Archive for the ‘HL7 Messaging’ Category

Among applications that produce Result messages, there is considerable variation in the way that the individual report lines are structured. The following three methods are common:

1. Repeating OBX segments: where each OBX segment contains exactly one line of report text in the OBX-5 field.

OBX|1|FT|||FX OF LT FIBULA
OBX|2|FT
OBX|3|FT
OBX|4|FT|||Technique: Three views left ankle.
OBX|5|FT OBX|6|FT|||Findings: There is an oblique fracture of the lateral malleolus at the level
OBX|7|FT|||of the mortise. No other fractures are identified. The mortise is symmetric.
OBX|8|FT
OBX|9|FT|||Impression: Oblique fracture of the lateral malleolus at the level of the
OBX|10|FT|||mortise.
OBX|11|FT
OBX|12|FT

2. A single OBX segment with repeating OBX-5 fields: where each OBX-5 field contains exactly one line of report text

OBX|1|FT|||FX OF LT FIBULA~~~Technique: Three views left ankle.~~Findings: There is an oblique fracture of the lateral malleolus at the level~of the mortise. No other fractures are identified. The mortise is symmetric.~~Impression: Oblique fracture of the lateral malleolus at the level of the~mortise.~~

3. A single OBX segment and a single OBX-5 field: where a special character or series of characters act as the delimiter that separates individual report text lines.

OBX|1|FT|||FX OF LT FIBULA\.br\\.br\\.br\Technique: Three views left ankle. \.br\\.br\Findings: There is an oblique fracture of the lateral malleolus at the level\.br\of the mortise. No other fractures are identified. The mortise is symmetric. \.br\\.br\Impression: Oblique fracture of the lateral malleolus at the level of the\.br\mortise. \.br\\.br\

With the use of an integration engine, converting from any one of these message variations to another should be a relatively simple task.

Maintaining original report line breaks. In general, the application that produces the text of a report will structure the lines of the report in an appropriate fashion. The following report message excerpt illustrates how important the position of the original line breaks can be.

OBX|1|FT|||CONFUSION
OBX|2|FT
OBX|3|FT
OBX|4|FT|||RT CAROTID
OBX|5|FT|||ICA PSV: 92 cm/s
OBX|6|FT|||CCA PSV: 99 cm/s
OBX|7|FT|||ICA/CCA PSV RATIO: 0.9
OBX|8|FT|||ICA EDV: 34 cm/s
OBX|9|FT|||RT VERTEBRAL ARTERY FLOW: Antegrade
OBX|10|FT
OBX|11|FT
OBX|12|FT|||LT CAROTID
OBX|13|FT|||ICA PSV: 66 cm/s
OBX|14|FT|||CCA PSV: 88 cm/s
OBX|15|FT|||ICA/CCA PSV RATIO: 0.8
OBX|16|FT|||ICA EDV: 38 cm/s
OBX|17|FT|||LT VERTEBRAL ARTERY FLOW: Antegrade
OBX|18|FT
OBX|19|FT
OBX|20|FT
OBX|21|FT|||Right carotid: Color and spectral Doppler failed to show evidence of
OBX|22|FT|||significant focal measurable stenosis. There is antegrade right vertebral
OBX|23|FT|||artery flow.
OBX|24|FT
OBX|25|FT|||Left carotid: Scattered focal calcified plaque formation is present at the
OBX|26|FT|||left bifurcation. Color and spectral Doppler show mild turbulent flow in the
OBX|27|FT|||proximal left ICA. However, flow ratios and velocities remain within normal
OBX|28|FT|||limits. There is antegrade left vertebral artery flow.
OBX|29|FT
OBX|30|FT|||Impression:
OBX|31|FT|||1. Study fails to show evidence of high-grade focal stenosis either carotid.
OBX|32|FT|||2. Calcified plaque formation left bifurcation which produces a visually
OBX|33|FT|||estimated 50% diameter stenosis in the proximal left ICA. If asymptomatic for
OBX|34|FT|||left hemispheric symptoms, a follow-up carotid ultrasound is recommended in 1
OBX|35|FT|||year.
OBX|36|FT
OBX|37|FT

