FierceHealthIT editor Ken Terry had a recent post on the need for better human-computer interfaces in EMRs. He highlighted a few areas where EMRs could stand some improvement, and I thought they were bang on. These are aspects I’ve thought about a great deal myself, and true to the Steve Jobs dictum of staying foolish, I’m offering some solutions to these oft-mentioned problems. I’m sure there are plenty of people who have already thought of these and better solutions, but here we go:

1) Initial Data Entry – The biggest headache for providers’ offices today is what to do with all those boxes of medical records. Scanning solutions exist but they leave you with unstructured data. Manual extraction is time-consuming and requires upfront investment. I’ve pondered for a while about this. I think on-demand data extraction might be the way to go. Provider offices know ahead of time what their weekly, even monthly appointments are. If a provider’s office digitizes the records of patients with upcoming appointments every week, it should have most of its records digitized by end of year. This is assuming patients make it to the doctor’s office for at least once-a-year appointments if not more. If the office outsources this work, it needs some monetary investment, no doubt, but such a setup might be affordable since it is pay-as-you-go.

2) Templating – Terry states that many doctors hate the templates that come with most EMRs. And templates make it easy to generate pages and pages of verbiage which say exactly the same thing for patients with similar profiles, or say very little that is meaningful. Surely customizable or extensible templates can get rid of this problem. Or speech-to-text dictation that allows the doctor to mirror practices from not so long ago.

3) Alert Overload – Many EMRs are designed to issue alerts for adverse drug interactions, prompts for patients and similar such decision support tools. But too few of these and you risk not asking the right questions. Too many providers just ignore them, or worse, override them. No easy solutions for this one, except maybe to figure out where the fine line lies between lack of decision support and too many alerts.

4) Interoperability – EMRs cannot talk to each other. So a patient who moves from one provider to another is really at the mercy of software whimsies. Or worse. For providers, it’s equally frustrating not to be able to get ahold of the patient records in a format suitable for their particular EMR software. One simple answer – standards. Granted HL7 is still evolving, but EMR vendors need to at least consider offering data exports in this format.

I recently got a note from someone who is working on a rather interesting project. They’re basically creating a standard front end for a hospital’s EMR systems. I think the concept is really interesting and could be really cool to see put in practice. Here’s a note from one of the company founders about what they’re doing.

Contineo (Latin meaning “To bring together”) — is designed to be a back-end agnostic client. Our goal is to wrap all medical information systems into a single client. This means providing access to Nurse Call, Patient Monitoring, Results and even EVS (Environmental) and ordering systems (Such as food ordering).

Additionally, we have integrated messaging features (IM) that allow for staff to communicate with one-another and are working on a range of other elements that really focus on providing the best tool of a clinician to access and interact with medical systems and data.

We do this through our client server architecture where the server is integrated with the varied medical systems through standard APIs. We are working to identify key systems that are standards based and develop modules to connect to them.

Any HL7 or XML based backend can be integrated with.

Currently, we have a proof of concept with a major hospital in Silicon Valley, where we are connecting to a Microsoft Amalga system – and providing the same front-end client that is seen in this Medsphere post.

We are working with clinicians to define workflows that are of value to them – this includes things such as medication administration. The client has an integrated barcode scanner which allows for med/patient verification and the logging of the actual admin of a drug. This encounter scenario can be used in a number of workflows; e.g. Verify order, take action, confirm action completed.

This can be pushed back into the EHR via a standard HL-7 message. In the case of an Amalga implementation – the data could be pushed to both the EMR and Amalga

We are seeking input and feedback and are really looking for more hospitals that would be interested in a POC and potential Pilot.

As you can see they’re looking for hospitals to pilot their product. You can contact Contineo on the Contact page of their website. Otherwise, leave a comment and I’m sure they’ll be watching there as well.

I told them they needed to do the same type of interface for ambulatory EMR. Could be really interesting to see that type of integration with the iPhone.

