HL7V2.x Implementation

The key activities that need to be considered for the implementation of a HL7 version 2.x are

• Identifying the list of relevant messages from the standard documentation set


• Mapping of the fields in the messages to the attributes in the application database


• Identifying the tools and methods for construction of messages based on the triggers in the application


• Identifying the tools for message communication and validation.
  

Message Identification

The messages are identified based on the data flows required for the healthcare organization. The transactions that need to trigger these messages in the sender need to be identifier along with the list of receiving systems. The required and optional segments in each of the messages are identified. Any implementation specific data those are not available in the standard segment need to be sent in the user defined Z segments.

Message Mapping

Message mapping involves mapping of HL7 data elements to the application tables, columns and code sets. This is a crucial step of the implementation and involves specialist knowledge of the application and healthcare domain.

Message Generation

The construction and generation of version 2.x messages from healthcare systems can be done using three different approaches which are depicted in Figure and described below

Native Generation – The messages can be generated natively within the application using the same software components that makeup the core application. This approach is advantageous for enterprises with lower interfaces and a small number of departmental systems. This approach is essentially based on point-to-point integration and not suitable for organizations with complex interfaces and large number of departmental systems.

Middleware Approach – This is external to the applications and applications used different mechanisms to communicate with the middleware. These range from systems sending messages and data in a proprietary format based on the event to middleware and it building the message into HL7 format to message sending standard HL7 messages and middleware validating the message before sending the message in format understood by target system.

API Approach – This approach involves deploying readily available software components and libraries external to the application and modifying the applications source code to make a call to the libraries. This is ideal for closed legacy applications and quickens the deployment of HL7.

Messaging Communication

The most commonly used mechanism for sending HL7 Version 2.x messages is Lower Layer Transport protocol (LLP). The messages are sent over TCP/IP over the network.

The protocol is very simple to implement using the implementation setting sockets. The protocol requires that that each message should be preceded with the character 0x0B (11) and followed with the characters 0x1C (28) and 0x0D (13). This is required for communications code to be able to recognize the start and the end of each message Finally each segment is terminated by a 0x0D (13) character. This is mandated by the standard, but often HL7 log data can be received via ftp or email where the segment separators have been transformed into 0x0A characters, etc.

See my post on MLLP and HLLP for more details

Major Implementations of HL7V2.x

Several countries in the world have recognized version 2.x of HL7 as national standard for example version 2.4 is established as a German Industrial Standard. The SCIPHOX (Standardized Communication of Information Systems in Physicians Offices and Hospitals) used standard HL7V2 for communication between hospitals though it used CDA (Clinical Document Architecture; for communication between hospitals. SCIPHOX encompasses laboratory results, diagnoses, medications, procedures and referral data.

National Healthlink Project in Ireland is an electronic communications project between GPs and hospitals. Version 2.4 with XML encoding is used as the messaging standard; for example ADT A01 is used to notify GP’s of a patient visit to A&E; ADTA03 is used to notify GP’s that their patients have been discharged or died. Apart from ADT ORU R01 is used to notify Radiology and Pathology results of patients to their GP’s.

The national layer of Australian Standards documents in the AS4700.x series constrain and localise the ANSI/HL7 v2.x series of standards for use in Australian healthcare settings. Version 2.3/2.3.1 is used for Patient administration, Pathology orders and results, Electronic messages for exchange of information on drug prescription, Discharge and Referrals. Though some of the standards have not been upgraded to 2.4 with most of the sites still using version 2.4


The application vendors and Local service providers of NHS - Connecting for Health programme which are one of the frontrunners in implementation of HL7V3 are using variants of HL7Version2 (CSC: UK HL7vA.2, HL7V2.3,HL7V2.4; BT: UK HL7V2.3;Fujitsu: HL7V2.3) for intra-organisation communication.