NeoTool — Singular Focus, Healthcare Integrated

When designing an HL7 interface to send pharmacy orders from a clinical application to a pharmacy system, it can sometimes be a challenge to determine which HL7 message type to use to send different types of information.

Since both ORMs and RDEs can be used to send pharmacy orders, the question sometimes arises as to whether one should use ORM or RDE for pharmacy orders when working on an HL7 integration project. Either approach is valid.

Ultimately the question is not “Should I use ORM or RDE for pharmacy orders?”, but rather “Do my sending and receiving applications support exporting and importing of ORMs, RDEs or both for pharmacy orders?” Some vendors may choose to only export/import pharmacy orders as ORMs with additional segments or Z-segments as needed, while other vendors may choose to support export/import of RDEs instead, and still others may accept both. 

However, the above can lead to a challenge should a sending system only support exporting pharmacy orders using the HL7 standard ORM message type, while the receiving system can only support importing pharmacy orders using the RDE message type (or vice-versa). What this means is that the sending system would be sending the order in a different message format (ORM) that is in a different message format (RDE) than the receiving pharmacy system can accept — hence the receiving pharmacy system would either ignore, reject, or error the order. In such scenarios, an interface engine can be used to transform the ORM from the sending system into an RDE that the receiving system can import successfully (or vice-versa).    

There are two primary methods of moving clinical data in a hospital or clinic:

1. Point-to-point interfacing, which provides a direct connection between exactly two applications
2. Interface engine interfacing, which provides a way to leverage a set of interfaces between many applications

The presence of an HL7 interface engine in a healthcare environment gives more control to an organization and saves money and time by:

• Reducing the required number of export and import endpoints
• Allowing for reuse of data between applications
• Providing an easier method to interface a new or replaced application
• Providing the ability to monitor the entire system at one time
• Providing the ability to proactively notify interested persons using visual display and e-mail, when problems arise

Facilities that are pursuing healthcare integration initiatives and use an interface engine model find that:

• It is much less expensive and takes less time to initially implement an interface because an engine allows for leveraging of data and an engine is flexible in its acceptance of data
• The cost and time required to add new or replace existing applications is frequently less than half that required in a point-to-point model
• It requires considerably less time and money to maintain and monitor the interfaces because of the availability of centralized monitoring

There is an excellent 22 page white paper on this website entitled, “Why Do I Need an Interface Engine? Evaluating Two Approaches: Point-to-Point and Interface Engine.” It discusses the pros and cons of these two approaches in detail. Specifically, the white paper provides details on how an HL7 integration engine provides more control and saves time and money in a clinical or healthcare environment. The paper includes a comparison of an interfaced environment using point-to-point communications and an interfaced environment using an interface engine.

In a prior post, I described the motivation for mapping HL7 messages. As described in that post, the HL7 2.X messaging standard is the most widely used method to move healthcare information yet the details of the messages vary greatly from system to system.

An HL7 engine provides several functions and one of the key features of an engine is the ability to map from one set of application assumptions to another set. Said another way, an HL7 integration engine takes a message in one format and maps or transforms it into another format.

The starting and ending message formats will be controlled by the applications involved. Prior to HL7’s market dominance, the variety of message formats was large. This meant that typically an interface’s data elements closely matched the data model in the source application. Further, this made the creation of the interface “easy” by the sender of the data but “very hard” for an engine in the middle or the receiving application.

The HL7 community’s approach to define a base data model for the messages makes the variety of message formats smaller in today’s engine market. This reduction in the number of message formats is somewhat offset by the huge number of interfaces that must be created.

In the current market, typically an interface engine is mapping in one of the following ways:

• Mapping between two or more interpretations of the HL7 standard to resolve data model or workflow issues between incompatible applications
• Mapping between XML and HL7 and/or HL7’s 2.XML format
• Parsing an HL7 message and writing message contents to a database
• Reading a database and creating an HL7 message
• Working with a mixture of proprietary message formats such as CSV or flat files (sometimes called COBOL copybooks)

An HL7 interface engine needs to be flexible enough to deal with non-standard HL7 messages in an efficient and accurate manner, without having to manually code the differences for each external healthcare vendor with which it is communicating.

An HL7 interface engine also must provide a quick way to start with a standard “base HL7 version” and modify it to mirror the differences in the message that is sent or received by a particular application.

As an example, NeoTool’s interface engine supports non-standard HL7 formats by:

