EHRs and Interoperability: Back to the Drawing Board

Over the past few weeks I've been wondering what interoperability really is. As I listen to what is said about it I detect not a single consensus definition, but at least three different concepts all clothed in the same name:

A1. The ability to send notes, images, and test results to any practitioner or facility coupled with the ability of the clinicians at the receiving end to view the stuff and, maybe, save it.

A2. The "minimum dataset approach" that has been tried by many specialties over the years. A minimum set is a group of discrete data elements that every member of a specialty organization agrees to collect in accordance with the definitions adopted by the organization. The original impetus for this approach was to allow data to be pooled for research and outcome studies.

A3. The "send and accept everything that exists as, or can be made, a discrete data element" approach. This is an expectation more than it is a strategy because: What is everything? And what happens if part of the "everything" is not quantitative? Perhaps this approach defines "everything" as all of the data needed to implement all of the chapters of the HL7 standard, or perhaps something else. HL7, of course, provides a safety hatch. Anything that you need to send that does not conform to the specifications can simply be wrapped up as a narrative report and dumped at the recipient's door for them to deal with.

This line of reasoning is based on the important but rarely described assumption that senders and receivers are working within the same frame of reference, let's say primary care, and have the same expectation relating to external data and have systems that can map all of the data elements that are going to be exchanged to data elements within their respective databases. If the sender has adopted A1 but the recipient expects A2 then the recipient might not bother to implement an interface to accept A1-style information.

In prenatal care, OB/GYNs need the specific measurements and test results from prior visits to incorporate into their flowchart. Receiving narrative would create an error-prone clerical job for someone at the receiving end. The sender might have reams of quantitative data from a long ICU stay leading them to adopt an A3-style approach including augmenting the HL7 specification with custom messages to carry monitoring data in a way that is convenient for them. The recipient might be a long-term care (LTC) facility that only wants a discharge summary and a list of meds and treatments that they need to administer.

None of this helps to clarify what interoperability means when it comes to exchanging data between senders and recipients working under different care models with radically different data requirements. Consider some of the common settings that have specialized data capture and display needs:
• ER
• OR/Anesthesia
• Outpatient surgery procedures
• Substance abuse clinics
• Mental health
• LTC/Rehab
• OT/PT initial evaluation as well as treatment programs
• Medical specialties: Eye, ENT, Orthopedics, Urology, GI, Oncology, Renal, Medical Genetics
• Pediatrics, for vaccine details, growth charts, 100+ developmental and behavioral assessment forms (most copyrighted and cannot be administered on a computer)
• Other Primary Care

A large integrated healthcare delivery system is going to have to contend with all of the above. Is there a single EHR that can address all of these and meet the specific needs and expectations of each subgroup of practitioners? One can assume that the answer is no because you rarely find a large healthcare organization that has just one system from one vendor. It’s more typical to find a large core system sitting amidst a cluster of specialty applications targeted at those activities important to the organization but that the core EHR could not support.

How many of these organizations actually achieve full interoperability between their own systems? Some do, but many can’t do much more than fake it. Certification doesn’t address this issue because there are a variety of certifications available. Any one will qualify you for the government handout while only addressing a specific setting such as inpatient, or general ambulatory, or LTC. The idea of certification does not offer a mechanism to ensure interoperability between systems certified as different criteria. Is that simply a minor oversight or does how little fundamental thought went into the whole notion in the first place?

Although there is a simple unifying model that would allow all of these products to generate medical record entries that could be read and processed by others, there is hardly a vendor willing to forgo the financial benefits of proprietary lock-in to achieve this objective.

So, what's true for security is true for interoperability (and any other performance [non-functional] requirement) - it cannot be added on, it must be designed in. Current EHRs do not have interoperability designed in and they will never truly live up to expectations until they are redesigned from scratch.

Find out more about Daniel Essin and our other Practice Notes bloggers.