Special lines, such as the individual measurements with units in the initial sections and the numbered list items in the Impression section, would have severely compromised readability if the original line breaks of this report were not maintained. For this reason, when we are converting a report from one message format to another, we have very strong motivation to maintain the integrity of each line of the report as it was produced in the originating application. In general, this does not present a problem and, in fact, is the most straightforward way to perform the conversion.

Be aware of line length limits. If, however, the maximum number of characters per line in the original report may exceed the allowed character limit of a destination application, we are presented with a challenge. Even with powerful tools provided by an integration engine, the handling can become complex.

In the report above, the sections labeled “Right carotid”, “Left carotid” and “Impression” contain lines of text that may be up to 78 characters long. If a destination application with a report line character limit of 70 characters needs to receive this report, we need to modify the placement of the original line breaks.

A useful feature of an integration engine for this task is the ability to appropriately “wrap” the text of one line to the next line without splitting the text in the middle of a word. Unfortunately, we have more work to do than simply applying that feature to each line of the report. Our first problem is that if we are iterating through the lines of the report and simply inserting a new line when we encounter one that is over 70 characters, we will end up with report lines structured like this:

[…]
OBX|21|FT|||Right carotid: Color and spectral Doppler failed to show evidence of
OBX|22|FT|||significant focal measurable stenosis. There is antegrade right
OBX|23|FT|||vertebral
OBX|24|FT|||artery flow.
OBX|25|FT
OBX|26|FT|||Left carotid: Scattered focal calcified plaque formation is present
OBX|27|FT|||at the
OBX|28|FT|||left bifurcation. Color and spectral Doppler show mild turbulent
OBX|29|FT|||flow in the
OBX|30|FT|||proximal left ICA. However, flow ratios and velocities remain within
OBX|31|FT|||normal
OBX|32|FT|||limits. There is antegrade left vertebral artery flow.
[…]

This strategy maintained the original line breaks and simply added a new line break where a line over 70 characters was encountered.

Our strategy must be modified to use our word wrap feature on a block of report text that has been stripped of the original line breaks. You may recall, however, that for some special sections of the report, we must maintain the original line breaks to maintain its readability. Our strategy needs to be much more complex, such that it will apply appropriate handling to different sections of the report.

The result is that the conversion process must now begin to “pay attention” to the actual content of the report. While this can be done, it is an undesirable situation, mainly because the variation in the reports may be great enough that detecting the beginning and end of any given section is highly unreliable.

Using an integration engine that has robust message processing capabilities, this type of complex restructuring of the lines of a report is possible, but it can be a significant effort. The easiest solution to the problem, if it is possible, is to decrease the maximum line length of the application that is generating the reports to a length that all destination applications can handle.

For more information and to see the original PDF, click here.

In the constellation of separate systems within a healthcare facility, it is common to have a single application which produces (HL7 ORU) Result/Report messages.  These ORU messages may correspond to Orders that originated with several different ordering facilities or ordering physicians.

In many instances, there is a need to send a different message structure to each of the systems which need the ORU messages.  The task of appropriately formatting and distributing the ORU messages is manageable with the flexibility and message processing power provided by an integration engine.

With a single inbound stream of ORU messages flowing to your integration engine, a method to route messages to the appropriate destinations is required.

If the ORU message contains a field to indicate which facility initiated the order, that field may be the only thing we need to use in order to route messages properly.  Another option is to route messages based on the field that contains the identity of the ordering physician (or “Ordering Provider”).  In this case, we are likely to benefit from the use of a lookup table, since there may be many ordering physicians associated with a given ordering facility. The technology used to implement the lookup table may vary, but the methodology would be consistent.

OrderingProviderID	OrderingProviderName	DestinationFacility
123	Smith, John  MD	Riverside
234	Jones, Mary  MD	Riverside
345	Johnson, Bill  MD	NorthSideClinic
456	Williams, Mike  MD	MemorialHospital
…	…	…

Our message processing logic would simply use the lookup table to find the DestinationFacility which corresponds to the OrderingProviderID presented in the ORU message (commonly populated in the OBR-16.1 field).  Using the example table above, an ORU message with an ordering provider of John Smith should be sent to Riverside.