• Including all the standard HL7 versions loaded and available for easy modification
• Allowing for modification of these base versions by creating a derivative of the standard message format that inherits all the characteristics of the standard format – supports Z segments, non-standard separator characters, etc.
• “Change once” segment definitions so that a single change is properly reflected in all messages that use that segment
• Providing the ability to leverage prior derivative work and create a derivative of a derivative – to support two versions of a single application, for example

The message format support of an interface engine is combined with a method of actually mapping from one format to another format. Typically this is accomplished via some graphical mapping tool and executation environment. In a future post, I will describe some of the techniques used while actually mapping messages.

In my last two posts - acknowledgement (ACK) message definition and Original Mode ACK, it is important to remember that not every system will handle acknowledgments the same way in HL7 messaging. You will interface with systems that send you HL7 messages and do not wait for a response of any kind prior to sending the next message. In this scenario, your system will not be able to send back acknowledgment messages. This type of HL7 messaging delivery is never recommended.

Also, not all systems will review the values that are placed in MSA-1. So even though your application may be setup to send back an AE value in MSA-1, if you fail to receive a message, there is no guarantee that the sending system will review this value. Why is this important?

Consider this scenario:

Your lab application is setup to send back a negative acknowledgment (’AE’ value in MSA-1) if it receives a message that it cannot enqueue. The HIS system at the hospital where your application is installed does not review the MSA-1 value of the ACK message that you send back. At 2:00 pm, there is a hardware problem on the machine where your application is installed, and although you are able to receive messages, you cannot enqueue them. So you send back a negative acknowledgment letting the other side know you have a problem and were unable to enqueue the last message. The HIS ignores the details of this response, and sends you the next message, which will also fail to be enqueued.

An hour later, doctors begin to call the lab looking for results for the orders that they have placed. The lab staff claims they have never received those orders. The HIS administrator is called, and after a quick review of the interface, claims that the orders are being sent and acknowledged by the lab system. This, of course, is because the HIS is only using the first level of qualification.

A quick review of the lab system reveals the problem. Once the lab system has recovered, all of the lost messages need to be reloaded before the interface can be brought back online to receive real time messages again. These messages will need to be resent from the HIS. This may require downtime for the HIS and other systems in the hospital.

These problems can be avoided upfront if the implementation team has a solid understanding of how ACKs will work between the systems. It is important to review the HL7 integration specifications of any application that you will be interfacing with to gain a thorough understanding of how their system sends and receives HL7 acknowledgment messages.

In particular, you need to understand the level of detail an application will go to when qualifying an HL7 response. While this may only be a small piece of an HL7 interface, it is often overlooked in the beginning and is only addressed once the issue has been encountered in production. A little preparation upfront can save you a lot of time, and messages, in the long run.

The HL7 2.5 standard defines close to 500 different message types. While some are only used occasionally, almost all HL7 interfaces will incorporate the H7 acknowledgment (ACK) message. An HL7 ACK message is used to insure that HL7 messages are delivered from system to system without being lost.

Like any technology company, occasionally we have our own internal IT problems to deal with. This week it happened to be our mail server. For a period of time, we were not receiving any external e-mail, but we were unaware of the problem until a customer called us to let us know his e-mail had bounced. Once we were aware of the problem, fixing it was trivial. This got me thinking about the way HL7 messages are delivered, and the importance of HL7 acknowledgment messages.

In the clinical world, the successful and timely delivery of HL7 messages is critical. Tens of thousands or even hundreds of thousands of messages are transported daily in a typical hospital environment. When a medical application (HIS, LIS, RIS…) sends an HL7 message, it immediately needs to know that message was delivered successfully. Only once the successful delivery of the message has been verified should the next message in the queue be sent. 

HL7 integration engines or HL7 enabled applications need to be able to generate properly formatted HL7 responses for all messages that they receive. Also, with HL7 messaging, applications should be configured to wait to receive an HL7 formatted response prior to sending the next message in their queue. 

Most applications will take the ACK qualification a few steps further and verify not only that the message they receive is an HL7 ACK message, but also that the data contained within this message matches the data from the previously sent message and that the status of the ACK is a positive response. This is known as original mode acknowledgement. A vast majority of HL7 interfaces today use original mode acknowledgment. 

