Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and HIPAA for FREE!!

The Medication List Said, “Raised toilet seat daily”

Posted on September 25, 2014 I Written By

The following is a guest blog post by Lisa Pike, CEO of Versio.
With over a third of healthcare organizations switching to a new EHR in 2014, there is a lot of data movement going on. With the vast amount of effort it took to create that data, it’s a valuable asset to the organization. It can mean life or death; it can keep a hospital out of the courtroom; and it can mean the difference between a smooth-running organization and an operational nightmare.

But when that important data needs to be converted and moved to a new EHR, you realize just how complex it really is.

During a recent conversion of legacy data over to a new EHR, we came across this entry in the Medication List:  Raised toilet seat, daily.

Uh, come again??

How about this one?  “Dignity Plus XXL [adult diapers]; take one by mouth daily.”  What does the patient have, potty mouth?

Now, while we may snicker at the visual, it’s really no joke. These are actual entries encountered in source systems during clinical data migration projects. Some entries are comical; some are just odd; and some are downright frightening. But all of them are a conversion nightmare when you are migrating data.

Patient clinical data is unlike any other kind of data, for many reasons. It’s massive. It requires near-perfect accuracy. It’s also extremely complex, especially when you are not just migrating, but also converting from one system “language” to another.

Automated conversion is a common choice for healthcare organizations when moving data from legacy systems to newly adopted EHRs. It can be a great choice for some of the data, but not all. If your source says “hypertension, uncontrolled,” but your target system only has “uncontrolled hypertension,” that’s a simple enough inconsistency to overcome, but how would you predict every non-standard or incorrect entry you will encounter?

Here are some more actual examples. If you’re considering automated conversion, consider how your software would tangle up over these:

346.71D  Chm gr wo ara w nt wo st ???
levothyroxine 100 mg Should be mcg. Yikes!
Proventil Target system has 20 choices
NKDA (vomiting) NKDA= no known drug allergies.
Having no allergies causes vomiting?
Massage Therapy, take one by mouth twice weekly ???
Tylenol suppositories; take 1 by mouth daily Maybe not life-threatening, but certainly unpleasant
(Pelizaeus-Merzbacher disease)
Should have been PMDD
(premenstrual dysphoric disorder)
Allergy:  Reglan 5 mg Is patient allergic only to that dosage, or should this have been in the med list?
Confusing allergies and meds can be deadly.
Height 60 Centimeters or inches? Convert carefully!


These just scratch the surface of the myriad complexities, entry errors, and inconsistencies that exist in medical records across the industry. No matter how diligent your staff is, I guarantee your charts contain entries like these!

When an automated conversion program encounters data it can’t convert, it falls out as an “exception.” If the exception can’t be resolved, the data is simply left behind. Even with admirable effort, almost no one in the industry can capture more than 80% of the data. Some report as low as 50%.

How safe would you feel if your doctor didn’t know about 20% of your allergies? What if one of those left behind was the one that could kill you? What if a medication left behind was one you absolutely shouldn’t take with a new medication your doctor prescribed? Consider the woman whose aneurysm history was omitted during a conversion to a new EHR, so her specialist was unaware of it. She later died during a procedure when her aneurysm burst. I would say her family considered that data left behind pretty important, as did the treating physician, who could be found liable.

Liable, you say?

That’s right. The specialist could be found liable for the information in the legacy record because it was available….even if it was archived in an old EHR or paper chart.

You can begin to see the enormity of the problem and the potentially dangerous ramifications. Certainly every patient deserves an accurate record, and healthcare providers’ effectiveness, if not their very livelihood, depends on it. But maintaining the integrity of the data, especially during an EHR conversion, is no trivial task. Unfortunately, too many healthcare organizations underestimate it, and clearly it deserves more attention.

There is good news, however. With a well-planned conversion, using a system that combines robust technology with human expertise, it is possible to achieve 100% data capture with 99.8% accuracy. We’ve done it with well over a million patient chartsIt isn’t easy, but the results are worth it. Patients and doctors deserve no less.

Lisa Pike is the CEO of Versio, a healthcare technology company specializing in legacy data migration, with a proven track record of 100% data capture and 99.8% quality. We call it “No Data Left Behind.” For more information on Versio’s services or to schedule an introductory conversation, please visit us at or email

Interesting EMR Data Conversion Story

Posted on December 1, 2009 I Written By