An ordering physician may be associated with more than one ordering facility. In this case, a more robust routing method may be desired. We may want to send the Result message to all destination facilities that the ordering physician is associated with. This would require a slightly more complex lookup table and associated logic.

OrderingProviderID	OrderingProviderName	DestinationFacility
123	Smith, John  MD	Riverside
123	Smith, John MD	NorthSideClinic
345	Johnson, Bill  MD	NorthSideClinic
456	Williams, Mike  MD	MemorialHospital
…	…	…

In this case, our message processing logic would use the lookup table to find all rows that contain the OrderingProviderID and route the appropriately formatted message to each DestinationFacility. Using the example table above, a Result message with an ordering provider of John Smith should be sent to both Riverside and NorthSideClinic.

Something to keep in mind when using lookup tables such as the examples above is that the tables need to be maintained. A procedure to keep the lookup tables up-to-date should be put in place in order to ensure that message routing is accurate.

For more information and to see the original PDF, click here.

HL7 International announced that a new implementation guide for ELINCS is now available. The new guide uses HL7 2.5.1 as the foundation instead of HL7 v2.4.

ELINCS stands for EHR-Lab Interoperability and Connectivity Standards, and it is a specification to refine (or constrain) “standard” HL7 messages to move lab results from labs to physician offices.

Key changes in the ELINCS HL7-R1 specification include:

• Shifts from HL7 v2.4 to HL7 v2.5.1
• Supports sending copies of lab results to other providers
• Supports a broader set of lab tests for which LOINC coding is required
• Outlines special rules for reporting the identifiers of ordered tests (depending on whether systems support unique identifiers for each test ordered on requisition)
• Supports the structured microbiology culture/sensitivity results

Outlined below are several great resources to learn more about the new ELINCS implementation guide:

• Change Summary: ELINCS v1.1 to HL7R1 Change Summary (PDF) – Delivered by the California HealthCare Foundation (CHCF).
• HL7 Press Release: HL7 Standards Are the Foundation and Enablers of Meaningful Use:  Version 2.5.1 Implementation Guide for Electronic Laboratory Reporting to Public Health Now Available; Several HL7 Standards Support Meaningful Use (PDF)
• White Paper: Accelerating EMR Interoperability with ELINCS provides a foundation to understand the role of ELINCS.

Each of the above resources are very helpful, especially the change summary. The HL7 press release is interesting to read since it also reviews how HL7 supports the new Meaningful Use requirements. It outlines HL7′s specific support for Stage 1 requirements. In the latter part of the press release, HL7 discusses how it plans to address the healthcare interoperability requirements and challenges identified by the ONC. If you are interested in healthcare standards, it is worth the time to review these resources.

If you need more information, there are several blog posts on HL7Standards.com on sending lab results to EMRs or EHRs. Feel free to search our site to learn more as well.

With the discussion on healthcare interoperability escalating, it is good to take a step back and outline some basics of an HL7 interface. Understanding an HL7 interface is essential as well as approaches to take  in implementing a growing number of HL7 interfaces.

What is HL7? HL7 is the most widely used standard to facilitate the communication between two or more clinical applications. The prime benefit of HL7 is that it simplifies the implementation of interfaces and reduces the need for custom interfaces. Since its inception in the late 1980’s, HL7 has evolved as a very flexible standard with a documented framework for negotiation between applications. The inherent flexibility makes deploying HL7 interfaces a little more challenging at times.

Who uses an HL7 interface? There are several types of roles involved with HL7 interfaces, including clinical application analysts, integration specialists, application programmers, and systems analysts.

How should you approach an HL7 interface? To facilitate communication between two healthcare applications, a modest HL7 interface includes:

• An export endpoint for the sending application
• An import endpoint for the receiving application
• A method of moving data between the two endpoints
• A method for handling the queuing messages
• A method for logging the flow of messages

Logic tells us that each healthcare application must grant access to accept and send patient data and have rules of what it will accept and what it will send. Frequently, the access grant will be hard-and-fast rules rather than flexible ones that provide easy methods for exchanging data. This access to data is usually tightly controlled by each application vendor to ensure data integrity within their application.

To implement an HL7 interface between two or more applications, providers usually implement either a point-to-point interfacing approach or utilize an interface engine. A white paper which outlines these two approaches is entitled What Is Your Healthcare Interfacing Approach?

