The prominence of Health Level Seven (HL7) in LIMS

Healthcare Industry has seen massive digitization and standardization over the past years. With ever growing amount of patient related info, efficient storage, timely access, and security have now become top imperative features of any healthcare solution. A substantial amount of patient information is in the form of test results such as biochemistry, haematology, imaging, and pathology.

Healthcare industry possesses best in class medical equipment to provide accurate and timely reports of investigation and examination results. All the medical equipment available in the market is designed specifically to suit customized lab test requirements. The results are fed to a wide variety of devices. Most interfaces that aid in viewing the results are unclear and inefficient. Hospital Information Management System (HIMS) and Laboratory Information System (LIS) act as the backbone of the Healthcare Industry and help in better management and delivery of test results, thus reducing the Turnaround time (TAT).

Typical Laboratory Information Management System (LIMS) functions

• Patient file management
• Test request creation
• Specimen collection and identification
• Sample and request dispatching (Accession)
• Instrument connection and result acquisition (Interfacing)
• Quality Control (QC)
• Result consolidation and distribution
• Technical and clinical validation
• Billing and statistics management

The specimen testing process happens at Instrument level, which is the brain of the whole system.

What Is An Instrument Interface?

An instrument interface allows a lab instrument, whether it is a hematology analyzer or a cytogenetics imaging, to communicate with the institution’s LIMS. The LIMS, in turn, forwards the patient results directly into an EMR, rather than requiring a technologist or clerical person to manually re-enter data. Hence, it is faster, more efficient, and less likely to cause errors.

Interfaces are generally uni-directional, or bi-directional, or host-query but mostly a combination of all of the above. Different healthcare standards or initiatives serve different healthcare segments effectively in delivering critical information between systems. Examples of key healthcare integration standards include HL7, DICOM, HL7 CDA, CCR, CCOW, LOINC, ELINCS, X12, SNOMED, NCPDP, IHE, CCHIT, HITSP.

Given that legacy systems function behind the closed walls of their networks, it is not feasible for them to look into each other’s systems in any easy way. Instead, what legacy systems have to rely on is packaging up different pieces of data into a text file, and transmitting it securely to someone else. The main content-standard for these files has been HL7 (Health Level 7), where 7 is the layer 7 (Application) in the OSI Model.

Prerequisites for an Interface

Analyzers capable of being interfaced to an LIS are found in all areas of the clinical laboratory: Bio-chemistry, Haematology, Urinalysis, Immunology, Microbiology etc.; mostly, all clinical instruments that are equipped with a serial RS-232 I/O port. Many new communication points like USB and TCP/IP port are also provided.

Here is a list of basic requirements to interface with instruments.

A. Physical Hardware

The instrument must be equipped with an active I/O port to which computer devices may be connected.

• The host system must have a corresponding non-blocking I/O port available
• On clinical analyzers, this is a serial synchronous RS-232 port
• A connection cable from the analyzer to an interface device or the host system end point
• Devices like bar code scanners, printers, monitoring devices, etc.

B. Operating System Software

Operating system software is typically provided by a hardware manufacturer or a third party. It controls basic machine functions such as interaction with I/O devices, memory management, disk access, and creating the application software environment.

C. Data Formats

(i) RS-232 Serial Communication: These are the standards for communication with peripheral devices like clinical analyzers. The parameters that classify this category are:

• Serial communication parameters (baud rate, parity, data bits, stop bits, ASCII standard character set)
• The ‘handshaking’ protocol between host and a peripheral device for data exchange to occur: ACK/NAK
• Message blocking: how does each side of the communication define where a message begins and ends. For example STX, ETX for start bit and end bit
• Message structure (what will be the order of data fields or where is the sample ID relative to the rest of the data record?)
• Message content (what is the sample ID and what are the test names and results associated with this ID?

(ii) ASTM Protocol: Standards for communication between laboratory analyzers and information systems have been defined by ASTM (American Society for Testing and
Materials). It aims towards simplification of connection between clinical analyzers and information systems. There are two standards that currently apply: E 1381-91 that defines
protocol and E 1394-91 that defines format/content.

(iii) HL7 standard: HL7 attempted to define a standard for communication between various parts of healthcare information systems (HIS), principally system-to-system communication. In the standard of their initial efforts, HL-7 became aware of parallel efforts at ASTM. While the HL-7 group is organized separately, the communication standard they have adopted is largely the work of another ASTM subcommittee within the E31 committee group.

There are several HL7 versions.
HL7 v1.x – an old version, little used at present
HL7 v2.x – a plain text protocol, easy to implement and use
HL7 v3.x – a much more complex protocol with flexible and rich semantics, encryption, and electronic signature support
HL7 FHIR (Fast Healthcare Interoperability Resources) – a simple protocol presently being developed, based on open standards

Given that the HL7 FHIR is still under development, HL7 v3.x brings unnecessary complexities. HL7 v2.x remains the most widely adopted version. However, this version has a number of drawbacks, including security issues on almost all levels. Before HL7 V2, every interface between systems was custom made and required programming on the part of both the sending and receiving application vendors. Interfaces were expensive because there was no standard collection of patient attributes or standard set of ‘interesting events’.

Some forward-thinking, like minded, healthcare community members formed a volunteer group to make interfacing ‘easier’ – HL7 was born. It is critical to recognize that HL7 V2 was initially created by clinical interface specialists while V3 has been mostly created by medical informatists. Consequently, the initial use and focus for each standard is keenly different.

How to work with HL7 v2

This is an open source, best HL7 parser and library for Java, named Hapi.

https://hapifhir.github.io/hapi-hl7v2/
Doing a parse a HL7 message and created one hassle free.

HAPI also comes with a TestPanel GUI, where we can simulate instrument interfaces with different ports. One can spot HL7 messages sent to a system and receive acknowledgement.

Future scope

Consider any of the popular de-facto standards in use today: TCP, IP, HTTP, HTML, POP, telnet, Windows, or even the ASCII character set. They are all valuable because the user base has grown to multi-fold and the standards work in the real world. Similarly, the Network Effect for HL7 will increase with its usage in healthcare applications.

HL7 messaging standards are widely implemented by the healthcare industry and have been deployed internationally for decades. HL7 Version 2 (‘v2’) health information exchange standards are a popular choice of local hospital communities for the exchange of healthcare information, including electronic medical record information.

HL7 has recently embarked in the development of a new standard referred to as Fast Healthcare Interoperability Resources or ‘FHIR’. FHIR is a departure in both process and product from previous HL7 messaging standards such as HL7 v2 and v3.

HL7 FHIR combines the best features of HL7 V2, HL7 V3, and CDA, while leveraging the latest web service technologies. The design of FHIR is based on RESTful web services. This is in contrast to the majority of IHE profiles that are based on SOAP web services.

Future works in electronic health records area include futuristic technologies like IoT, Wearables, Blockchain, and AI with predictive analytics.