Welcome to EMR and EHR

Yes, you should be wincing a little bit if you clicked on this post because you just had to see what it was talking about. Thankfully, it’s not actually my post. It’s a post on the CareCloud blog titled “9 Things Electronic Health Records Can Learn From Star Trek”. Here’s the list of 9 things (you can read the full descriptions on the link above):

• Multiple Channels for Data Entry
• Interactive Patient Education
• Holographic Doctors
• Detailed PHR on demand
• Integration with vital signs monitoring systems
• Adaptive, Intuitive Touch Screen Interfaces
• Real time Practice-wide Synchronization
• Remote Access for Patients
• Support for Mobile Devices

Pretty creative if I do say so myself.

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.

John over at EMR, EHR, and HIPAA wrote a great blog on meaningful use, and some of the definitions that are being kicked around in the healthcare IT world.  It is interesting to me that HIMSS includes in its definition of meaningful use ‘decision support.’

For a long time, my work revolved around decision support.  It’s truly an interesting area, and can include such suave topics as BI and decision support.  My biggest issue with it being a deciding factor in meaningful use is that it simply isn’t an option yet, especially for folks early in their adoption of the EHR.  

I’ve blogged about reporting off of an EHR before, and I will reiterate my point — it is vital that the reporting needs of an organization are explored during the EHR RFP process.   If the reporting needs aren’t understood when the EHR is adopted, chances are they won’t be met.   This also extends to decision support — just think of it as reporting needs on steroids.  Now, not only are you supporting one or two data points, you are supporting several, and attempting to allow the system to enact the 80/20 rule — that with 20% effort it could support 80% of the decisions.  

In order to support decision support (wow), it is necessary to have key data indicators in place, preferably in a discrete format (and not a bunch of free text) so that a few queries could be run, or a dashboard report created that will take care of it all.  If this doesn’t happen, I’ve seen quite a few clients turn to solutions that include SAS and SPSS for text mining to attempt to get at the same information.  Both SAS and SPSS are excellent tools for such work, and a little less unwieldy than attempting to write a query that includes a bunch of junk in the where clause because . . . Oh wait.  Let me go a bit slower.

If you end up having a lot of free text data that you have to report off of, you have to remember this little accidental thing called a typo.  One of the first text mining projects that I worked on involved data that came from an insurance call center, and “Payment” was spelled in over 75 different ways (including typos). Don’t believe me?

PAYMENT

PMT

PAYMT

PYAMT

PYAMENT

PAY

PMNT

MPT

To write a SQL query that would be able to SORT OF predict if a person meant payment would have a query that would be very, very slow to run.  Add on the volume that your clinic has, and in a few years it could be quite a mess.  All of this can be taken care of if you simply address the needs from the beginning, and start to watch regulations and motions in congress to understand what upcoming data needs for things like HEDIS, PQRI, and Pay for Performance would be.   To make matters worse, there are still often ‘fixes’ you have to put in the data in order to make it fit into some reporting needs, and ultimately decision support.

My problem with ‘meaningful use’ including decision support is the fact that it will sting early adopters.  So, if you had adopted an EHR in, say, 2002, you might not have seen all of these issues coming — and your EHR may not include robust decision support, or have strong data structures to support it.  I would hope that if you adopted your EHR in 2002 that much care has gone into it, but I have also seen EHR’s implemented as late as 2006 that contain unruly data.  I tend to find that in the larger the clinic and the more the users, the more of a problem this becomes.

Yes, there are ways to retroactively fit an EHR to support decision support, but it involves a lot of groundwork.  You have to establish how far you will want to go back, you’ll have to understand the amount and quality of data at every single step, and you will have to somehow code around that data.  You have to decide if you want to retroactively fit that data back into the medical record, or if you want to introduce a data warehouse to hold it (a project that is both expensive and very likely to have issues along the way, depending on what systems are included).

I do believe that decision support is a vital function of the modern EHR.  I’ve seen some that really assist a physician in performing their tasks, yet were rejected in an RFP phase because they would not support reporting requirements such as HEDIS or OSHPD, or even the operational and financial statistics of the department.  What I’m not sure about it is how they expect to legislate this.  Are they going to come into clinics and run our data to see?  As a big privacy advocate, I can’t say I like that decision.  But I’m also not keen on ‘self reporting.’

I worry about organizations that will try to short cut their decision support by just ‘using the billing data.’  Billing data needs to be created in tandem with clinical data, but it functions under different rules, and has different requirements.  The skew that using billing data with no clinical context will not be true decision support — it will be merely meeting the letter and not the spirit of the law.  How will legislation address this?

