Archive for the ‘HL7 Standard’ Category

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 pointed out in previous posts, there is an ongoing drumbeat of discussion on the best way to realize Meaningful Use in the new HITECH world. Recently, HL7′s CEO and CTO wrote a column for Government Health IT entitled Leverage Today’s Standards for Meaningful Use. A key portion of the column states:

“To discard the existing data interchange standards and to replace them with something new and ‘simpler,’ as some are proposing, would be counterproductive.

Instead, we need updated and simplified tools and processes that leverage the existing standards and produce the needed interoperability.”

There is an obvious cynical angle that could be made of this column, since it is the HL7 leadership stating that the healthcare standards are just fine. The problem is the tools and processes, and the Federal government, according to this column, is doing great at building these tools and processes. Making that cynical argument may not be the most productive.

Granted the column was placed in Government Health IT magazine, so the expectation may be a more government focused article. Reading the column several times now, it is still unclear what is being advocated. It seems the arguments being advanced are:

• Keep HL7 and other standards as is, especially since it would be very costly to take a different approach in defining Meaningful Use.
• The government is using existing healthcare standards effectively today, and the government is building software applications to work with those standards. The government will “spur innovation.”

The HL7 column seems awkward. The first point is a compelling perspective to be taken into account in the formulation of Meaningful Use, especially with the aggressive time schedules. The second point on the government spurring innovation is more questionable. There is no doubt that the government is spurring the healthcare industry to action on implementing EHRs and facilitating greater healthcare interoperability. Do we really want government-developed applications as the standard though?

Two points should not be lost in the Meaningful Use discussion.

First, there should be a constant focus on how the changes will impact the delivery of patient care. High quality and efficient delivery of patient care should be paramount.

Second, the private sector needs to step up to the challenges and continue to drive innovation in the applications and devices being developed and offered. Unquestionably, the government has placed incentives and regulations into the market to motivate and constrain at the same time.

Sorting through these elements will be a challenge, and most healthcare application vendors are ready to take it on.

The Health Level Seven (HL7) organization announced its Electronic Health Record (EHR) System Functional Model Release 1.1 has been published as an international standard by the International Organization for Standardization (ISO). The press release can be read here (PDF). From the release, Don Mon, PhD, co-chair of HL7’s EHR Work Group, HL7 Board member, and vice president of Practice Leadership at AHIMA, stated the following:

“HL7’s EHR System Functional Model, Release 1.1 sets the standard to achieve common functionality of EHRs globally. This document had broad international input from clinicians, vendors, health information management and HIT professionals, and privacy and security officers that practice in a variety of care settings throughout HL7 affiliates and ISO participating national member bodies.”

For additional information, visit the HL7 EHR work group’s home page.

Recently, a poll was posted here asking, “Which HL7 version do you encounter the most in your interfacing projects?” Not surprisingly, the results offer some insight into the challenges awaiting greater HL7 v3 implementation. Ninety percent of respondents indicated they most encounter HL7 v2.x.

Below are the complete results:

• Version 2.3 – 36%
• Version 2.3.1 – 17%
• Version 2.4 – 12%
• Version 2.5 – 12%
• Version 3.0 – 10%
• Version 2.1 – 5%
• Version 2.2 – 5%
• Version 2.6 – 5%

As always, if you have a poll topic suggestion, please email them to us.

We are excited to introduce polling to www.hl7standards.com. You can participate and vote either on the home page or below the sponsor ads.

New polls will be added bi-monthly, and the results can be viewed after participating in the poll or clicking the “View Results” link at the bottom of the poll.

The current poll question, posted November 17,2009 is:

Which HL7 version do you encounter the most in your interfacing projects?

Vote now!

Please email us your ideas and feedback. We welcome any suggested poll topics or questions you would like to see in future posts.

Health Level Seven (HL7) announced this week the industry’s first ANSI approved standard that “specifies the functional requirements for regulated clinical research in an electronic health record system (EHR-S).”

In the press release, Donald Mon, PhD, co-chair of the HL7 EHR Work Group and member of the HL7 Board of Directors, stated:

“This profile is an excellent demonstration of how important functional requirements for secondary data use, such as clinical research, can be integrated into the patient care work flow and documented in EHR systems.”

Resources for this announcement are highlighted below.

• Healthcare IT News article:  HL7 offers standard for clinical research in an EHR
• HL7 Press Release:  HL7 Announces Industry’s First Electronic Health Record System (EHR-S) Functional Requirements Standard for Clinical Research (PDF)
• Electronic Health Records for Clinical Research (EHRCR) website and resources

A few news items from the HL7 Working Group meeting being held this week.

• HL7 Version 2.5 is approved as an international standard by the International Organization for Standardization (ISO). From the HL7 organization press release:

“We are pleased that HL7’s Version 2.5 is now an international standard,”
said W. Ed Hammond, PhD, chair of the HL7 Board of Directors. “The adoption
of this standard will increase the use of electronic healthcare data because many
countries that use standards mandate the use of ISO standards to share data,
reduce redundancies and improve patient care.”

• New HL7 Board members and volunteers of the year were announced. To read the press release about the new appointments, click here for the PDF. Congratulations to the HL7 Board members and for the all the hard work and dedication of all HL7 volunteers.

The 23rd Annual Plenary and Working Group Meeting is next week in Atlanta, GA, September 20-25, 2009.

The HL7 organization describes a working group meeting as:

“HL7 Working Group Meetings are held three times per year at varying locations. These Working Group Meetings serve two important purposes:

1. They give the HL7 work groups a chance to meet face-to-face to work on the standards;
2. They provide an invaluable educational resource for the healthcare IT community.”

In addition to the working group meetings, there are many HL7 training sessions that will be occurring during the meeting. It is a great opportunity to interact with many other HL7 professionals.

Kai Heitmann, who is the HL7 International Representative to the Board of Directors, reported this morning on the attendance mix at the September 2008 HL7 Working Group Meeting (WGM). Given that this meeting is the “international meeting” for the year and also Annual Plenary session, it is no surprise that the mix of US and international attendance is different than a typical WGM.

However, the numbers were pretty stunning in terms of the international attendance amongst the approximately 530 attendees: 44% of attendees are non-US. The break down (in attendee count)

• 100 from Canada
• 29 from UK
• 17 from Japan
• 15 from Australia
• 12 from Germany
• 11 from Korea
• 7 from France
• 5 from Switzerland

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.