EHR Data Extraction and Clinical Conversion

I think it’s quite easy to predict that 3-5 years from now, one of the top topics on this blog and in the EHR world as a whole is going to be around EHR data extraction or if you prefer EMR data conversion. I’ve previously predicted that by the end of the EHR stimulus money we’re be lucky to achieve 50% EHR adoption. So, you’d think that in 3-5 years we’d still be talking about EHR selection and implementation. Certainly, that will still be a topic of discussion. Not to mention, which EHR vendor they should go to for their second EHR. However, I am certain that 3-5 years from now we’re going to see a mass of doctors switching EHR vendors.

As part of my EHR blog week challenge (if you’re a blogger, you should participate too), today I’m going to highlight one of the foremost EHR professional and technical services company’s blog, Galen Healthcare Solutions which focuses on EHR data conversion.

I know I’ve written about EMR data conversion a number of times before. Although, I haven’t written about it much for quite a while. I guess meaningful use and the EHR incentive money has kind of dominated the conversation. However, there’s much that can and should be said about EHR data conversion.

The first thing anyone should know about EHR data conversion is that it’s not easy. In fact, it’s quite frankly an incredibly painful experience in almost every regard. Just take a look at this blog post summary of the EHR Clinical data conversion process by Justin Campbell of Galen Healthcare Solutions. He summarizes the steps as follows:
* Data Extraction
* Data Analysis: Cross-Referencing
* Design: Data Filtering, Matching (Provider, Patient Item), and Exceptions/Errors
* Testing
* Go-Live

I believe the most challenging item on this list is likely the Data Extraction. Sure, the data analysis and design are a pain to do and do well. However, the data extraction is often the most difficult part of an EHR data conversion, because you’re often working with an unfriendly EHR vendor that has lost you as a customer. Unfortunately, many EHR vendors haven’t heeded my call for EHR data independence, and so it can be a miserable experience trying to get the information and access you need to do an EHR data conversion. In some cases the EHR vendors will try and hold that data hostage.

The key for those selecting an EHR software is to be sure that the process for exporting your data from the EHR is part of your EHR contract. If it’s not, then add it to your contract. If they won’t add it to your contract, there are 300+ EHR vendors to choose from. Certainly it’s a part of the EHR contract that you hope to never have to use. Don’t take that risk.

Justin Campbell has also posted a few different data conversion success stories on the Galen Healthcare Solutions blog. Obviously, Galen has a lot of experience with the Allscripts Professional EHR software and so you’ll note this bias throughout the blog. However, the experience of the conversion is very interesting.

Here’s a paragraph from one of their data conversion success stories: Azalea Orthopedics.

To facilitate this conversion, flat-file extracts were obtained from MedManager for dictionaries, demographics and appointments. However, instead of using these extracts to import into Allscripts PM, an alternative approach was taken in which real-time appointment and demographic interfaces were deployed from the client’s existing Allscripts Enterprise EHR to the new Allscripts PM environment. This offered the flexibility of having the PM data populate real-time. Interfaces were also required from Allscripts PM to Allscripts Enterprise EHR. Thus as part of the go-live, existing reg/sched interfaces from MedManager to Allscripts Enterprise EHR needed to be deployed.

I have to admit that this kind of complexity in healthcare is what drives so many doctors nuts. I’m sure there were some functional reasons that they had to do all these interfaces between the systems. What I don’t understand is why the interfaces need to stay in place after the conversion is complete (at least if I understand it correctly). Did Galen really have to implement an interface between Allscripts PM and Allscripts Enterprise EHR? I’m sure there’s some long history for why this has to happen, but it’s such a terrible design. Certainly this isn’t Galen’s fault, but Allscripts. Interfaces are really great….when they work. When they don’t work, they drive a clinic, the IT person and even the EHR vendor absolutely nuts. I’ll be interested to learn more from Galen about why they did what they did.

I did find their report on the number of transactions processed fascinating:
Demographics: 156,900 processed in 491 minutes (8.18 hours)
Appointments; 313,280 processed in 1570 minutes (26.17 hours)

That’s a lot of data being processed. Can you imagine having to run the 26 hour data conversion twice if you messed it up the first time? Yep, data conversion is a tricky thing and can be very time consuming if you’re not really thorough in the process.

Imagine how much data will be collected 5 years from now with all these EHR implementations happening. Plus, the above data was only appointments and demographics. It doesn’t even include the physicians charting and other clinical data.

About the author

John Lynn

John Lynn is the Founder of HealthcareScene.com, a network of leading Healthcare IT resources. The flagship blog, Healthcare IT Today, contains over 13,000 articles with over half of the articles written by John. These EMR and Healthcare IT related articles have been viewed over 20 million times.

John manages Healthcare IT Central, the leading career Health IT job board. He also organizes the first of its kind conference and community focused on healthcare marketing, Healthcare and IT Marketing Conference, and a healthcare IT conference, EXPO.health, focused on practical healthcare IT innovation. John is an advisor to multiple healthcare IT companies. John is highly involved in social media, and in addition to his blogs can be found on Twitter: @techguy.

