Plenful's Approach to HL7 Interoperability

If you have worked with healthcare systems or data you have likely encountered or interacted with HL7 messages. According to the HL7 standards organization, around 95% of US healthcare companies utilize HL7 to facilitate electronic data exchange between and among systems. For example, if a piece of software running in a pharmacy submits an order to an inventory tracking system, or if a patient is admitted to a facility, or a note is added to an EMR, HL7 was most likely used to communicate those (and many other) events.

But what is HL7 and why is it so ubiquitous? HL7 became the de facto standard in healthcare in the US over the course of 30+ years and was invented during the digitization of US healthcare systems in the late 80’s and 90’s. Over time, it has become so commonplace that to accommodate the many use-cases in healthcare, it needed to become very complex.

HL7 v2 is a series of messages that communicate some kind of event occurring in a healthcare context. It can be anything from a request for a new lab order to an addition to a vaccination record. An HL7 message is a piece of text composed of individual segments, these segments are composed of fields, and the fields themselves may have one or more sub-fields. Below is a simplified example of a Patient Identifier segment:

PID|1|123456789|||Cohen^Dan||19560213000000|M|||500 Main Street

The segment type is first; they are always 3 digit codes. In this case it's PID. Then each subsequent field is separated by a ‘bar’ character: |. Fields are numbered left to right based on the number of bars that you have encountered. PID field 1 is the text after the first “|”. PID field 2 is the text after the second “|” and so on.  Let’s focus on PID field 5. I’ve underlined it for emphasis. In the HL7 v2 specification, field 5 is called Patient Name.

Each field can be composed of sub-fields, and these sub-fields are usually what house the data. Sub-fields are read the same way as fields are, except that they are separated by the “^” (caret-up) character. We can read them left to right inside of a field in the same way that fields are read in the context of a segment. Subfield 1 of patient name holds the text containing patient last name and subfield 2 of patient name holds the text containing patient first name. In this example, I’ve put in my own name, Cohen^Dan.  Putting all this back together, subfields contain data, fields contain subfields, segments contain fields and messages are made up of a set of segments.

At Plenful, we automate complex healthcare workflows and problems. To solve some of our partners' most pressing challenges, we need to meet them where they are. Both in a technical and in a business sense. To address their challenges, we often need to ensure our systems communicate effectively with other systems. In order to do so, Plenful has to handle many types of HL7 v2 messages and properly extract the correct information from these messages.

The traditional way of handling HL7 messages is to set up logic for handling each type of message as separate from each other. So, a message type of New Drug Order would have one type of processor in our system, and a message type of Cancel a Drug Order would have another. Traditionally, when HL7-based systems integrate with each other, they integrate based on the type of each message. At Plenful, we knew that our systems need to be able to handle many current and many unknown future types of messages.

To address this, we developed an HL7 Builder. The solution is a user interface that allows users to ‘construct’ a scaffold of an HL7 message from the segment level down to the subfield level. We built our system and user interface to support a set of segments, a set of fields, and a set of subfields. For any given use case involving HL7, a Plenful user can use the builder to extract data from only relevant subfields. When we need to support new segments, fields, or subfields users simply add to a list elsewhere in the system and the new constructs will appear as options in the builder. Because of the builder’s flexibility, we have been able to enable other forms of automation. For instance, we use the HL7 builder to construct messages that are exported from Plenful to our customers’ systems.

With the builder at our disposal, we are well-equipped to navigate the complex landscape of healthcare data management and support all of our customers' needs.