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!!

EHR Data Hostage Wouldn’t Exist if EHR Were Truly Interoperable

Posted on October 20, 2015 I Written By

John Lynn is the Founder of the HealthcareScene.com 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 InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

I was recently talking with Mario Hyland, Founder and Senior Vice President of AEGIS (or better known on social media as @interopguy), about various healthcare IT certifications and really a follow up discussion to our previous look at achieving continuous healthcare interoperability. Next month I’ll be launching the Healthcare Scene podcast and I’ve invited Mario to join me as a guest. So, more to come on EHR testing in the future.

However, as we were discussing my vision for what would be a “meaningful EHR certification” I suggested that it would be meaningful to doctors if an EHR vendor was certified as able to export all of the EHR data. It would be meaningful to doctors if an EHR vendor’s contract was certified to not hold EHR data hostage if a doctor chooses to go to another EHR. I think many EHR vendors would do it as a way to instill trust in the doctors who choose their EHR (Translation: We’re so certain you’ll love our EHR that we’ve made it possible for you to leave our EHR if you want to leave).

As I recounted this idea and others, Mario Hyland made a great observation: If EHR software were truly interoperable, an EHR vendor couldn’t hold a practice’s EHR data hostage.

Think about the concept. If there was true EHR interoperability, you could just buy a new EHR, connect it to your old EHR, and all the data would be available in the new EHR. We’re not even close to getting there yet, but the concept is right.

One challenge is that in practice, we’re only sharing a small subset of the data in the EHR. Even if we got the entire medical chart interoperable, there’s still a bunch of other data in an EHR that would be beneficial to retain. For example, things like audit logs from the old EHR might come in valuable if an old record comes under scrutiny in some legal case.

I still love the concept. I also think it’s one extra reason why we don’t see EHR vendors running towards interoperability. I only know a few EHR vendors that have enough trust in the EHR software they’ve built that they’d be ok building the functionality for their doctors to leave.

How Do We Achieve Continuous Healthcare Interoperability?

Posted on February 2, 2015 I Written By

John Lynn is the Founder of the HealthcareScene.com 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 InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

Today I had a really interesting chat about healthcare interoperability with Mario Hyland, Founder of AEGIS. I’m looking at a number of ways that Mario and I can work together to move healthcare interoperability forward. We’ll probably start with a video hangout with Mario and then expand from there.

Until then, I was struck by something Mario said in our conversation: “Healthcare interoperability is not a point in time. You can be interoperable today and then not be tomorrow.

This really resonated with me and no doubt resonates with doctors and hospitals who have an interface with some other medical organization. You know how easy it is for your interface to break. It’s never intentional, but these software are so large and complex that someone will make a change and not realize the impact that change will have across all your connections. As I wrote on Hospital EMR and EHR, API’s are Hard!

Currently we don’t even have a bunch of complex APIs with hundreds of companies connecting to the EHR. We’re lucky if an EHR has a lab interface, ePrescribing, maybe a radiology interface, and maybe a connection to a local hospital. Now imagine the issues that crop up when you’re connecting to hundreds of companies and systems. Mario was right when he told me, “Healthcare thinks we’re dealing with the complex challenges of healthcare interoperability. Healthcare doesn’t know the interoperability challenges that still wait for them and they’re so much more complex than what we’re dealing with today.”

I don’t want to say this as discouragement, but it should encourage us to be really thoughtful about how we handle healthcare interoperability so it can scale up. The title of this post asks a tough question that isn’t being solved by our current one time approach to certification. How do we achieve continuous healthcare interoperability that won’t break on the next upgrade cycle?

I asked Mario why the current EHR certification process hasn’t been able to solve this problem and he said that current EHR certification is more of a one time visual inspection of interoperability. Unfortunately it doesn’t include a single testing platform that really tests an EHR against a specific interoperability standard, let alone ongoing tests to make sure that any changes to the EHR don’t affect future interoperability.

I’ve long chewed on why it is that we can have a “standard” for interoperability, but unfortunately that doesn’t mean that EHR systems can actually interoperate. I’ve heard people tell me that there are flavors of the standard and each organization has a different flavor. I’ve seen this, but what I’ve found is that there are different interpretations of the same standard. When you dig into the details of any standard, you can see how it’s easy for an organization to interpret a standard multiple ways.

In my post API’s are Hard, the article that is linked talks about the written promise and the behavioral promise of an API. The same thing applies to a healthcare interoperability standard. There’s the documented standard (written promise), and then there’s the way the EHR implements the standard (behavioral promise).

In the API world, one company creates the API and so you have one behavioral promise to those who use it. Even with one company, tracking the behavioral promise can be a challenge. In the EHR world, each EHR vendor has implemented interoperability according to their own interpretation of the standard and so there are 300+ behavioral promises that have to be tracked and considered. One from each company and heaven help us if and when a company changes that behavioral promise. It’s impossible to keep up with and explains one reason why healthcare intoperability isn’t a reality today.

What’s the solution? One solution is to create a set of standard test scripts that can be tested against by any EHR vendor on an ongoing basis. This way any EHR vendor can test the interoperability functionality of their application throughout their development cycle. Ideally these test scripts would be offered in an open source manner which would allow multiple contributors to continue to provide feedback and improve the test scripts as errors in the test scripts are found. Yes, it’s just the nature of any standard and testing of that standard that exceptions and errors will be found that need to be addressed and improved.

I mentioned that I was really interested in diving in deeper to healthcare interoperability. I still have a lot more deeper to go, but consider this the first toe dip into the healthcare interoperability waters. I really want to see this problem solved.