The Road to Healthcare Interoperability Paved with Standards! Why Aren’t We There Yet?
The harsh reality – Healthcare IT systems will never all speak the same language!
Astonishing! “Health data (volume) is doubling every 18 months”, per Tina Brown-Stevens at the 2012 StrataRX conference. I’m not sure the description “exponential” even covers that growth rate and its implications. Data, data everywhere, but what do we do with it?
To utilize data we need to connect the dots, i.e., connect the data by facilitating data exchange between systems, applications, databases, and medical equipment and devices. That’s where interoperability standards fit in. Standards provide the building blocks for creating functional interfaces between disparate systems.
How many healthcare standards do we really need?
Standards organizations have proliferated since the mid-1980s. The American Health Information Management Association (AHiMA) identified at least 40 organizations currently creating healthcare IT standards. And they run the gamut. Per the AHiMA, “Some of these organizations are sanctioned by governing bodies, such as the American National Standards Institute (ANSI) in the US. Other standards are self-proclaimed but use formal processes for creating and balloting standards.”
Standards organizations are typically formed when an individual or group decides there is an unmet need, or that they can create a better standard. Often the origin is a small working group.
Take for example the Health Level 7 (HL7) standard which was initially developed to transfer clinical and administrative data between hospital information systems. “The HL7 protocol dates back to the late 1970s when its precursor was developed at the University of California at San Francisco (UCSF) Medical Center and first implemented in production in 1981. HL7 v1 and v2 are essentially refinements of the UCSF protocol. X12 and ASTM E1238 have had a large impact on the development of HL7. The HL7 organization matured from a small ad hoc working group in 1987 into a full-blown standards development organization within its first 5 years.” (Ringholm White Paper)
In the U.S., HL7 has become the de facto means of moving healthcare data. However, it is far from the only means. Patient demographic information is usually transferred using ADT messages, while it is ORM for orders and SIU for scheduling. Yet another standard, NCPDP, has arisen for pharmacy.
New technologies necessitate new standards, e.g., mobile devices, mHealth, as it has come to be known, is rapidly gaining a foothold in healthcare and also has very specific requirements. Sometimes existing standards can be extended to support new requirements, other times not.
Historically, there has been little collaboration between standards organizations, thus further fueling the proliferation of standards.
Why can’t standards guarantee a perfect interoperable world?
The scope of requirements for different systems and applications generally has necessitated extending standards to meet a system’s, or application’s particular requirement. These additional requirements often result in the creation of non-standards compliant messages. As a vendor, we see this all the time. In fact, a very large percentage of the HL7 messages our clients have us working with are non-standards compliant. While these non-standards compliant messages do pose significant challenges, there are ways to deal with them technically.
Our approach with HL7 was to create a more Lenient HL7 parser. With it users can parse unknown segments, capturing the data for subsequent transformation and manipulation. Using the Lenient HL7 Parser, organizations can work with messages that do not strictly comply with HL7 standards.
When it came to EDI formats, we created an EDI Format Reader to deal with EDI messages where the open source parser did not suit our clients’ requirements. EDI, Electronic Data Interchange, is an electronic communication system that offers standards for exchanging data via any electronic means. EDI standards include X12, EDIFACT, ODETTE, etc., which address the needs of specific industries. So you see, there are workarounds.
While standards will never give us a perfectly interoperable world, we have moved a lot closer. When we accept that Heath IT systems will never all use the same standard, or that these standards need to be extended in order to be useful to serve the diverse requirements in healthcare, the role of middleware, or interface engines becomes evident. Interface engines mediate the differences in not only data formats and standards, but also in communications protocols. By embracing interface engines as part of the solution to interoperability, we can all benefit from an interoperable healthcare world.