ed-informatics.org

It is said, usually by vendors, that installing an EDIS (Emergency Department Information System) will negatively impact ED efficiency for a short time, and then efficiency will increase to levels higher than before, thus:

Effect of ED Information System on ED Efficiency: Vendors

But ED Information Technology pundit Dr. Todd Taylor (emergency physician, past Speaker of the national Council of the American College of Emergency Physicians, and now executive with Microsoft) says that the graph should really be more like this:

Effect of ED Information System on ED Efficiency: Todd Taylor

Who is right?

Both are right. A bad EDIS implementation can decrease efficiency. A good EDIS implementation can increase efficiency. I have personally experienced both. It used to be that almost all EDIS implementations were bad; more recently, it seems to me, a majority are at least mediocre.

One caveat as you’re digesting the information in this post: in many cases, before installing an EDIS, data about efficiency were hard to obtain, requiring hours of work by a data analyst to produce a single set of reports, so that “pre-EDIS” data is suspect. Another caveat: an EDIS is often installed as an ED is expanding and its volume is increasing, so trying to compare before-and-after numbers is a bit like comparing turtles and giant sea tortises (or maybe teenage mutant ninja turtles). Nonetheless, if you work in an ED through the implementation of such a system, despite the “the plural of anecdotes is not data” bit, it’s easy to tell whether the EDIS negatively or positively impacted efficiency.

Given that physician charting has such an effect on efficiency, I will discuss ED charting in a new series starting soon. The remainder of this post will focus on EDISs in general, mostly dealing with the tracking system portion of the EDIS, which is usually the part that is first implemented.

Now for some fairy tales.

Once upon a time, at a fairly-large hospital in northwestern Pennsylvania, the C-suite and in particular, the CIO and CFO, decided that they were going to install a Hospital Information System (HIS). Someone called the ED secretary and asked “could you send someone to a meeting at 2 PM on Tuesday to design the screens for the ED?” That was the sum total of design effort put into the ED part of the HIS; one suspects that similar care and thought went into the rest of the HIS. The product was unusable, failed, and was deinstalled. That was a bad HIS.

But there’s more to this than just bad and good HISs and EDISs. Notice that, above, I wrote that “a good EDIS implementation can increase efficiency.”

Once upon a time, at a fairly-large hospital in south-central Pennsylvania, the ED decided to install a niche/best-of-breed EDIS. They started with the vendor’s tracking system. They installed it, and there was a very brief drop in efficiency, and then things picked up, efficiency improved, and everyone lived happily ever after. For six months, that is. Until they decided to install the vendor’s nurse charting module. The nurse manager of the ED, who I knew personally, told me that the subsequent six weeks was the worst experience of her life, and she seriously considered suicide. I’m not kidding, and she wasn’t, either. They deinstalled the nurse charting module until the vendor could redesign it. (BTW, she used to be a speaker at the EDIS conference.)

This is true of HISs as well.

Once upon a time, a fairly-large hospital in Indiana had an HIS and wanted to implement an EDIS, either the HIS’s ED module or a niche/best of breed system. After due consideration, the ED Chair and the CIO decided to install the HIS’s ED module. It was a miserable failure, and they jointly decided to deinstall it. After six months of additional consideration, and attending the EDIS conference, and looking very closely at different niche/best-of-breed products, they finally decided that, with a little work, the best solution for them was an upgraded version of the module they had deinstalled six months before. Once they got it installed and customized, things were good and they lived happily ever after.

There is another moral to this last tale: HIS vendors tend to deliver a box of parts rather than an assembled system. It’s a lot like buying a kit to build a bike for your kid for Christmas. That is, it takes a lot of time and effort to build, and you probably won’t get it right the first time. HIS vendors say: “You can customize to meet your specific needs!” The cynics say: “This is a way to get the hospitals to do design work, which the vendor will then steal and sell to other customers.” Jakob Nielsen says: Leaving the design to the users is the ultimate abdication of the designer’s responsibility to provide a quality product, and many studies have shown that users . . . customize their interface in ways that are detrimental to their productivity. [From the preface to Mullet and Sano’s outstanding book Designing Visual Interfaces: Communication Oriented Techniques]

Once upon a time, a fairly-large hospital in southwestern Pennsylvania installed an ED charting product. The vendor and the product were known to the ED, and the vendor was trusted (well, as much as you can trust any vendor). The ED coordinated with the hospital IT department, and the hospital agreed to build the upstream and downstream interfaces for the product, using the hospital’s interface engine.

Upstream and downstream depend on which way you’re facing. Since the ED is almost always on the bottom floor of the hospital, and those in the ED often complain about being up to their knees in alligators, we will term the ED downstream, and the hospital proper upstream.

The downstream interface for a charting product downloads demographic data from the HIS or registration system into the charting product – so users can pick, from a list, one of the patients currently in the ED.

