Achieving Precision in Healthcare Integration without Sacrificing Agility

With contributions from Jason Bloomberg.

Nowhere is semantic precision as important as it is in the healthcare industry, where a single misunderstood utterance or code might put a person’s life in jeopardy. In fact, precision has historically been so important in health IT that it has always trumped agility as a priority for integrating distributed systems. We’d better hardwire our integrations, the conventional wisdom goes, because that’s the only way to guarantee a high standard of patient care.

Tragically, this conventional wisdom has turned out to be entirely false. Generations of inflexible technology have disillusioned healthcare providers, who either shun the latest shiny widget from the IT department, or even worse, misuse it, for example, by cramming custom data into “comment” fields because the structured input on the screen doesn’t meet clinical requirements.

The primary reason technology has been unable to solve this problem is basically because at its core, semantic integration isn’t really about technology. It’s a human communication problem. Even today’s fastest supercomputers can’t understand the meaning of words. Computers think in zeroes and ones, while human meaning is context sensitive, variable, and often ambiguous—even in healthcare.

Traditional integration approaches cannot deal with such vagaries, but agile architectural approaches like Service-Oriented Architecture (SOA) can—but only in conjunction with robust standard semantic models and frameworks that codify the human meaning behind the data. These models and frameworks must bring the precision, while SOA must bring the agility.

Electronic Health Records: Semantic Battleground

With the steady increase in Electronic Health Record (EHR) adoption in the healthcare industry, finding a reliable, secure, cost-effective method to share information between EHRs is a significant challenge. An ideal solution should be standards-based and comply with federal mandates such as the Health Insurance Portability and Accountability Act (HIPAA). The central consortium responsible for establishing the semantic models for sharing such information is Health Level Seven International (HL7), a standards organization that provides a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information to support clinical practice and the management, delivery, and evaluation of health services. The HL7 standards are intended to provide interoperability among IT systems, in order to improve the delivery of care, optimize workflow, reduce ambiguity, and enhance knowledge transfer among all stakeholders, including healthcare providers, government agencies, vendors, and patients.

HL7 standards cover numerous healthcare-related scenarios. For example, most laboratory and diagnostic systems now deliver results via HL7 messages to hospitals, health insurance companies, and other authorized parties. Such messages carry one record for each test observation, and each of these records contains one field that identifies the test, for example, serum sodium, and another field that reports its value. Such observation records carry other fields for reporting the units of measure and other information. The field that carries the observation identifier is OBX-3, and the field that carries the observation value is called OBX-5.

This message structure alone, however, doesn’t provide sufficient semantic information. Many labs send their own idiosyncratic codes in OBX-3 to identify the observation: one laboratory would identify serum sodium with the one code and another lab would use a different code. Such an extreme degree of variation would be a huge barrier to the development of clinical repositories and research databases in the absence of a universal code system for tests that every stakeholder would agree to use.

Furthermore, with each laboratory having its own unique code for every test observation, point-to-point integration becomes an expensive challenge. To address this issue, we implemented a terminology Service that normalizes all of these idiosyncratic codes to codes that follow a set of open standards, including the standard known as Logical Observation Identifier Names and Codes (LOINC). LOINC offers a universal code system for reporting laboratory and other clinical observations. With LOINC, it’s possible to identify observations in electronic messages such as HL7 observation messages, so that when stakeholders receive such messages from multiple sources, they can automatically file the results in the right fields of the EHRs and other forms, thus resolving semantic ambiguities.

However, HL7 message semantics and LOINC are still only a part of the answer. Interoperability is also essential. In a clinical setting, reliable, timely, and accurate information sharing has a direct impact on patient safety. One of the big challenges when integrating heterogeneous healthcare systems is that patient demographics and clinical data reside in a variety of legacy systems. The challenge now becomes how to provide semantically correct data to each system that participates in the data exchange in a way that doesn’t limit flexibility.

The Service-Oriented Approach to Health Information Integration

In order to address this agility challenge, the first order of business is to build an abstraction layer by creating detailed interface control documents that document the input/output requirements and mechanisms for each system participating in the integration. Second, wrap all legacy data interfaces with Web Services. The primary function of these Services is to loosely couple the legacy APIs from Service interactions at the Service intermediary. This loose coupling reduces the cost of changes over time, including revisions in the semantic models, the addition of new use cases, and the ability to phase out the underlying legacy systems.

Third, the heart of the integration is to implement a translation layer between the legacy interfaces with the canonical data defined in the Web Service using medical data standards such as LOINC, which serves as an additional abstraction layer, further increasing the ability of the system to respond to change over time.To simplify the integration, we took a message-oriented approach centered on the Enterprise Service Bus (ESB), which served as the intermediary for our project.

As part of this approach, we leveraged the integration profiles defined by the Integrating the Healthcare Enterprise (IHE) Technical Framework. IHE simplifies and standardizes the integration of healthcare systems by defining a technical framework for implementing established messaging standards to achieve specific clinical goals. IHE doesn’t actually define new integration standards, but rather supports the use of existing standards including HL7 as appropriate, defining configuration choices when necessary. Implementing the translation layer using IHE, HL7, LOINC, and other standards provided a level of abstraction that was critical to the success of the project.

As with all ESBs on the market, our ESB supported XML natively. However, HL7 messages are in a compact, non-XML format. Since we were following a message-oriented pattern based on HL7, The ESB also had to support XML Style Sheet Transformations (XSLT) and XPath processing for flexible data transformations. We also needed an HL7 validating parser to validate the message and extract the relevant information.

Furthermore, to support content-based routing, we achieved a performance increase by querying the messages natively using XPath. The ESB must then route messages from each clinical application correctly to the target system. We leveraged HL7 message headers to apply the necessary content-based routing patterns, allowing the routing of messages to any system (either internal or external) based upon either the message content or message headers.

We used both XPath and XQuery to process the headers to achieve both point-to-point and one-to-many routing scenarios within the ESB. The ESB also stored message transactions in message queues using different messaging patterns (asynchronous and synchronous messaging, publish and subscribe, store and forward, for example) and supported message sequencing in order to deliver the HL7 messages to the clinical applications in the order they arrived at the ESB.

The ZapThink Take

The traditional integrator thinks about connecting things, while the SOA-based integrator thinks about changing things. In this example, the goal of each abstraction layer is not only to hide complexity, but also to support change over time. For example, the terminology Service not only translates between standards like LOINC and underlying proprietary coding schemes, it also supports the ability for such standards to evolve. They don’t change very often, but change they will. Change is unavoidable, especially in the context of human understanding of meaning.

The ESB itself provides an additional layer of abstraction via transformations and content-based routing—two types of operations that are both metadata-driven. As a result, as the HL7 semantic models improve, the integration behavior on the ESB can dynamically change via straightforward changes in configuration. The ESB is unable to replace the human activity of maintaining the semantic models, but it is able to dynamically respond to the changes as necessary to provide agility, while the semantic models continue the never-ending battle to be increasingly precise.

Photo by tiarescott.