I am wondering how they are going to legislate this, given that at quite a few of the clients I have worked with, their only recourse is running reports, and getting back to the department that is acting like an “EHR Rogue.”  How will Congress decide who is meaningfully using systems?  How can this possibly be regulated at a federal level, when we all have problems regulating it ourselves?

Food for thought, for sure.

As a consultant, I’ve had the pleasure to work with several large clients, and almost every single one has made the same request of me –

“How can we get a report telling us patient volume by (insert ‘data cut’ here) in a timely manner?”

And boy, is that a doozy.  I’ve filled out lots and lots of joint commission reports, and one of the main data points they want is ‘how many,’ yet many of my clients find that number frustrating, if not impossible, to get to.  So many times, I’ve heard CEO’s, CFO’s and the like complaining that two reports from two different people on the same number come out with different results.

Considering that many of them had EHR’s in place – why is this number so hard, when it seems it would be the simplest?

The answer I’ve come to (and always seem to come to) is that it depends on who the client is.

The definition of a ‘patient’ in a capitated sense is different from a ‘patient’ in a clinical setting, yet both of these are reasonable numbers.

Consider — I worked for network oncology operations (so, the operation of all clinics)  in one place.  They considered a patient to be someone who had started a course of treatment.  However, the clinical operations  considered a patient to be someone who walked through the door.

Both of these are valid numbers, but when finance asked for ‘how many patients did you see,’ the two came up with wildly different numbers.

It’s easy to see why, isn’t it?

In this situation, we held a five hour meeting during which we attempted to come to a resolution between all involved on what these key performance indicators were, and how we would define and derive them.  Five hours later, we barely had defined what a patient was, and it seemed on the surface to many involved that the old fashioned method of having people keep count and report to us with a phone call still seemed rather sweet.  After all, the biggest concern for everyone was that we didn’t present the CFO with different numbers, but we couldn’t make the clinic and overall operations agree on which was the more accurate statistic.  But, I pushed back, and pushed back hard that we should not be spending four to five analyst hours per day on gathering the number when we could do it from the system with just a little more effort.

We called another meeting — and I took over and suggested a compromise.  We ended up implementing my plan, which was a simple one — we would define the statistics more carefully, and report all of them to the CFO — so he could pick which numbers he wanted to use after having a full understanding of what they mean.  We ended up with Patient Starts, Patient Consults, and Patients.

Was it a pain?  Not as painful as the meetings where we were all upbraided because we couldn’t report a seemingly simple number.  Yes, two five hour meetings discussing the definition of patient was painful.  No way around that.  But it was necessary.  From these three definitions we were able to leverage the information in our EHR and create reports that were meaningful — they just reported three numbers, and the analyst FTE was changed instead to a database script.

While examining the output of these reports, we found several instances in which the system was not being correctly used, and used our ‘data goal’ to come up with new internal policies and training guides to ensure our clinics were entering what we needed — and if they needed more staff to support, we were able to comply — we now had an analyst FTE’s that could assist the clinic in proper EHR utilization, instead of just calling people and asking for a number.  She was much more challenged in this role, and a happier employee, and it stopped the angry calls from admin to the clinics for numbers.

So, if you are thinking of implementing an EHR, I would strenuously suggest that reporting be a key factor in selection, configuration, and implementation.  It’s far less painful (and expensive) to have reporting requirements out of the gate than to try and rig a system around poor configuration ex post facto, or to completley change front desk and clinical worfklows far after initial implementation.  EHR may be a clinical concept, but it touches all areas of healthcare operations, and COO’s, CFO’s, and CEO’s are stakeholders in these systems in addition to CMO’s, CTO’s, and CIO’s.

Quickly, now — which is easier to support?  I’ll give you a hint — most times, my little 5’0 personage would be choosing hoisting that rock on my shoulders.  Honestly, though, I’ll say that famous answer in healthcare, that it depends on the clinic.

Many years ago, when I was working for a very large multi-site cancer center,  I was called into a meeting with all the bigwigs.  You know, VP’s and such.  It was my first time, so be gentle.  I really didn’t understand why I was being asked, and the meeting invite was notoriously vague.  I was ushered into a very posh board room that I didn’t even know that we had (complete with video conferencing), at a round table with approximately 27 other people who were most definitely paid a lot more than I was (and had a bit better fashion sense, compared to my frazzled, just out of the data center look).  One of the VP’s announced that he was planning to look for a cancer-specific EHR/EMR that would encompass both radiation oncology and medical oncology, and interface with the main EHR that the hospital overall was going to implement.   He wanted to use the data that we gleaned from such a system to support one of the largest research studies done in a particular type of cancer therapy, in a prepatory round for pay for performance.  Then, he informed us that one of our vendors had said they were able to fill this need. 

