Designing for gray scale: under the hood of medical terminology translation

My last couple posts have touched on the importance of data standards in enabling interoperability in healthcare. It is important to recognize, however, that data standardization is not about dictating the way organizations capture and share clinical data. Often there is specific local and institutional knowledge that is represented in the information of a given healthcare organization, which can't be characterized easily by national data standards. Geographic or cultural phrasing, local eponyms, and lay names are critically important to the local delivery of care. For each participant in a health information network, these nuances in data syntax and semantics are analogous to shades of gray. This "grayscale" presents a set of challenge for participants who need unambiguous, shared understanding of information to enable decision making.

An architecture for Health Information Exchange must accommodate choice and dealing with change - it must be designed for grayscale. This includes choice of medical vocabularies, messaging standards, and other terminology interchange considerations. In my last post I introduced the notion of a Common Terminology Services to deliver a set of capabilities in this space. In this post, I will discuss a technical architecture for enabling this.

Let's start with a simple example: a clinical system in a hospital places an order for a medication to a hospital pharmacy application. To simplify discussion of architecture and system interactions without lots of fancy pictures, I've included a simple model to call out the key actors in this example, and their role and relationships.

CIS = Clinical system in the hospital e.g. CPOE

Rx = Pharmacy application

IA = Integration application, responsible for workflow, data type mapping, and message normalization

CTS = services supporting terminology interchange

The flow begins with the CIS sending an HL7v2.x medication order message to the IA, which normalizes the message to a format understandable by the Rx application. Before sending the message onwards to the Rx application, the message is handed off to the CTS to normalize the coding scheme used for the medication being ordered. At this point, the message has been augmented with the appropriate semantics which can be understood by the Rx application, and contains a set of standard codes that the Rx application can understand in order to fulfill the medication order.

This example seems straightforward enough, but there is some substantial work going on by the CTS actor. First, it's worth mentioning that CTS is actually a set of industry standard interfaces specification created by HL7 to enable vendor-independent access to medical terminology applications. The CTS specification encompasses three categories of terminology services: Messaging, Vocabulary and Translation.

Messaging services are responsible for ensuring a successful handshake with the source system at the application protocol level, handling mediation of vocabulary domains, contexts, value sets, coded attributes and other artifacts of the HL7 message model. These services allow a wide variety of message processing applications (like the IA in the example above) to create, validate and translate HL7 data types in a consistent and reproducible fashion. Vocabulary services communicate with terminology management software, and do so in terms of code systems, concept codes, designations, relationships and other terminology specific entities. Vocabulary services allow applications to query different terminologies in a consistent, well-defined fashion. Finally, CTS Translation services provide the ability to create and deliver mappings – or translations – between concept codes from different code systems.

A single set of CTS services for a healthcare institution would facilitate service-oriented architecture (SOA) interfaces to all applications. That way, the institution could be assured that all mappings were consistent, and it would need to add updates to vocabulary and mappings in only one place. The combination of the CTS functional approach with the reliance on the Integration Application (IA) actor delivers a couple of key advantages. Firstly, interactions between the health information or clinical systems and the terminology interchange application are flexible and loosely coupled, due to the use of the IA to mediate the flow of data. This avoids expensive and complicated changes that might otherwise be required to permit those systems to share data or participate in integrated workflows.

The second advantage is that the CTS provides a common interface and reference model for understanding, so that across a variety of types of healthcare applications, there is a common set of terms when discussing and communicating terminology related concepts in both human and computable environments. This way, applications interfacing with the CTS are not required to know about specific terminology data structures, and more importantly, how to access them. Applications can be developed independently from the terminology service software.

I had intended to dedicate more space to some example applications for terminology exchange in healthcare, but will save that until my next post.

Intel® SOA Expressway for Healthcare is a specific implementation of a new product category called a SOA "soft appliance", which delivers a breakthrough in simplicity, cost and scalability for enabling high-quality health information exchange.

For more complete information about compiler optimizations, see our Optimization Notice.