On this site, we have written many posts about working with various healthcare standards with a strong focus on HL7 interfacing and messaging. Outlined below are three posts worth a read to gain further insights on developing and testing HL7 interfaces.

• Getting Started with Your HL7 Interface:  Highlights what to ask for and what to ask about as it relates to HL7 messaging.
• HL7 Specifications Defined:  Defines what should be included in a healthcare interface specification.
• HL7 Sample Messages – Always the Best Way to Go:  Outlines the importance of getting sample HL7 messages when developing an interface.

This information should provide you with a solid start in your healthcare interfacing project. Check out HL7 Resources and the Healthcare Interoperability Glossary for further definitions.

As an integration engine support engineer, I frequently provide consulting services to interface analysts, programmers, and developers that are responsible for the planning, implementation, care and feeding of new HL7 interfaces. The range of technical prowess among the clients I assist is fairly broad. For example, on any moment of a typical day you may find me fielding questions on segment cardinality from a self-professed “HL7 neophyte”, while minutes later I may be on a call to review customized TCP/MLP message framing test results with a beleaguered multi-tasker. Thus, while some are very conversant with HL7 standards, and more importantly, the actual “as-built” specifications of their trading partner’s production environment—many are not.

One of the questions that almost always needs to be addressed during new interface planning, regardless of the experience level of the client, is which version of HL7 to use when we construct messages. A recent user-community poll indicated that a large majority of HL7 messages in production are a v2.3 or v2.3.1 variant. However, when a new interface is being built (to send order results to a client system, for example) should a sending reference lab, imaging center, or hospital use the most common, or the latest v2.x?

While it is true that the newer versions of the v2.x HL7 standard are backward-compatible, the process of identifying gaps in the specifications becomes simplified when both trading partners are operating off of the same blueprint. Similarly, one shouldn’t arbitrarily choose the most common v2.x of the standard to use as a base-line for their messages either—unless their interface engine is flexible enough to easily make and test changes to the message structure, they could end up with some extended development and potential headaches long after they thought their specifications were “complete”. So which course of action is the most prudent?

My recommendation, whether solicited or offered as free advice on best practices, is always the same— talk to your trading partners. They know best which version their application is ready to accept. If they have no preference, then your discussion should lead to an agreement on the version to be used, and will naturally lead to other discussions that will help smooth the way for a more swift and efficient implementation.

Moving dates and times between systems via HL7 has two primary challenges:

1. Clock skew/drift — the systems don’t agree on the definition of “now”
2. Time zones — the systems differ in their offset from UTC/GMT

While both problems are easy to understand, the two challenges are solved in very different ways. Here is a summary of each problem:

• Clock Skew or Clock Drift: Systems exchanging data “almost agree” on the current date and time — but not quite. For example, the RIS system thinks it is 4:15pm while the registration system thinks it is 4:17pm.
• Time Zone: The receiver of a message needs to know if the dates and times in the message are using the same time zone as the receiver or a different one. e.g., a radiology clinic based in Tucson receives an order from a referring physician in California. The time zone on the message says the order was generated at “8:15am.” The clinic needs to know if the time is California time or Arizona time. The answer is, “It depends!” The challenge is that depending on the time of year, Arizona and California share a common time zone and at other times they do not.

The Clock drift problems cause issues in annoying, silly ways — i.e., actual events that are happening in the real world appear to be impossible based on the disagreement about the current time. e.g., the RIS system thinks it is 4:15pm while the registration system thinks it is 4:17pm. An HL7 ADT admission message is generated recording the date and time of admission is “4:17pm”. Within seconds the RIS receives the message and claims that this date is “in the future” so it does not process the message correctly.

The solution to clock drift is twofold:

1. Attempt to synchronize clocks to one true time or a shared view of “correct time.” Many operating systems (including Windows) can automatically adjust the system clock based on a reference to a known, good time.
2. Alternatively, there can be a shared, collective view of time using something like the Network Time Protocol (NTP). Ultimately the OS can maintain the clocks within a few milliseconds. Sadly, many Hospital IT shops do not use a system to synchronize times.