The problem was, I knew that they couldn’t.  And I’m one of those people who doesn’t know, apparently, how to keep her mouth shut.  My immediate response was “They’re lying.”

“Oh, but they promised me.”

“I understand that, sir.  But they ARE lying.”

 I ended up with another four hours cut out another one of my days to be one of the folks who had to sit in on the demo.  Even worse “SM” pulled me aside and told me I had to run it, and I had to prove or disprove whether or not this integration was possible.   It was a grueling four hour ordeal for both me and the dog and pony show man, during which I did indeed uncover that they weren’t an integrated solution.   When I did, someone actually got up and ran to tell SM.

Moments like those make you wonder.

Even after we reported back to SM that we absolutely would not be able to support this research with a system (this vendor, we knew, was the closest), it was decided they were going to go forward.  Somewhere in all of this, I was assigned the entire deal — from the construction of the database to hold it (and the ability for folks working remotely to log into it to use it), to the design of the forms to gather the data (ranged from size of tumor to dosimetry data to whether or not they could still spit or eat steak), to the management of the bodies in motion.

Because I started as a database guru, I was given the task of cleaning up the treatment system data for radiation oncology, and bumping it up next to the chemo information we gleaned from registrars examining paper charts, and minimal amounts of information regarding the medical oncology from the paper chart and billing data.   Two of our radiation sites were ‘islands’, and yet another one at the time didn’t even have a robust record and verify system at the time.  This made for an extensive process.  Since part of the research was being administered as a telephone questionnaire, I also had to come up with the best call lists as I could.

I made sure to filter all the dead patients I possibly could out of the data set — not only did I use the SSI Death Index (doesn’t include goverment workers or teachers, and several other occupations), but I also used all the systems we had for the entire health system (I was a cool kid with the access).  I did everything I could, but in the end all of that was beaten when I sent the list to the site managers, who had their secretaries note additional deaths they had recorded from the newspaper.  You see, that was actually our best way of determining if a patient was, in their terminology “CTB.”  Which means Cease to Breathe.  I requested in earnest that if I died, that I was called dead.

In the end, they got their data — and we went through this painful process two more times for two other studies of the same therapy across differing diagnoses.  But one of the hard lessons came when I was cleaning up some of the data (I was one of the people who helped to type it in, since some of the clinics didn’t even have remote access due to affiliation issues).

The question was regarding whether or not the patient could chew their food.  You see, shoot enough radiation at someone’s head (it was a head and neck study), and their salivary glands won’t work. 

Unfortunately, the doctor had not properly noted the patient’s diagnosis ANYWHERE – it was billed wrong and clinically noted wrong.  We knew it was somewhere in the head, but it was a very non-specific head and neck ICD-9 (lemme show some ICD-10 love).  So, when the nurse called and asked the question, the patient’s wife had answered:

“You cut my husband’s tongue out.”

Lesson:  Every physician must be a champion of health data in order for HIT to truly succeed in any realm.

I would like to open by extending my gratitude to John Lynn for convincing me to blog about EMR’s and EHR’s.  He is my partner in this endeavor, and I appreciate everything he’s done to get this wonderful blog up and running.   If you want to see a truly robust blog about these issues, his is fabulous.

Right now, my desire for this blog is to bring you, my delightful readers, a view into EMR’s and EHR’s.  I’ve been working in this industry for over a decade, across many disciplines (finance, clinical, IT, medical physics, treatment devices, ICU, honest brokering, billing, FQHC’s, inpatient, ambulatory, integration / HL7, data mining, research projects, scheduling, benefits, charge capture  — yeah, all over the map), and have even had the honor to work overseas, in a post with the NHS of Scotland.  I’ve seen, implemented, played with, tested, reported out of, billed from, and experienced many EHR’s and EMR’s out of the box and in the wild (very rarely are they tame).  To boot, I still get geeked when I first look at a new data set.

I’m going to admit, I’m an opinionated person.  I am sure at the end of each post you’ll have no doubt about where I stand (or no doubt that I’m not sure where to stand yet!), and I’m going to probably pontificate on crazy minutae.  I’m hoping, however, that I will be informative and interesting (and yes, sometimes a little irreverant) to read, and that I will be able to present material that will help folks on their journey toward EHR Goodness.