December 20, 2010

Inside HL7 Standards
By Lee DeOrio
For The Record
Vol. 22 No. 23 P.32

To get a better understanding of Health Level Seven International’s (HL7) family of standards, For The Record (FTR) exchanged e-mails with Eliot Muir, founder and CEO of iNTERFACEWARE. The goal was to get a better idea of how HL7 version 3—designed to support large-scale data exchanges—was being accepted in the healthcare community. Also on the agenda was an overview of the differences between HL7 and Web-based solutions.

FTR: What’s different about HL7 version 3?

Muir: HL7 version 2 (V2) was developed with the goal to standardize and reduce the cost of building interfaces in healthcare. To expedite the adoption of these standards and to increase the number of users, clinical interface specialists and vendors tried to incorporate data fields and interface frameworks already in use. As a result, V2 was a set of loosely defined standards built in an ad hoc way but easy to conform to. Version 3 (V3), on the other hand, was developed with a more ambitious goal of making a complete data model framework to try and achieve consistency across the whole message set. Also, V3 is XML based and therefore each message is significantly larger by one or two orders of magnitude compared to V2.

FTR: Who is using this version?

Muir: The early adoption of V3 standards has been limited to organizations with applications without legacy communication requirements and some government agencies. So far, adoption is not widespread. It is still too early to find any widespread examples of V3 deployments. While no formal statistics are available, it is safe to assume that the total market share of V3 is probably less than 0.1%.

FTR: Is it true that V3 is being used more by labs, immunization registries, etc and not by large hospital systems? If so, why?

Muir: Yes, that does seem to be the case. The immunization registries typically run stand-alone systems that use software developed internally by the government. This software is often given to them so that different registries can all run the same software at both ends of the exchange. This is different than trying to integrate disparate vendor systems. Hospitals don’t typically have the budgets to develop custom software that government agencies have. Their integration needs are well defined in scope. They usually own existing legacy systems that can run on old operating systems. Therefore, HL7 V2 is an effective common interoperability standard for them. Overall, unless there are compelling cost benefits or ROI [return on investment], it is very tough for a new standard to displace an existing standard.

FTR: What does HL7 V3 need to do to become widely adopted?

Muir: We anticipate a lot of resistance toward the adoption of V3 standards. So far, even government mandate to adopt V3 standards has not been successful in driving the adoption of these standards. Its current iteration is so complicated that projects in a number of countries, including the United Kingdom and Canada, have not generated an acceptable ROI for these countries to push for the adoption of V3. With the current state of the economy and increased scrutiny on taxpayers’ money, the funding for these types of experimental projects is likely to dry up.

From a technical standpoint, V3 has failed to keep pace with the new software trends toward simpler and faster solutions. Browsers are getting faster; consumers and hospitals have an interest in more lightweight operating systems like iOS and Android. V3 goes against these trends by being more cumbersome to use and heavy on both human and computer resources. To displace HL7 V2, HL7 V3 needs to overcome two serious obstacles:

• deliver compelling end-user benefits that will encourage organizations to justify their investment and spending into these standards; and

• facilitate an easy migration from V2 to V3.The current version of HL7 V3 is completely incompatible with HL7 V2.

Healthcare organizations will not be motivated to transition to V3 if they have to abandon their V2 interfaces and reinvent the wheel. Some approaches that might help include:

• Bypass V3 and move on to V4. We all know that V3 falls short of addressing the needs of the current healthcare market. V3 doesn’t have a good reputation in the healthcare industry. Just like Apple doesn’t try and resurrect Newton, organizations should forget past failures and focus on the next version.

• Identify an area of V2 that is particularly underserved and can be standardized to deliver more economic benefits.

• Deliver a simple and concise specification of concrete messages that can be exchanged. The emphasis should be on the messages themselves and not the design process of how they were specified.

• Simplify implementation by using a plain format like JSON (www.json.org) over HTTPS. This would help minimize the complexity of the protocol and make it easy for developers to implement on both existing and older platforms.