The solution to the time zone problem is simple: All systems should send time zone along with every date and time. Sadly most HL7 interfaces do not include the time zone. This issue is covered in detail in another posting.

Both HL7 V2.x and V3.x support complex date structures. In the real world most V2.x messages are encoded using the local time on the system that generates the message. In addition, many HL7 interfaces do not support the concept or use of time zone.

This can be a big challenge when building interfaces and often site-to-site negotiation is required should the data moving across the interface need interpretation in another facility in a different time zone.

Said another way, historically HL7 messages were “always local” within a hospital or clinic. As the scope of using these messages pushes to regional or national level, the time zone is much more critical. In addition, the challenge of time zones directly applies even at the local level when daylight savings time kicks in and out.

As noted in chapter two of the HL7 specification, the time zone of the sender “should” be sent as an offset from the coordinated universal time (UTC) (previously known as Greenwich Mean Time or GMT). The problem is that the time zone specification is optional in V2.x — it “should be sent” but is “not required.”

This means that we need some general guidance on how to interpret an unadorned time. The rule proposed in the HL7 standard is that when the time zone is not present in a particular field but is included as part of the date/time field in the MSH segment, the MSH value will be used as the default time zone. Otherwise, the time is understood to refer to the local time of the sender.

In the real world most HL7 2.X interfaces

1. Assume that “all dates and times” are local to the sender
2. Never apply the MSH time zone to other, non-qualified times in the message
3. Don’t even support specification of time zones on any dates/times.

Ultimately the conversion of a time to a different time zone is almost always the responsibility of the receiver.

HL7 V3 has an almost obscene number of words regarding dates and times. Ultimately, the typical use for time stamps is summed up very nicely:

The value of a point in time is represented using the ISO 8601 compliant form traditionally in use with HL7. This is the form that has no decorating dashes, colons and no “T” between the date and time. In short, the syntax is “YYYYMMDDHHMMSS.UUUU[+|-ZZzz]” where digits can be omitted from the right side to express less precision. Common forms are “YYYYMMDD” and “YYYYMMDDHHMM”, but the ability to truncate on the right side is not limited to these two variants.

Any “feed”, whether an ADT feed, ORU feed or ORM feed, is basically a streamlined way of getting messages. In the HL7 standards world, ADT, ORU (order messages) and ORM (results messages) are the most common HL7 messages. Of those three, ADT messages are the most commonly used.

ADT stand for “admissions, discharges, and transfers”. It basically means demographics; anytime you think of ADTs, think demographics: the patient’s name, the patient’s location in the hospital, his or her address, phone number, gender, etc.

There are many different types of ADT message types, such as:

• Registering a patient
• Discharging a patient
• Merging patient files to avoid duplication

An ADT feed is one way an application or a provider can get all that information from a clinic or hospital information system (HIS). With the constant updating of a client, customer or patient’s data, ADTs comprise the most HL7 messaging traffic. Change of address, addition of a middle name, and addition of next of kin are all examples of the type of data updates that make up ADT messages. Upon updating, this clinical data will then flow out to different places such as outpatient clinics or laboratories, dependent on who needs that information in their database.

Typically, a hospital registration database will have the master of the patient data and information. Each time patient information is updated, the updates will be pushed out in the form of an ADT message to the appropriate applications in facilities such as labs or clinics.

ADT feeds are usually received through either an interface engine or direct (point-to-point) interface.

In the case of an interface engine, clinical data can be provided to a variety of places. An export can be set up so there can be a one-on-one connection where, for example, a hospital registration system can establish a connection to a lab outside of the hospital. “Data dumps” are also possible, where one end of the application has all the files and the other doesn’t and through the connection, the patient data can all be transferred.

In summary, ADT feeds are the most common and high volume feed used. The updating of patient information eclipses the volume of order and result feeds. Having up-to-date patient information, though, is a critical component in streamlining and improving the continuity of patient care.

Despite previous warnings, I recently committed a cardinal interfacing sin when working on an HL7 integration project. Upon kicking off a large project involving several applications with which we’re interfacing, I requested both specifications and sample HL7 messages from the vendor. The specifications came right away; the sample messages unfortunately did not.