The HL7 standard defines the maximum field length and field cardinality in an effort to help developers define their clinical databases and interfacing requirements. The field length has always been the “recommended maximum” and, frankly, the idea has historically been pretty much ignored. The field cardinality provides a minimum and maximum number of times that a value should be sent on the HL7 2.X interface and, in general, is more strictly followed by applications.

In short, if HL7 messages are to be exchanged, both the sender and receiver must agree what elements will be sent (field cardinality) and how long each element will be (field or component length). These two terms are critical to understanding how data will move within an integration project:

Cardinality: Sometimes an element will be considered required (minimum cardinality of one) and sometimes optional (minimum cardinality of zero). When you add the complexity of repeating elements (maximum cardinality of n), you can provide for all element constraints - e.g., “optional and repeating element” (such as patient alias) becomes a minimum of zero and a maximum of n (0 to n or 0:n).

Length: Both ends of an interface ultimately need to agree on the lengths of the elements that are to be exchanged. For example, assume the sender delivers a patient name of “Ivanov Ivan Ivanovich-Novak” and the receiver supports 10 characters for first name, a single character for middle name, and 12 characters for the last name. The receiver will see a patient named “Ivanov I Ivanovich-No” - to a human, it looks almost the same. But to a computer, it could be very different.

The challenge with HL7 integration is that often clinical software vendors (or ISVs) define their database structures before they adopt HL7. The story often goes something like this:

We’ve got 352 customers running version 4.2 of our product and in version 5.0 we want to add a little HL7 interfacing to populate the patient roster. This will allow our larger customers to avoid duplicate entry of patient demographics in our application. Thus, we need an inbound ADT (admit, discharge, transfer) interface. The application database cannot drastically change while adding HL7 functionality. The application developers need to add an HL7 subsystem to the application and then reconcile the differences between our database and HL7’s data model.

In order to make the process of adopting HL7 easier, often developers use an HL7 toolkit. Using such an interface engine makes the HL7 communications, parsing, interfacing monitoring, etc. problems go away. The challenge left is the data model reconciliation. Ultimately what the late adoption of HL7 in a product’s life cycle means is that the choices made early in an application development live on for many years. For example, initial development efforts often build databases that look like this:

Patient Table
Column 1: Last name, required, string type, 50 characters long
Column 2: First name, optional, string type, 30 characters long
Column 3: Middle initial, optional, character type, 1 character long
Column 4: Date of birth, required, native date type
Column 5: Gender, optional, native integer (0 = male, 1 = female, 2 = unknown/other)
…

The point is that developers think about data elements one at a time. In the HL7 standard, we call these values components. If you look at the HL7 standard, there is a PID segment which contains a fifth field (PID-5) that field uses the XPN (eXtended Person Name) data type. That data type has changed substantially over time.

Prior to HL7 2.3.1, the XPN data type (back then often called just the PN) looked like this:

1. family name
2. given name
3. middle initial or name
4. suffix (e.g., JR or III)
5. prefix (e.g., DR)
6. degree (e.g., MD)

This means that the widely-adopted versions of the HL7 standard allow six components in a name. Note that the example legacy database design discussed above only supports three of these elements (last, first, middle.) Also note that the database has a single character for “middle initial” while HL7 allows for the squishy idea of “middle initial or name.” Remember that the product management team said, “When adding HL7 to version 5.0, you can’t make major database changes.” Thus the reconciliation is pretty easy: “We’ll support what we can with the existing database and ignore the rest of HL7.”

A related HL7 integration problem occurs on two fronts: Note the database requires last name and date of birth. HL7 just says that the name is required, but it does not specify what pieces of the name must be sent. HL7 also marks the date of birth (PID-8) as optional. So the inbound interface must do something if the remote application sends a message to create a new patient but leaves out either the last name or DOB.

Ultimately, this is why HL7 allows a development team substantial latitude to include or exclude elements in the interface. In the on-going example, the vendor will probably make some note in their HL7 interface specification like this:

• Only the first three components of the PID-5 field are supported (i.e., prefixes like “Mr.” or a suffixes like “Sr.” will be dropped.)
• The length restrictions are:
  • First name 30 characters
  • Last name 50 characters
  • Middle name 1 character
• If the message does not contain a patient last name, the value Unknown will be defaulted into the patient’s record.

In future posts, I will address the issue of component-level cardinality and HL7’s new direction in HL7 2.7 regarding field and component lengths.

