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.
John,
I agree with the reader in that it is important to emphasize the complexity involved with such an undertaking. For instance, the primary EHR I consult for – the Allscripts Enterprise EHR – exhibits database complexity. There are 14 databases that make up the AE EHR. The most common and complex of which is “Works”, the primary clinical database. There are 1,150 tables and 560,000 lines of code over 3,200 stored procedures, 550 views and 200 functions. That said, the most critical issue regarding conversions seems to be in regards to patient matching. I’d be interested to hear any discrepancies the reader noted in patient matching and patient identifiers between the two vendor systems. More information regarding the patient matching criteria for the AE-EHR can be found here: http://wiki.galenhealthcare.com/Patient_Matching_Criteria.
-Justin
The EHR companies need to take a page out of the Enterprise software guys’ book, and learn how to design tables and databases.
Justin,
Thanks for the insight that is the beast that is Allscripts EMR. I’m kind of amazed that they split it up into 14 databases. Interesting. Considering the other numbers you said it’s no wonder that they can’t be nimble in their development.
Oh yes, and patient matching is the difficult part. I’ll see if the person that sent me the story can provide insight on it.
Lincoln,
What do you think that Enterprise software does that EMR software should emulate?
John, That could have been my clients this past August! I sat in their office while the exact thing happened, only it took the vendor an entire day to finally get the right people on the conference call to solve the problem. The moral of the story: Sometimes bigger companies aren’t always better. Smaller vendors tend to provide better customer service with less layers of people to deal with.
John,
I wrote a blog article sharing a recent experience Galen Healthcare Solutions had with data conversion: http://blog.galenhealthcare.com/2009/12/08/legacy-data-conversion-fuzzy-patient-matching-to-the-ehr/. Specifically, a fuzzy matching algorithm was utilized to match legacy patient records from data silo successfully in the EHR. I’d be interested to hear others “outside-of-the-box” approach to EHR data conversion.
Its quite simple actually. If you are moving from one EMR to another and want all your demographic and Clinical Data to move with you to the new EMR, just call on these guys:
http://www.ellkay.com
I am a consultant with a lot of Practices as my clients. They pitched me that they can convert from any EMR to EMR…and damned if they weren’t right. 10 clients I have passed to them so far, each one converted without even a tiny hiccup. What can I say? If I am bragging for them, its because they’ve always made me look good.
John Markson,
Thanks for sharing. I’ve seen the Ellkay name around for quite a while, so I think they do have some good domain expertise. Otherwise, they wouldn’t have survived. I expect they’re going to have more and more business as we go along.