That way, once the ED chart is complete, it has identifying information so that when it heads back upstream to the HIS it can attach to the right patient’s record.

The vendor installed the product, and it worked OK; not perfect, but well enough. The hospital installed the downstream interface. But then the person who built interfaces left. Months later, the hospital still hadn’t built the upstream interface. A couple of years later, the hospital still hadn’t built the upstream interface. But you can’t destroy medical records, so the charts had to be saved. The ED charts built up. Tens of charts. Hundreds of charts. Thousands of charts filled up the hard drives; they were spinning faster and faster and getting hotter and hotter. (Remember, this is a fairy tale.)  None of the charts ever made it to the HIS. Eventually the large numbers of stored charts, in a system never designed for data storage, caused charting to degrade so much that the hospital had to take drastic measures to keep the product working. They never actually did get that interface working; they ended up upgrading to a newer version of the charting product, and this time, the hospital built both interfaces, the charting system worked, not perfectly but OK, and everyone lived happily ever after. (More or less.)

So sometimes the problem with an implementation is not related to the vendor, but related to the hospital’s IT department, or due to the interaction between the EDIS and the HIS.

So, you think this is a good reason to buy an HIS module for your ED rather than a niche/best-of-breed EDIS?  You think using the vendor’s ED module guarantee your interfaces will be problem-free?

Well, think again. Some vendors added ED modules by the simple method of buying out an EDIS or similar company. And, as you would suspect, the interfaces don’t work that well. I know of hospitals who have installed a HIS ED module and then found it didn’t interface with most of the HIS. For instance you couldn’t look up the HIS’s old electronic records from the ED module, you had to launch a separate program to do that. I know of at least two HIS ED modules that are (or at least, were) that way. Caveat emptor.

Once upon a time, a medium-to-large hospital in southwestern Pennsylvania installed a niche/best-of-breed EDIS. They were very, very happy. The implementation went well, and efficiency increased. Then a large, nearby hospital system said “Come, be part of us.” And it was so. But then the large hospital system said “That EDIS you have has to go. We use a single HIS and EDIS module for all of our many hospitals, and you must use it too.”

The people in the ED were very, very sad.

The people in the ED heard how unhappy other EDs in the system were with this HIS ED module. Even the hospital CIO told them it was a “downgrade.”

But the CIO promised to take the erector-set of parts provided by the HIS vendor, and to try to reconstruct some of the functions they would lose in the downgrade.

And lo, it was so! Many of the functions the ED was losing were added back by the hardworking IT elves at the hospital.  (The didn’t add them all back; they were just elves, not Santa Claus, after all.) And the changes wrought by the IT elves were spread throughout the entire hospital system, and all of the EDs lived happily ever after. (Not as happily as if they’d had the niche/best-of-breed EDIS, but happier than they’d been right after the “downgrade.”)

I’ve worked in many different EDs with different Emergency Department Information Systems (EDISs) and have seen many different results from the same EDIS or HIS ED module. Sometimes it’s not the software, it’s not even the interfaces, it’s the actual human side of the implementation process. I have seen the same exact product used entirely differently in two EDs. In one busy urban ED in Philadelphia, with multiple “pods” (separate sections of the ED, each with its own “nurses’ station),” the doctors “live” in the tracking system (Amelior EDTracker) – it’s up in front of them all the time, they’re interacting with it because it tells them which patient to see next, when the labs are done and what they are, what orders they (and the residents) have entered on the patient, and more.

At a busy community ED at the other end of the state, outside Pittsburgh, with two “pods” but nonteaching except for some medical students, the same system is in front of the secretaries, who use it all the time; the nurses use it less but still quite a lot. The doctors never look at it. They get the labs and know when X-rays are done because the secretary or nurse tells them or sticks a printout on the paper chart.

Why the difference? Multiple reasons, likely. At the community hospital, the current system works, so why should they change? And as a nonteaching hospital, they don’t have docs who know and love the usefulness of a tracking system.

It also might be the actual human side of the implementation process. If you implement well, then people will be happy and they will use the system.  What constitutes a good implementation from the human side? A short list would include:

• an adequate amount of good training for your personnel before the “go-live” day
• extra experts (likely provided by the vendor) around during the first few days after “go-live to help over the hump
• having chosen a physician and a nurse to be “super-users” and champions of the system
• staffing with extra nurses, docs and secretaries for the first few days after “go-live”

I’ll have more to say about the implementation process in a future post.

So what’s the bottom line? How about this: if you

• select a financially-stable vendor with a superior system,
• make sure that your IT department will be able to hold up their end of all the needed interfaces,
• prepare for the human aspects of “go-live day”

then you can expect to improve your efficiency.

If you don’t, then your mileage may vary.

Good luck.

Tags: ED Systems, Emergency Department, Computers, ED, Healthcare IT, Usability, User Interface, Efficiency, Process