I stumbled into a great article in the June 2006 issue of the ACM’s Component Technologies journal. The article is titled “Software Development Amidst the Whiz of Silver Bullets…” and was written by Alex Bell (who works outside of healthcare at Boeing.) The article addresses the question of “new school technologies” (say, XML and UML) and what magical value they really bring to the table when solving real world problems.

I thought Alex’s insights were good, and I thought I would share them and some thoughts of how this debunking applies to healthcare integration.

As a long time healthcare integration professional, I’m often faced with questions generated both internally and by students or customers regarding this weird, odd thing we call HL7. By HL7, I mean the HL7 2.X messaging standard that moves clinical information around a hospital, clinic, imaging center, or lab. HL7 2.X is a “triggered” and real time protocol. That is, systems within the facility want to know where a patient is right now. They want to receive lab results within seconds of them being entered. The pharmacy system needs notification when new prescriptions are written. And so on.

Like Alex, the longer I’m in the software development and healthcare integration game the more it seems the problems we face are the same again and again. Often someone new to integration will say something like, “Why are we using HL7? Can’t we just do a little XML and be done with it? XML would be so much easier!”

Here are some excerpts from Alex’s article:

[T]here are no silver bullets available now or in the foreseeable future with which to solve all difficulties.
…
I was recently reviewing a software design document … included the following commanding statement a number of times: “The configuration data will be stored in XML.” I immediately thought to myself, “Wow, this design must really be good” and was relieved from previous concerns that some form of ancient Egyptian hieroglyph may have instead been the representation of choice.

Funny, yes. But it reminds me of the typical first reaction that new users have to HL7: “Wow, it’s ugly and XML would be so much better.” They miss the point: HL7 2.X is about the data model and workflow of healthcare facilities. In fact, HL7 can be encoded in XML using the HL7 2.XML standard. Or, go for the brass ring and try to speak HL7 V3.0 (or more generically, HL7 3.X). Alex continues…

Still reeling from the powerful implications of what I had read, I began to wonder if placement of any content in the context of XML would somehow lead people to believe it to be of hallowed or divine origin, and having some implicit warranty of accuracy or correctness
…
XML is not the only silver bullet in the software engineering space to which sanctity seems to be automatically attached by simply using a particular technology. The fact that a diagram has been created using the UML leads some to believe that the associated design is guaranteed to be implementable and ready for development, even if the laws of physics were ignored as constraints.

Sure enough, there’s one view that HL7 V3.X falls into the space of ignoring some of those laws of physics.

[S]ome developers feel that their usage impacts the open-endedness and flexibility made possible by method signatures of the ilk:

XMLResult DoAnything (XMLDoc Arguments)
{
……
}
…
As opposed to having to devote significant efforts to the consideration of constraints such as network bandwidth, processor speeds, and the speed of light when developing system architectures, such annoyances are now overcome by creating reams of UML diagrams containing very vague entities and equally vague navigation between them.

Is HL7 perfect? Far from it. However, as I like to say in training class, “HL7 2.X is the best thing we have for now. ‘Everyone’ uses it and it is the de facto way to move clinical data.” The HL7 integration community is always improving the standard and has embraced XML. Let’s just not think that these new technologies are and end in themselves.

As we have discussed in previous RSNA posts, Integrating the Healthcare Enterprise (IHE) has had a major presence at the show. Yesterday, Nikolaus Wirsz, PhD, manager IT standards, Siemens Medical Solutions, gave a presentation entitled The IHE Initiative Worldwide: An Update. During the presentation, he stated “IHE is not a local problem; we are seeing integration problems everywhere. As a result, IHE has been promoted worldwide.”

Although the crux of his statement is true, healthcare integration is being resolved locally by many hospitals, imaging centers, clinics, and labs. IHE is an important organization that is driving how the various standards can be used to enable healthcare interoperability, and it is essential that the standards be promoted worldwide.

In reality, healthcare institutions are not waiting. Radiology practices are putting information technology solutions in place to extend their electronic data exchanges to the referring physician community. Hospitals, labs, and clinics are doing the same.

Healthcare interoperability, with HL7 integration being an essential part of it, is occurring at the local level. Their driving forces are streamlining workflow, enhancing quality of patient care and experience, and improving productivity. Healthcare interoperability is being led locally as well as by IHE.

Procedure code mapping is one of many code set mappings that may need to be completed in order to successfully interface a healthcare provider with an imaging center via the HL7 standard. Procedure mapping has an impact on radiology workflow.