Rather than making a big deal out of the messages and insisting that we get them prior to interface construction, I dove right in to perform a gap analysis based on the specifications that we were furnished in order to determine the incompatibilities between the systems involved. After carefully identifying the mappings required to transform the HL7 messaging such that it would satisfy each system’s specs, the interfaces were configured.

It was time to test, and out came the disappointingly small (in some cases just 1 or 2 messages per application) sampling of test messages that had slowly trickled in but had been shelved until the ‘real’ work of building the interfaces could be completed. Those messages were loaded, the interfaces were turned on, and voila!

Errors.

The sample data didn’t align with the specs, rendering my beautiful side-by-side comparison spreadsheets useless. The mapping tables I developed from those specs to translate representations of common fields such as gender, race, and relation? Worthless as well.

How could I have so quickly forgotten that the proof is almost always in the sample message pudding?

Specification documents are often hailed as the keys to unlocking the secrets of the import/export modules of healthcare applications and successfully brokering communication between disparate systems. Good specs do just that. The only problem is that you stand a better chance of finding a few needles in a hay mountain. They’re out there; they’re just not very plentiful.

The shortcomings of specs are attributable to a variety of factors:

• They’re rarely updated at the pace of development. While correct at a particular moment in time, changes are often times made to the interface that either never make it into the document or do so after those changes have been introduced to the marketplace.
• They’re often out of sync with upgraded software versions. Even if a vendor takes extreme care in updating both the interface and the specifications simultaneously, healthcare facilities may have upgraded their software since receiving their specification document and therefore unknowingly hand an outdated version to trading partners/interface analysts.
• Variances in installed modules/features are difficult to document. Many applications offer a wide array of software modules and features that can be alternatively installed depending on the customer’s budgets or workflow that make the production of a “one size fits all” specification difficult.

But the messages don’t lie. Having them takes the guesswork out of determining exactly what is coming out of or readily received by a healthcare application. Today’s most sophisticated interface engines will even go so far as to take those messages and build an HL7 derivative to which they’ll conform at the click of a button! There’s not much left to the imagination, and thus interfaces can be built with a much greater level of confidence.

So if you’re a vendor, be sure to stamp out a good sampling (at least 50) of anonymous messages for each message type supported through your application interfaces each time a change to the interface is introduced. Doing so will not only be appreciated by interface analysts trying to connect your systems to others in a hospital, clinic, imaging center, etc. It will also ease your own interfacing burden by reducing the number of calls and questions you field related to interfacing.

And if you’re an interface analyst, stranded on a deserted integration island and given the choice between sample messages and specifications to ensure your survival, always opt for the messages. They represent much more than a means to validate interfaces – they can be vital to successfully building them. Just make sure you don’t settle for 1 or 2 like I did.

HL7 does not provide a real world standard for controlling the display of text documents on the receiving system. While there are some rarely-implemented formatting codes provided in the Formatted Text (FT) section of HL7, often senders must deliver “plain, vanilla text” in order for a receiver to accept a text document via HL7 messaging. The receiver will then display the lines of text in whatever manner is appropriate for that application.

Typically this question comes up when someone is trying to ensure that text documents they send (such as a radiology report) will be displayed a specific way on a remote application. Asked another way, the sending HL7 user want to know if the receiving (remote) application will display the report in a given size font or a fixed-width font. The question revolves around the desire to put “low tech text formatting” in place to build things like tables, indented paragraphs, or even nicely word-wrapped paragraphs.

The reality is that HL7 messaging does not imply or demand that an application display a text report in any specific manner. If there is a need to ensure that the receiving application displays data in a specific way, the interface analyst must review the display mechanisms in the receiving application to see what is possible. The analyst must then change the message (text) format to work within those provided by the receiver’s display mechanisms. Typically the sender can not force the receiver to take a “pretty text document.”

The problems most frequently encountered when moving text reports are related to the size of the text, how long the lines can be, indenting text, the desire to make headers “stand out”, and how word wrapping is accomplished. All of these items are under the control the receiving application. In the real world, HL7 has no opinion on these issues.

Often applications support moving rich text documents via either an ED or RP data type. This means that the sender can deliver a PDF, Word document, RTF document, HTML document, etc — but only if the receiver supports the format. More details on rich documents are provided in this blog posting.