For those who aren’t well versed in the world of Healthcare IT an EMR system install is often known as a Go-Live, which occurs when a hospital or clinic “goes live” on a new software suite.

At this time they will sunset (turn off) the old system and turn on the new one.

There is a lot of work that goes into a go-live, it’s unfortunately not as simple as flipping a switch.

Here’s how the process works:

1. A hospital becomes a prospective client and negotiations begin. Topics may be price, concessions the customer expects the vendor to make (i.e. custom development, support expectations after the install) and anything in between. This portion of the process may last anywhere from a few months to several years.
2. A hospital or clinic becomes a customer. At this point the organization has signed a contract, the vendor has agreed to whatever stipulations (ie custom development the customer requires), and both parties have agreed on pricing.
3. The build phase begins. Let’s assume all custom development for the customer has been completed. My company will often release this functionality to all of its customers, who then have the opportunity to install (and turn on) or not install the added features. In the Build phase of the software, the vendor of the enterprise suite will go in and work side by side with the employees of the hospital or consultants they’ve hired, and configure the software  to meet the needs of the customer. Note configure largely means no development. These are settings that are built in to the system that can be turned on or off. An example of this may be “Set item ‘XYZ – Automatically Generate Cleaning Request’ to ‘Yes’ if you would like the system to automatically generate an environmental service clean request when a patient is transferred from a bed.” So in this case the customer’s operations team and administrators need to sit down with the unit clerks and Transport managers and decide if it makes more sense for the employees requesting transport (say nurses or unit clerks) to manually request a bed clean, or if it should automatically be generated. Note again, as this is rather key, this is configurable not an option that causes the vendor to do additional development. This kind of system enables for a large variety of flexibility and the ability to (in theory) meet the needs of a large variety of customers.
4. While the core settings are being put in place, the project team (composed of vendor and customer implementers) is going to be identifying all of the data necessary to be loaded into the customers databases. This may be records representing physicians, employees, patients, units, rooms, beds, procedures, etc.. anything that is a piece of information unique to the hospital needs to be identified at this time. Occasionally the information may not “exist” in the previous system but is information that needs to “exist” in ours. In this case each of the subject matter experts (typically the manager of a department who may consult with his employees) need to be involved to design what information should make it into the the system. An example of this may be “Break types for transporters” in which the SMEs may decide on three records, Lunch, Break, Misc..If the customer is unsure or indifferent regarding necessary build (aka configuration) then the vendor will suggest what has worked best for other customers.
5. After the data has been loaded, it is important to test each workflow at least a month out so that employees understand how the system works and so any bugs or inefficiencies can be ironed out.
6. Go-Live date. This is the moment, if there ever is one, that the switch is “flipped”. The production environment is enabled and on Monday morning when everyone gets to work, they are all using a different system. During the first few weeks of a go-live (I’ll be using this term to refer to the point from which the legacy system has been sunset and the new system has been turned on) there are a number of the vendor’s employees running around the hospital helping hospital employees through their workflows. If there are bugs encountered that were not found in testing then the hospital employees or vendor floor supporters will call them into the “command center”–a centralized group which exists to streamline workflows and iron out furls in the system–to be fixed. This setup continues typically for a predetermined amount of time, however if things are running smoothly prior to the scheduled end of support date, or on the opposite end of the spectrum, things are still rather chaotic a month in, then the command center and floor support dates may be adjusted.
7. After things quiet down, the customer will

So thats it! That’s all there is to it.

Now the devil is in the details as they say, and I can assure you, I saw a number of those details in my first experience supporting a go-live this past weekend. As a software developer, I spend much of my time at my desk, designing and implementing new functionality. While I consider myself outgoing, I am not a “trained” floor supporter (although technically I am a professional floor supporter considering I was paid to do so).

Touring Harvard

The basic belief is that as long as you have an understanding of the application the end users you are supporting are using, then you should be okay. Unfortunately, the system is so configurable that often times the workflows barely resemble those that I we’ve set up in our “model” system back in our development environments. All in all, supporting our customers as they go live was a good experience. Not great–I would be lying to you if I said everything was hunky dory, even in week to of go-live, but it is rewarding to see your work used in the field.

Taking a walk after a long day’s shift

A few examples of issues that I saw when on site:

Power struggle for work expectations. This is an interesting thing to see. When you design a system you think this is who should do this and this is how I will design this task to be accomplished. You make basic assumptions of which user will be doing what. What I found is that it does not always work out that way, even when the customer expects it to. In this case, clinical users did not know how to create a bed request for their patients. A bed request is essentially how we tell the hospital’s bed planners that a patient will be moving and to figure out where to put them. It represents a transfer or admission that will soon take place. It is expected that a physician or unit clerk who is managing patients will request the transfer when the patient’s level of care changes or need for a transfer arises. However, these employees in the first few weeks of the go-live did not know how, or did not care to learn how to create this bed request, and thus simply just put the impetus on the bed planners. The bed planners in turn began creating and planning the bed requests, essentially doubling their workload. I suppose it is possible to make it more clear how clinical users can accomplish this request, however dereliction of duty is not a fault many developers would have thought to program against.

Accidental erroneous data entry. I encountered one ugly situation where an end user in the registration workflow created extra pending admissions (also known as encounters). The patient, who was admitted, now showed two encounters, one current admission and one pending admission. Our surgical users then performed a procedure on the patient, but all the data was recorded in the pending encounter. This is bad, B-A-D bad. Since there is no way to “move” that procedure data from one encounter to the next, I called it in to the command center. I never heard the final outcome, but the best solution last I heard was to recreate the entire six hour procedure in the correct encounter. How horrible!

The last interesting experience I want to share is simply sitting in a room with 4-7 overworked panicked bed planners as they hectically take calls, and complain about the system. Occasionally there is the moment of “ooh” and “ahh” where they find a useful new feature, or realize the ease of a task that may have taken them much more time in the legacy system, but largely the comments were complaints. I learned to sit their politely, listen and nod, as well as jot down ideas for ideas of fixes to their problems, or just let them vent. Much of their issues were not from our system but from their organization, or simply from their aversion to change. I honestly believe that their hospital is much better off with our company as their EMR vendor, and in a month or two, their employees will too.

It was a pleasure to support the customer, learn how they use the system and gain insights for future development, I look forward to doing so again. Plus it was fun to see Boston! (Hence the pictures thrown in randomly).

John Harvard