Whenever we talk about health care interoperability with other interoperability “experts," hundreds (maybe thousands) of acronyms — ANSI, ERA, PIX, VPN, FHIR, HL7, XDS.b — start flying around. These are technical standards that were created to make information exchange easier for health IT developers, payers, providers, and patients — but this is not where an interoperability conversation should begin. Talking about specific exchange standards is overwhelming, and five steps ahead of where we should start. So I’ll begin here by answering the most basic question: What does interoperability really mean?
But even that’s not an easy question to answer. In many ways, the entire health care industry is still wrestling with establishing definitions and coming to consensus on standards. But first, a definition, from the HIMSS Board of Directors:
In healthcare, interoperability is the ability of different information technology systems and software applications to communicate, exchange data, and use the information that has been exchanged. Data exchange schema and standards should permit data to be shared across clinicians, lab, hospital, pharmacy, and patient regardless of the application or application vendor. April 5th, 2013
So when you want to send vaccine activity to a state registry, interoperability enables that to work. When you view clinical data from another EHR, interoperability is making that work. And when you use solutions that aren’t directly built into your health IT service, interoperability is enabling that to work as well. But across the industry, there is a confusing — and rather enormous — variety of exchange standards that are used and sometimes mandated, depending upon the type of information you’re sending, and perhaps who you’re sending it to.
From my perspective, the most important part of the HIMSS definition is “use the information.” Whichever technical standard is used, the focus of interoperability should always remain on the task the consumer or client needs to get done — this has to trump the acronym alphabet soup of standards that attempt to describe how interoperability can be enabled, which can often distract from the real client need. One could potentially avoid established standards, or even fax and manual effort…. and still accomplish a client interoperability need.
Why do we have multiple “technical standards” and a lack of consensus on these standards? Again, there’s no easy answer.
One of the big reasons is that historically the largest players in health care IT haven’t had incentive to collaborate with others on a common set of standards. In the absence of consensus, providers turn to “one-stop shop” vendors that provide suites of compatible products for any given clients’ system.
This accomplishes the client’s need to interoperate, but only within their own system. It does not guarantee communication to external systems, which is what real interoperability is all about. Without an incentive to communicate externally, providers have placed limited pressure on HIT vendors to actually interoperate.
Here’s just a small sampling of standards organizations that exist (this doesn’t even include government-sponsored standards committees), courtesy of motorcycle guy, Keith W. Boone, leading health care interoperability expert. Keep in mind: These are just each organization’s acronyms and not the hundreds of acronyms that each of them creates:
- Health Level Seven International (HL7)
- Digital Imaging and Communication in Medicine (DICOM)
- Accredited Standards Committee (ASC) X12
- National Council for Prescription Drug Programs (NCPDP)
- Regienstrief (LOINC)
- International Health Terminology SDO (IHTSDO)
- International Standards Organization (ISO)
- ASTM International (ASTM)
- Institute of Electrical and Electronics Engineers (IEEE)
- Integrating the Healthcare Enterprise (IHE)
- Continua Health Alliance
- ONC Standards and Interoperability Framework (S&I) [EHR]
It’s a lot. And the lack of consensus is somehow supposed to make it easier to exchange health care information? The folks who create and lead these organizations have the best intentions, but what each lacks a large enough quorum of the largest HIT players, meaningfully focused on implementing these standards in a consistent way.
Despite the differing technical standards, there are a few small pockets where they are uniform, such as the electronic exchange of administrative and financial health care transactions, primarily between health care providers and insurance plans. But this is more the exception than the rule.
How do health care IT companies think about interoperability? Most consider it an add-on to their software, and charge extra for electronic information exchange. In cases like these, the health care provider has several options:
- Buy an additional Health Information Exchange (HIE) “module” from the vendor.
- Purchase a third-party HIE from another vendor.
- Hire an internal development team to create electronic interoperability.
- Pay their vendor extra to customize a one-off point-to-point integration.
That’s confusing enough for anyone, but here’s the worst part: The burden is on the provider to understand each option, its costs and what standards it supports. And this puts a wholly unnecessary strain on the provider or practice.
When we talk about interoperability at athenahealth we focus on the “job,” as Clayton Christensen puts it, achieving the one thing the client needs done, regardless of standard or environment. It’s simply what we do. By addressing interoperability in this way, we remove the burden from the provider while meeting their immediate needs.
Yes, we use and support the widest range of standards (like those created by the organizations listed above) and we’re able to talk to vendors and clients about them when asked. But we begin by knowing exactly what “job” our client wants done, and then driving that result with our combination of cloud-based software, network knowledge and administrative work. This is interoperability as part of our service — not a separate invoice of add-ons.