13 Comments

  • Of course, in the future, we will return to the idea of switching EHRs.

    BUT – for those who only stood up an EHR because of the incentive money…I don’t see them switching unless they truly bombed in their initial (rushed) choice…which is highly plausible.

    Additionally, you might see those who are doing a “quick attest” by glomming onto a free EHR switching to something else when things settle down.

    About 3 years ago, before any of this craziness began, I was dealing with practices switching either EHR or PM.

    Yes, in the olden days, it was “normal” that an EHR was just that, and EHR.

    A practice usually had a PM well before an EHR as a PM truly showed an ROI and made things easier.

    Getting different brand EHR & PM to talk was a challenge.

    Then when a switch came along, it, too was a challenge, but a challenge for the new EHR. The data conversion was part of the sales process.

    In short, yes there will be those who switch to different EHRs, but that data conversion will be less of a concern for the practice and more a concern for the new EHR.

  • John,

    Thanks so much for your kind words. We so very appreciate you highlighting our hard work on your blog and are flattered by the write-up.

    That said, I wanted to address a couple of the points you made in the article, but let me start by first addressing one:

    1. Point-to-point interfaces:
    I don’t think these are going away any time soon as crazy as that sounds. When we will ever move away from the inefficiencies of point to point and get to a point of the hub and spoke model for the integration of orders, results, immunziations, etc. is anyone’s guess, but I still believe to be a long ways away.

    This is frustrating part is that the API for each EHR is different. A common API may be a big first step in getting to the hub and spoke model. I mused on this exact topic, proposing an Allscripts integration API re-design to separate the data component from the configuration components of the integration: http://blog.galenhealthcare.com/2010/09/15/proposing-an-allscripts-clinical-application-programming-interface-re-design/

    Additionally, in the scenario of a practice switching systems, this requires new interfaces to be deployed if the systems are different vendors (and even if they are the same vendor!!! – Allscripts has yet to offer seamless integration between its AEPM and AE-EHR offering). These additive costs must be taken into account when evaluating a conversion.

    I think as you pointed out in a previous article John, https://www.healthcareittoday.com/2011/06/10/ehr-vendor-consolidation/, as we see the industry consolidate, we are going to see a spike in conversions. Whether or not the acquiring vendor will take care of these conversions or whether it will be left up to the client remains to be seen, but I agree with John in that I predict a large number of conversions in the next couple of years as part of this consolidation.

    -Justin

  • As an Allscripts PM user I can assure you that the only way the Allscripts PM talks to the Allscripts EHR (Enterprise or Professional versions) is through an interface. And it is only a one way interface. The PM shoots over schedule, demographic and referring physician data. The EHR can be set up to return charges and ICD-9s, but nothing else. So if a patient forgets to tell the check-in person that their address has changed, but remembers to tell the nurse, that has to be communicated back to the check-in or the nurse has to leave the EMR environment and enter the data into the PM, in order to make sure that both systems are operational.
    The lack of an integrated system with Allscripts PM and EHR systems truly drives users crazy. Now add in the need for reporting for MU and you can imagine some of the challenges facing Administrators trying to meet MU. Instead of one system being able to report all the data, you have to work within two environments. I can tell you that I am hopeful that Allscripts will eventually get the systems integrated, but it is obviously way down on their priotiy list since figuring out how to integrate the multiple companies they have purchased is obviously taking first priority.

  • John Brewer,
    I have to partially disagree with you on most of those that did EHR for incentive money not switching. I predict many of them will hate the EHR system they felt “forced” to buy and will do better the second time.

    Justin and Mary,
    Your comments about Allscripts E EHR not being integrated with the PM is a bit disturbing for me. How tight is the integration? From Mary’s description, it sounds pretty limited.

    This line from Mary is what I’ve experienced with these type interfaces, “The lack of an integrated system with Allscripts PM and EHR systems truly drives users crazy.”

    There’s some situations that can pull off a separate PM and EMR. However, they are pretty rare and require a unique situation.

  • John,

    Allscripts Enterprise EHR is not as tightly integrated as it should be. It still requires a point-to-point interface needing configuration for connectivity and options (patient matching criterion – http://wiki.galenhealthcare.com/Patient_Matching_Criteria, dictionary auto-synchronization – http://wiki.galenhealthcare.com/Bulk_Load, etc.) I think the expectation of most clients would be that the integration is seamless, requiring no effort. Although clients aren’t typically charged for the interface between AEPM to AE-EHR, it still consumes client resources for implementation. One advantage to this approach is that it offers the clients the capability of “tuning” the interface to their specific needs.

    An obstacle exists in the fact that the PM system (COM+) and the EHR (.NET) are built on different technology stacks. Adding additional complexity is the fact that both have different interface engines (Allscripts Interface engine for AEPM and ConnectR for AE-EHR).

    -Justin

  • Mary,

    Our clinic was one of the first to go live with Pro PM ( A4 Ntierprise at the time) and Enterprise EHR. In fact, we switched PM systems specifically because we were told that it was going to be integrated with the E EHR. However, I was talking to an Allscripts PM tech last week, and was told that there is currently no plan to integrate the two products. From my understanding, Pro PM is going to be integrated with Pro EHR, not E EHR.

    There is a big disconnect between the Pro PM and the E EHR sides. We just upgraded our PM last week, and the upgrade tech didn’t even know what ConnectR was (I had to make the changes myself). I don’t know that all hopes of a unified product are dead, but I wouldn’t look for them in this decade…

  • John Riley,
    I have another thread that talks about Allscripts lack of integration between their various PM and EHR products. It’s amazing to think that even software within the same company can’t interact. Is it any wonder that we have a challenge doing so with multiple EHR companies.

  • Allscripts is pretty frankenstenian, it’s a conglomeration of many prior companies. The above person who stated the limited interface between PM/EHR is correct, I develop and maintain those interfaces on the enterprise side, it is HL7 only. This is due to the fact that they cobbled together a solution and relied on HL7 to fill in the gaps. Add that to very poor training at Allscripts (i worked there previously as a support tech), my prediction is in 2015 people are going to either drop EHR and just go back to PM, or find someone besides AS because the support sucks and the product is not all that great.

  • Rob,
    So you work at Allscripts developing and maintaining their interfaces? Then, you make some of the comments you do. Something’s not right with that. Maybe you could clarify.

    You act like it’s pretty easy for someone to just drop EHR. What makes you think that people will do that? It’s not as easy as changing your socks.

  • Worked past tense. I left after 2 months. I work at a hospital with their ambulatory care program which uses PM/EEHR. Yes i think people will drop EHR, especially those who were fine in their practice without it. What does it give you? Charting, labs, maybe ERx. As a clinician you can write things down. Its just based on what I’ve seen and my opinion of course. Considering the drop in efficiency, it may be the smart thing to do after all.

  • Talk of dropping EHR is just ridiculous. If an EHR is setup right, an EHR saves providers and staff significant time. Having an EHR has made our clinic far more productive. I want companies (like Allscripts) to change because I know that the productivity gain can be even better. The problem is not with the concept of electronic medical records, it is with the implementation (both software and end client setup).

    What needs to happen is someone with enough financial backing to get it done right needs to create a single unified platform designed from the ground up to include EHR, PM, LIS, PACS/RIS, secure digital communication to outside providers, and a patient portal. That company needs to provide complete IT training at a reasonable cost in order to help local IT be able to handle their own issues. And, since I’m already asking a lot, I’d also like it to be open source, but not feel/look like open source. Making the perfect app is impossible, but I think we can do far better than what is out there right now (refereeing specifically to the ambulatory market).

  • John Riley,
    I’m not sure talk of dropping EHR is that ridiculous. Although, I disagree that they’ll drop an EHR and go back to paper. I’ve heard a number of EHR vendors say their best customers are those that have implemented an EHR and hated it. I think this is the more common path: replacing an EHR with another EHR. Yes, this kind of makes me sick to think about too since you can imagine the lost time and money from the first EHR, but it’s a common reality.

    “I’d also like it to be open source, but not feel/look like open source.”
    This does seem to be part of the problem with open source EMR lately. Plus, I really haven’t heard much from them lately either. Part of this makes since because it’s open source, but every open source project still needs a face (or multiple faces) that speak about it. There aren’t many in the open source EMR world.

  • EHR vendor consolidation and churn is driving explosive growth in the Clinical Data Consolidation business.

    While Open Source EHR’s give programmers the flexibility to manipulate software the real issue in data conversions is the classic RDBMS data structures because the schema’s are just too different among the 2000+ vendors.

    If your EHR vendor simply goes out of business how will you comply with the 7-12yr requirement to maintain medical records for your state? Your clinical data is now stuck inside an old system with no way out.

    The best solution is to select an EHR Vendor that always stores all Clinical Data in an open and common machine readable formats that support mixed content (Excel, Word, Access, XML, CSV, .DCM, .JPG, .TIF, etc..) organized by Patient Folder so that no matter what happens in the future, you’ll always be able to easily read, copy, paste, print, mail your medical records.

    Also nothing prevents you from reading this data into any future Database for reporting, or analysis or clinical studies as necessary.

    Archiving is also easy, just move the Deceased or inactive patient folders to mass storage.

    Just think if all EHR Vendors used this simple Clinical data storage strategy then Data Conversions would be very close to Copy and Paste… Uploads to Patient Portals would be simple. The longevity of your vendor would be insignificant. Nearly anyone could manipulate the data, not just programmers. You would actually have total control over your data.

Click here to post a comment
   

Categories