An imaging center has a defined set of procedures they can perform. In their Radiology Information System (RIS), each procedure has its own internal code. For example, a left-side chest x-ray may be coded as 9999. While these codes are standard within the internal RIS, they are not the same procedure codes that external healthcare providers will be sending them. Hospital 1 may have the left-side chest x-ray coded as ‘R777′ in their system, and Hospital 2 may have a code of ‘12345′.

Complicating this issue even further is the use of procedure modifiers. A third hospital may have a procedure code of ‘CX123′ in their system for a left-side chest x-ray, and they would use the same procedure code in their system when ordering a right side chest x-ray. They would, however, send a procedure modifier value of ‘L’ or ‘R’ as part of their HL7 order message.

The examples below illustrate the format of the OBR segment of an HL7 order message (ORM^O01) that each sending system would send to an imaging center:

Hospital 1:
OBR||0606290001|060629001RAD|R777^Left Side Chest||…

Hospital 2:
OBR||0606290001|060629001RAD|12345^Chest X-RAY Left Side|||…

Hospital 3:
OBR||0606290001|060629001RAD|CX123^Left Side Chest^^^L|||…
These messages need to be restructured so that the imaging centers RIS can accept them, and create an order for the correct procedure in their system.

Imaging Center:
OBR||0606290001|060629001RAD|9999^Left Side Chest X-RAY|||…

This mapping can take place in 1 of 3 instances:

1. The mapping can be accomplished using an interface engine.
2. The imaging center may require that the external system do the mapping in their system prior to sending the HL7 order messages to them.
3. The imaging center may choose to set up the mapping in their RIS for ‘each’ healthcare provider that they interface with.

There are pros and cons to each approach. If you are an imaging center that plans on interfacing via HL7 with a large number of healthcare providers, creating custom mapping for each HL7 interface within your RIS may be possible but, at the very least, extremely time consuming. On the other hand, if you are an imaging center that requires external systems to do their own mapping, you may lose business to more flexible imaging centers that are willing to do the mapping in their system. HL7 integration engines allow you to take the mapping out of the clinical applications, and gives you the ability to create the mapping in a system that is designed specifically for the manipulation and routing of HL7 messages.

Keep in mind that when the report is sent back to the ordering healthcare provider, a similar mapping may have to take place in order to map the procedure code back to the external procedure code value … Receiving the order is only half the battle!

Ken Rubin is a frequent contributor to the HL7 standards body and works for the Veterans Health Administration (VHA or VA). Among other things, he works to improve and architect current and future generations of VistA and related applications.

VistA is the Hospital Information System (HIS) that is used by hundreds of VA hospitals. In addition, various third party versions of VistA have been built as open source or proprietary electronic medical records (EMRs) on top of the “free” VistA code base. There is a great VistA history article here.

In any event, Ken made a blog posting this week regarding EMR interoperability. In part he says (in conclusion):

Many criticize HL7 v2 messaging because of the lack of interoperability that resulted from ambiguity in “Z” segments. On the contrary, HL7 V2 was and remains wildly successful at allowing organizations to interchange information and interoperate. The problem is not in the wire protocol, it is in the conformance assertions.

We have an opportunity now to benefit from the lessons learned from the past, taking the utility and flexibility offered by “Z” segments and tempering them with strong enough conformance so as to give confidence to consumers that things will interoperate within an interoperability profile. The challenge is on us to ensure that the interoperable portion is sufficient.

I agree with Ken’s words above. When I describe the HL7 integration standard during HL7 training classes or while demonstrating our interface engine, I often describe the HL7 2.X messaging standard like so:

Generic doctors treating
Generic patients using
Generic clinical methods via
Generic procedures aiming for
Generic outcomes to
Generic diseases and all paid for with
Generic insurance (or not)

The point is that the HL7 standard is in many cases the most generic form of a clinical workflow and data model. In order for it to be usable in a real world environment, the applications involved make choices and the facility where those applications are installed further refine (and sometimes override) those choices.

I describe that HL7’s entire point is to provide a framework for discussing these differences. A conformance profile - IHE, ELINCS, a vendor specification, etc. - is where the choices are written down. If multiple sites or many vendors can share one profile, we have “out of the box interoperability.” The HL7 2.X standard itself does not provide such connectivity for “free.”