• Provide empirical data to demonstrate that this new protocol can solve a real problem. Validate the standard by actually translating 100 different V2 implementations to the new standard to encourage users to switch. Bring it back to looking at empirical data.

FTR: Please explain the differences in trying to share data using HL7 as opposed to Web-based solutions.

Muir: Integration of any kind brings tremendous benefits to an organization. It saves them the trouble of reentering data into different systems. It also helps them to correlate and cross-reference information. The benefits of integration are the same, irrespective of how the underlying information is transmitted. HL7 V2 is more cost-effective than Web-based methods for transmitting data for two main reasons:

First, almost all major healthcare IT systems support it. In fact, many legacy systems running on older mainframe and Unix platforms form the backbone of many hospitals’ IT infrastructure and also support the standards.

Second, HL7 V2 provides a common schema for the structure of the information being transmitted. This enables organizations to integrate faster than what is possible with less-standardized Web-based interfaces and avoid transforming existing systems dramatically or custom coding.

Additionally, HL7 V2 is typically sent unencrypted over transmission control protocol or Internet protocol with simple header and trailer characters, also known as lower-layer protocol. It is a very small, efficient protocol that was designed when computers and networks were not as powerful as today. Therefore, it is easy on resources and bandwidth. Lastly, with a vast network of users with many years of experience using HL7 standards, new users can apply this knowledge in their own context and get up and running quickly.

FTR: What are HL7’s limitations?

Muir: HL7 standards are not great for exchanging imaging data. The standards lack many of the features that an imaging-focused protocol like DICOM has. DICOM has facilities to describe gray scales, encode images, and provide support for sending large volumes of data over a network. Additionally, developers not proficient in the healthcare industry can find the HL7 protocol a little unfamiliar to work with due to its EDI [electronic data interchange]-like syntax.

FTR: Why would a healthcare organization choose to exchange data using HL7?

Muir: HL7 standards are the most widely deployed standards across the healthcare industry. They have successfully eliminated the headache of custom designing and programming on the part of both the sending and receiving application vendors. HL7 standards have been around long enough to be tried and tested for creating interfaces. They have helped the healthcare industry reduce costs by outlining best practices for processes such as collection of patient attributes or a standard set of interesting events.

FTR: Are Web-based solutions considered more versatile?

Muir: Web-based solutions are definitely gaining popularity as they can be accessed from anywhere. As mentioned earlier, Internet bandwidth is no longer an obstacle. However, for new Web-based products and services to be successful, it is important for them to be interoperable with the key systems that hospitals run today. Many systems that were designed in the ‘70s and ‘80s have been able to support HL7 V2 but do not support the latest in Web standards.

FTR: Can a healthcare organization using HL7 share data with a colleague that uses a Web-based solution?

Muir: Yes, it is possible. Pharmacy OneSource, a provider of real-time infection prevention surveillance, document, and reporting systems is a great example. They are a software-as-a-service provider to more than 1,300 hospitals in the United States and help hospitals identify infections and negative drug interactions in real time, enabling clinicians to intervene quickly. The company uses cloud-based applications to exchange more than 5 million HL7 messages a day from its healthcare clients via VPN [virtual private network] connections. As a result, Pharmacy OneSource is able to transfer an organization’s existing lab, patient, and medication data via HL7 interfaces between its many customers and Pharmacy OneSource’s data centers accurately.

FTR: Please explain the differences of trying to meet meaningful use requirements using HL7 or a Web-based solution.

Muir: Healthcare organizations can meet their meaningful use requirements through both HL7 as well as Web-based solutions. The big difference is the motivation. If an organization is only looking to meet the requirements, Web-based solutions might make sense. However, if the goal is to truly integrate with other healthcare systems and ensure interoperability, then HL7 is a better alternative as most big vendors support HL7.

— Lee DeOrio is editor of For The Record.