John Lynn is the Founder of the blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of and John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

One of my readers sent me the following story about an EMR data conversion experience they had just had. I’ve removed the name of the EMR vendor and PMS vendor, because I think this could apply to a lot of the “jabba the hut” EMR vendors out there. Enjoy!

I had an interesting conversation today with one of my clients who is now in the process of migrating to [EMR vendor]. My involvement is to assist in moving the patient demographics into a file that can be imported by [EMR vendor].

So it starts out a week ago with my receiving a spreadsheet naming the fields used by [EMR vendor]. Then the client sends me an augmented version of the spreadsheet saying which fields from their current system are to map to the new fields in [EMR vendor]. I’m fine with this, it just makes my job a little easier since I don’t have to do any guessing. I spend a half hour writing and testing the program, and send a sample test file of 200 patients to the client. I exchange an e-mail with the client and it is agreed we will have a conference call on 11/24.

This brings us to today. First call starts out, not all the people are available on the [EMR vendor] side. (There were scheduling conflicts.) So ten minutes pass while people discuss what time works best for everyone. Instant messages are sent in hopes of snagging other people. New time set for afternoon.

Afternoon comes. All parties are present. Interestingly, the programmer on the [EMR vendor] side seems a little unfamiliar with the field layouts as defined in the spreadsheet sent a week earlier (who knows who sent it). After some discussion on their part, it is not clear whether they are talking version x.4 or x.5. He’ll send an IM to another programmer for clarification. Seems to be some concern about our sending blank/null data for fields that are not being used. Decided it is not the big of a problem. Discussion between client and [EMR vendor] revolves around whether they are talking about [either of the 2 methods this EMR vendor uses]. It is finally decided that more fields are needed in the original spreadsheet. Which field should be used for “race”? Are patient names going to be converted in all upper case or upper/lower? They’ll check with another programmer – that might be a conversion parameter. More background discussion about the “autoflow” phone call scheduled for later that day. Call concludes that a new spreadsheet defining the fields will be sent out.

Observations: This is just the tip of the iceberg in terms of time and space that will be required as sites migrate to EMR. It will take lots of TIME – you’ve made this point repeatedly. The bigger the organization, the more features they have in their product, the more people become involved and the more complex the conversion process can become.

Converting Data from Old EMR to New EMR

Posted on August 20, 2009 I Written By

John Lynn is the Founder of the blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of and John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

There was a lot of interesting response to my article on replacing an EMR. I actually got an email response that I believe is a really interesting read about one EMR vendors take on the challenges of converting the data from an old EMR to a new EMR. Here’s the email response (with old EMR vendor name removed since it could have been any EMR):

Interesting article. This is where I live each and every day.

Most recently, I’ve switched a client from [current EMR Vendor] to our product Red Planet. The price tag on upgrading [current EMR Vendor] was too prohibitive and they were already familiar with us since we were doing the PMS. So, we already had a foot in the door.

There were two challenges: 1) Converting the data. 2) Converting the culture.

The data was not easily accessible, even through it was SQL based. It was just hand-to-hand combat learning where/how the data was stored and then extracting. The real issue is that you don’t know that you got all of it. You bring up a visit on the new system, and it looks complete until you read some of the fine detail and discover it dropped the last 1/5 of a sentence. I’d scratch my head, go back and do extensive research, find the culprit, run another conversion and we would inch forward. This was extended over a 6 month period. It isn’t like converting a PMS where you know the receivables is X dollars and you can balance to the penny. There is no equivalent “penny” in the EMR and no one has the time to look at every nook and cranny of every note, shot record, lab result, image, or order. So when it looks close, you go for it.

An EMR imposes a culture on an organization. The staff, for instance, would continually ask me how they “suspend” a note so someone else could work on it. “Well, in Red Planet, we don’t do a suspend. There is no need,” would be my response. They would shake their heads, and try to wrap their minds around this new concept. I would watch them do things on their old system that I thought were tedious, non-intuitive, and very prone to error. I would then show them things in Red Planet and they would say to me it was tedious, non-intuitive, and very prone to error.

Now, when they were right about something being cumbersome, I at least have the ability to re-tool a process or function. In the end I’ve been able to capitalize on the things that were good from [their old EMR Vendor] and enhanced our product. I’m a fanatic for speed and accuracy, so being superior to what they had is an obsession.