HL7 standard

HL7 Standard Description

HL7 standard is an abbreviation of “Health Level Seven” where “Level Seven” refers to the Seventh OSI layer protocol for the healthcare environment.

The 7 OSI levels or layers are:
Level 7: Application Layer
Level 6: Presentation Layer
Level 5: Session Layer
Level 4: Transport Layer
Level 3: Network Layer
Level 2: Data Link Layer – the WAN Protocol and IEEE 802 LAN architectures
Level 1: Physical Layer.

HL7 standard is a standard for exchanging information between medical applications. As the name HL7 implies, the HL7 standards are principally concerned with application to application communication independently of the other 6 levels. In very general terms, HL7 is a protocol for data exchange in that it defines the format and the content of messages that healthcare applications use when exchanging information with each other. HL7 standard is not concerned with how messages are delivered between applications. An implementation can use TCP/IP connection or FTP file transfer or an HTTP post to deliver a message. HL7 standard does mandate a minimal lower level transport Protocol.

Medical institutions use many different types of applications that need to communicate information with each another. Patient medical records, facility admissions, transfers and discharges, billing information as well as test ordering and results all need to be communicated between medical systems. HL7 standard was designed by a combination of Medical providers, information system providers and others to provide a ‘standard’ mechanism or a structured protocol to accomplish communicate between healthcare applications.

HL7 standard is event driven in that actual events like a patient admission or the ordering of a test cause messages to flow from one application to other applications that need to know about the event. The patient admission to a hospital causes a bed and room to be assigned to the patient; the patient previous medical history needs to become available to the staff, etc.

HL7 provides a ‘standard’ protocol that, in theory, allows one implementation for all users. Any system, independent of the vendor can receive broadcast data as long as the receiving system accepts the standard protocol.

In practice, HL7 standard implementations are not “plug and play”. Each medical provider and each information systems vendor tend to have their own HL7 version of an interface. This is complicated by the fact that there have been a series of versions of HL7 – 8 version 2.x releases and 1 3.0 release.

All of the 2.x versions of the standard are backward compatible in the sense that things have been added, but nothing has been taken away. Assuming that the standard HL7 Parsing rules have been followed, all of the 2.x versions are backwards compatible in that the parsing rules simply ignore the added fields.
Thus a version 2.6 field patient name |Jones^Eunice^M^^Mrs.^^L| is equivalent by parsing to the 2.2 field patient name |Jones^Eunice^M|

Development of the version 3.0 of the HL7 protocol started in 1997. HL7 V3.0 is based on a formal model called the Reference Information Model (RIM). The goal of V3.0 is to reduce implementation costs and further standardize communication systems.

V3.0 is a complete redefinition of HL7 standard that changes the content of the messages and fields as well as the encoding rules, the Lower Level Protocol, and data types. It is XML based instead of the segment structure used in Version 2.x.

In theory HL7 3.0 will be easier to implement than Version 2.x. In practice, it has been in development for 12 years and is not completed. It is not backwards compatible to the 2.x versions. It is radically different than the 2.x versions and does not provide any upgrade path. Lastly I know of no implementation of
V3.0. In comparison, the 2.x versions are backwards compatible and are widely implemented. In order to achieve a consensus, (HL7 standard was designed by a committee), many fields defined as optional. The problem is you cannot be certain that specific information will be present in a given message. This is one of the reasons why the same message may vary significantly from vendor to vendor.

Leave a Reply

Your email address will not be published.

Post Navigation