You got board approval and the funding to kick off that huge health IT (health information technology) project that will affect just about everyone in your healthcare organization. The news release has gone out, the kickoff is meeting completed, and the charter is published.  Now as the managers, analysts, and stakeholders prepare for the long haul ahead, you reference your “lessons learned” report from the most recent project. Uh-oh. You didn’t do a lessons learned? It looks like we should dig into some of the operational and technical challenges and pitfalls that you’re likely to face, so as to be ready for such challenges and get that health IT project out to light.

 

1. Human Resource Challenges

When a large project demands a lot of new and changed positions, here are some of the challenges you can expect:

• Positions left vacant may be hard to backfill, and the managers of those vacating positions will put pressure to keep you from taking too many of their staff, especially in clinical areas.
• Expect lots of drama among staff as they jockey for open IT positions. Feelings will be hurt, and it will take some caring leadership to keep people engaged.
• For staff who move laterally in IT, will some vacant positions be backfilled with contractors or FTEs? At what levels?
• If you are replacing systems, you’ll need a staffing plan to support these systems until they are officially retired.
• What is your timeframe for any certifications that will be required? How will you deal with staff who fail certification exams?

 Once you realize that a large implementation is just as stressful as a complete job change, you can better prepare yourself and your staff mentally.

 

2. Too High Expectation of Vendor Delivered Configuration

Sometimes called a starter set or release version, vendors pride themselves on delivering a configuration that is 95 percent ready out of the box. Just plug it in and go, right? Sorry, it ain’t gonna happen! I’ve seen my share of vendor-delivered releases, and I know that if you end up with an 80/20 mix of delivered versus built configuration, consider yourself fortunate. You can work on managing the scope of your users, but many times configuration issues have less to do with scope and more to do with the config simply not meeting workflow needs.

 

3. Data Conversion Surprises

When moving from one clinical system to another, data probably lives in the system(s) being replaced that is of value to clinicians and operational staff. Be careful who makes the decision on what does or doesn’t get converted. I’ve seen cases where the decision-maker sees little value in converting data, thinking it can just be archived in a third-party repository. Those who are closest to patient care reject the idea of not having quick access to volumes of clinical data that they worked hard to record. You’ve got to get this addressed early in the project because of the time and funding that will be required to successfully convert data.

The vendor of the product you are replacing is losing a customer, so they probably won’t want to handle their end of the conversion for free.

Also along the same lines, you may have data that will need to be manually entered into the new system, such as printed med lists. Consider the staffing that might be needed for this.

 

4. Printing Issues

Printing is one of the biggest challenges in any large activation. The best way to prepare for this is to have technical dress-rehearsal sessions at every location at least a week before activation. For this event, you will need users to log into the production system and test printing, permissions, and other basic functions. Be sure to test any dual-function printers such as those that print prescriptions on secure paper from one drawer and plain paper from another drawer.

 

5. Training Logistics

When you go live, especially if you go “big bang” (all applications at the same time), then you could find that while staff attended and signed off on training, they are feeling inadequate near the home stretch and are requesting extra support “at the elbow” during go-live. If this is a large project, we’re talking about more than just a handful of additional trainers. The problem is that you’re near the end of the project and probably don’t have a lot of money left over. That is unless you put this in the budget up front.

 

6. Third Party Activation Support Firms

There are contracting firms that provide armies of clinic or floor support staff for large activations. They tout these folks as highly qualified clinical trainers, but there are things you may not know about some of them.

The skill set of the floor support trainers varies widely. I’ve seen really good ones, but also met some who didn’t know what an MRN is. Seriously, it happened to me! Some of the firms are desperate for “heads” and grab anyone with rudimentary computer skills, then put them in a classroom for a few hours to show them basic functions of the clinical system they are about to support. If you use one of these, you will need to assign a strong leader in your organization to keep a pulse on how the go-live support staff is doing – and be prepared to respond quickly to complaints from your users.

 

7. System Security Issues

Most clinical systems have clinical users with widely varying roles:

• Nurse
• Medical Assistant
• Certified Nursing Assistant (CNA)
• Multi-Skilled Tech (MST)
• Technician
• Provider, MD
• Provider, ARNP or NP
• Pharmacist

It’s very easy to forget the security differences between, for example, an ARNP versus an MD. Projects should use some kind of security grid. Excel usually works fine. It will have all the permissions referenced to the roles and be signed off by operational leaders. As with the printing issues I mentioned, a technical dress rehearsal should uncover security issues as well.

 

8. Scope Creep and Gold Plating Syndrome

Scope tends to be a challenge with just about every IT project. An operational leader will realize that there is some functionality that must be added before go-live ARNP or NP – in three days. To weigh the validity of these requests, ask these kinds of questions:

Was this a major “miss” in the project when scope was determined?

• Is the new functionality absolutely required to go live?
• Is the functionality considered “net new”? If so, then the users were able to survive without it to this point. So it’s probably not wise to delay the activation.
• What is the impact of going live without the function? It’s usually considered a show-stopper if it either 1) has patient safety implications, or 2) major financial implications.

Gold plating occurs when a piece of functionally is optimized to meet the demands of every possible user and scenario. It can be a noble pursuit, but can cause unnecessary delays when “good enough” really is sufficient for go-live. It’s usually the IT analysts or developers who fall into gold plating syndrome.

 

9. Help Desk Support Challenges

Try as you may to get your first-line help desk trained, those people are also learning a new application, and they will certainly feel as overwhelmed as everyone else. If they can sit in on some of the training that the end users get, they might fare better.

If you have multiple product segments or modules, you can expect a high number of wrongly assigned calls and tickets. Be sure to track each and follow up with your help desk manager. If possible, configure your ticket reporting system with a flag and field for wrong calls/tickets that can be tracked and reported on.

Finally, it’s important to stay encouraged and remind yourself and your staff that you will get through this. The Gartner Hype Cycle graph has been used to describe lots of things, and I do think a large clinical implementation is a worthy candidate.

 

Dave Newman is an application analyst and project leader in healthcare IT at a Seattle hospital, as well as the creator of LearnHealthTech.com, a site to help people gain and develop healthcare IT skills.