We keep hearing about the Big National Data Bank for Healthcare Information. The thought is that you need a big data bank so everyone’s health information is available anywhere/anytime. This type of personal health information repository has many problems. First it is complex and expensive to set up and maintain. Second there are very significant and well-founded privacy concerns. And finally, this large, complex electronic structure may not be needed … it might even be counterproductive!

Is there another way to transport patient health data from one platform to another (so it can go from one EMR to another), so that healthcare providers, anywhere/anytime can provide fully informed care for individual patients which would be less expensive and higher in quality?

I think the answer is YES!

There are standard data exchange platforms currently being used which can help us all share “meaningful” personal health information. They are called the Continuity of Care Record (CCR), CCD and HL7. For more information on these platforms, I suggest you read Brian Klepper’s blog post. This blog gave me great insight into this connectivity issue.

In addition to obviating the need for a big data bank, these data exchange platforms make it possible for small, innovative EMR companies to compete and survive in the “EMR Jungle”. By allowing for diversity and encouraging innovation, we will end up with better EMR software. In addition, physicians will be able to pick EMRs that suit their practice style and can make them more efficient, productive and better doctors. I think we need a patchwork quilt of unique EMRs that are all well connected rather than a few big standard lemming EMRs that are totally connected by “big brother” or “big business”.

What are your thoughts on this topic?

How do you make health databases talk?  Use the ‘Health Level Seven’  (HL7) protocol.  

How do you make them say something other than four letter words?  A lot of study, smarts, and intuitive understanding, and nifty tools I outline here will be your best allies in that sense. 

HL7 essentially describes a transfer protocol that is used between health care databases.  Why would you care if you were implementing an EHR?  Simple.  I assure you your EHR does not run the radiology equipment, or the radiation oncology equipment, or the lab system, or the drug dispensing system, or the supplies system . . . In other words, I know that a majority of places have multiple systems in play out of operational necessity.  HL7 attempts to give us a way to get around that, by creating a data standard that describes messaging ‘events,” and the body of that message.  An HL7 (2.x)  Message looks something like this

I know.  That looks like a bunch of gibberish, doesn’t it?  But really, it’s not.   I want to try and demistify a little about this message over the next few posts, and hopefully help you to understand what HL7 does, how it transmits data, and how you can make it work for you.

Often, people ask me the differences about HL7 standards.  The standards have undergone enormous changes over the years, and you can always keep up with them at www.hl7.org.  There are so many resources over at that site, and my main purpose is to give you an overview of what I find to be the most useful, and a general guide on how to use it.

First I want to explain a few things about HL7.  Think of it like DICOM, only not really . . . you know, standard.  Because, like almost everything in healthcare, a standard is just what you make of it.  Think of HL7 more of being guidelines for where to put data in a message.  While it seems rigid at first, the more you are exposed to the different vendors and their different capabilities as it relates to HL7, the more you will understand what I mean (instead of thinking I’m launching into an explanation of what the word ‘is’ is).   HL7 itself has undergone several different versions, but most vendors I have seen are using version 2.x (that’s 2.anything), but version 3 has some pretty slick features, and utilizes XML to make it much more accessible.   The first thing you want to do is make sure that the two systems you want to have a conversation will be using the same language.

If they can’t, don’t despair, because often people use an engine to sit between the source and the destination, and you can do all sorts of nifty transformations in those things.  There are variety of platforms for this intermediary server, and an incomplete list can be found here on HL7′s site.  The type of environment, be it eBiz, Ensemble, Interfaceware, Corepoint — that selection is going to be made based on how you are going to use your engine.  Do you plan to use it for multiple interfaces?  How many, really?  What kind of functionality do you want it to have?  Generally, I stay tool agnostic, because these choice are best left to organizations. 

Just know that the engine will do one vital thing — it will change your interface process from one step to two.  You will have one interface from source to engine (and thus one specification and one set of code) and another interface from engine to destination (thus a second specification for a second set of code).  Often times, HL7 will also involve configuration of the source and destination systems on HL7 message handling.

The next part of this series will discuss HL7 event types in overview.