HL7 standards are what make healthcare integrations possible. Without them, the degree of interoperability – even if the current state appears frustratingly slow – would likely be impossible. The most common standards used are the HL7 2.x standards. For those who have encountered HL7 integrations, these are the pipe delimited files that look unreadable to the human eye. These seemingly unreadable files are able to send demographics, scheduling information, billing data, transcription results, and labs. Additionally, actual files – such as PDFs of EKG waveforms – can be embedded into such messages. These messages types have been around for a long period of time, have evolved incrementally, and are the backbone of most integrations – both those within organizations and those between entities.

            Such integrations are fairly durable and do serve – especially within health systems – their intended purpose rather well; however, they do have limitations and likely not the long-term solution for an industry that increasingly wants data sharing to occur outside of entities. For example, the 2.x standard is not necessarily a plug-and-play integration. For example, it does not work as seamlessly as database connectivity through an open framework works; rather, the 2.x standard works more like a framework that provides a large majority of the infrastructure needed for an integration, but there is still some – sometimes quite a bit – of customization needed on a point-to-point basis to successfully complete an integration. There is, for example, the existence of Z segments which are general purpose, customizable segments in a message that can be used to transport data that does not fit neatly into the standard specification. A Z segment may provide additional clinical data not readily available in the standard message format but, nevertheless, import for the receiving system. The receiving system must then be configured to process the Z segment correctly.

            Many systems also have internal methods of mapping data to values within both the sending and receiving application and HL7 2.x integrations often have to use integration engines such as Mirth, Rhapsody, or Iguana to handle such translations. While there are standard code sets for many items; nevertheless, some organizations or vendors do not use them. This is somewhat common with labs where LOINC codes are a standard codesets (a way to note lab results); however, not all labs use LOINC codes internally in their LIS (Lab Information System). Various mapping processes either within an integration engine or within a sending or receiving application must process and translate between proprietary and LOINC codes. This also occurs with other codesets; however, it does appear to be a declining issue in interfaces as the growth of CCDAs (another standard document that has seen significant growth especially in the United States) and some pressure from the government through Meaningful Use has affected some vendor standardization.

            HL7 version 3 is a newer incarnation of the HL7 standard that was built after roughly a decade of work by experts in various areas of healthcare. It is built upon the RIM or Reference Information Model which models various workflows from an integration standpoint. This allows for the various version 3 standards to be developed from a common model and to better ensure data consistency. The RIM can easily be mapped to HL7 2.x; however, version 3 standards are XML based (a markup language for describing data). The most common version 3 standard in use is the CCD or continuity of care document. This file received significant traction when the ONC (Office for the National Coordinator of Health Information Technology) decided to use it when creating Meaningful Use standards. The CCD is most often used to exchange significant amounts of clinical data in a single document between EMRs and from EMRs to secondary systems such as Health Information Exchanges of data analytics systems. HL7 version 3 has put significant emphasis on exchanging and standardizing the clinical context of the data which renders it more actionable by receiving parties/systems. While the CCD is a fairly rigorous standard, there are still imperfections in it which create integration challenges. For example, some EMRs may not include the procedure history, some may include only current labs or others will go back x number of years. In environments with disparate EMRs, this creates an integration challenge for designers trying to plan cohesive systems with multiple EMRs.

            While there is no indication that 2.x integrations are going anywhere, it is likely that with the growth of APIs and the version 3 – especially CCDAs – their relative decline will occur through fewer new instances (of 2.x interfaces) relative to newer APIs and version 3. The newer methods allow for more standardization, easier implementation, and provide mechanisms for exchanging larger amounts of relevant clinical data in a single message.


0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *