What is HL7?
HL7 is a messaging protocol specifically developed to exchange health/medical/patient information between information systems.
HL7 messaging is widely used with in Hospitals and Medical Organizations in the USA, Europe, and Australasia. HL7 is endorsed as a standard by the
American National Standards Institute (ANSI).
Why is HL7 necessary?
Consider for example, when a patient is admitted to hospital. The Patient Administration System (PAS) records details about the patient (demographics), and the admission (admitting doctor, ward, financial details). There is likely to be several other systems such as Pathology Laboratory Information Systems or Pharmacy Systems, which will be interested in these details. So a message telling each of the interested systems in the hospital about the patient needs to be sent from the PAS. Or alternatively, the systems may wait until they need to provide a service to the patient, and then send a query to the PAS for details.
Whether the details are delivered via an announcement from the PAS or in response to a query, the PAS needs to communicate information about a patient to several different systems. Before HL7 was developed, vendors of information systems needing to communicate between each other had to get together and work out what information was going to be sent between each system, and how it should be formatted. This would then require the creation of a new interface mechanism to handle this information flow. Naturally, this was an expensive and time-consuming process. Can you imagine having to learn a new language for every different person that you talk to?
HL7 was developed to provide a common language for Health/Medical-based information systems to use when sending information to each other.
HL7 stands for Health Level Seven. The Level Seven refers to the seventh layer of the ISO communications model. This is the application layer, and basically means that HL7 is only interested in the formatting or structure of the information, not the technical details of how the information is passed from one system to another.
HL7 Messages
HL7 messages are generally created and sent by an information system in response to an event occurring. The event might be something such as a patient admission, a finalized pathology result, or a it may be query from another system. And each message contains information about that event.
Each HL7 message is made up of segments. Segments are the building blocks of HL7 messages, each segment has a three character name and a pre-defined format of specific fields. The fields are separated by the | (pipe) character, and may be further divided into sub-components with the ^ character.
Segments group related information together, for example the PID segment contains information patient information such as ID numbers, name, address and date of birth.
Different HL7 events trigger different message types - each message type has a defined set of segments that are joined together to provide all the required information regarding that event. Some segments are mandatory, and must be included in the message, and other segments are optional.
For example:
Event : A Patient is Admitted to Hospital
An HL7 Message made of the following segments would be created:
- MSH - Details about the message such as sending and receiving systems, dates and message type
- EVN - Details about the triggered event such as event type, event date/time, the person that triggered the event
- PID - Details to identified the relevant patient
- PV1 - Details of the patient’s visit to hospital, such as visit number, ward/bed, attending doctor, financial classification
The actual HL7 message might look something like:
EVN|A01|20020313173614149|||a017
PID|||875665^^^PH||NGO^LISA^^^Ms||19750514|F|||101 COLS STREET^^MELBOURNE^VIC^3000
PV1||I|3S^13^1^^^^^^Ward 3 Wouth||||TESTDR^TEST^JOHN^^^DR|||ORT|||||||||15521|COM|
The HL7 standards manual available from HL7 Inc. provides extensive details on trigger events, message types, and segments. Because the HL7 standard provides for a high degree of flexibility, standards bodies in individual countries may also publish implementation guides, to assist with implementation and encourage interoperability between local vendors. Refer to the standards body relevant to your country for more details.