HL7 Health Level Seven

BACKGROUND

• The term "Level 7" refers to the highest level of the Open System Interconnection (OSI) model of the International Standards Organization (ISO).
• Also, HL7 does not specify a set of ISO approved specifications to occupy layers 1 to 6 under HL7's abstract message specifications.
• "Health Level Seven standard that enables disparate healthcare applications to exchange keys sets of clinical and administrative data."

NEED FOR A STANDARD

• It is not uncommon today for the average hospital to have installed computer systems for admission, discharge, and transfer; clinical laboratories; radiology; billing and accounts receivable, to cite a few. Often these applications have been developed by different vendors or in-house groups, with each product having highly specific information formats.
• As hospitals need to share critical data among the systems has emerged.

GOALS OF THE STANDARD

• Implemented in the widest variety of technical environments.
• Implemented in a wide variety of programming languages and operating systems.
• Supported in a wide variety of communications environments.
• Immediate transfer of single transactions and multiple transactions.
• Supported the process of introducing extensions and new releases into existing operational environments.
• Cooperation with other related healthcare standards efforts (e.g., ACR/NEMA DICOM, ASC X12, ASTM, IEEE/MEDIX, NCPDP, etc.) has become a priority activity of HL7.

HL7 encoding rules
Message formats prescribed in the HL7 encoding rules consist of :

• data fields that are of variable length
• Separated by a field separator character.
• Rules describe how the various data types are encoded within a field and when an individual field may be repeated.
• The data fields are combined into logical groupings called segments.
• Segments are separated by segment separator characters.
• Each segment begins with a three-character literal value that identifies it within a message.
• Segments may be defined as required or optional and may be permitted to repeat.
• Individual data fields are found in the message by their position within their associated segments.

Concept

• Trigger event à an event in the real world of healthcare creates and initiates the need for data to flow among systems
• Two types of data flow:
  • unsolicited update/acknowledgement
  • query/result

CONCEPTUAL APPROACH
Trigger events:

• The real-world event is called the trigger event. For example: a patient is admitted may cause the need for data about that patient to be sent to a number of other systems.
• Transferring of information is initiated by the application system that deals with the triggering event; the transaction is termed an unsolicited update.

Acknowledgments: original mode:

• This acknowledgment mode specifies that it be acknowledged at the application level.
• It is also necessary to know that the receiving application processed the data successfully at a logical application level

"Acknowledgement" messages can confirm the sender that the message has been received.

Acknowledgments: enhanced mode:

• The HL7 acknowledgment has been extended to distinguish both accept and application acknowledgments, as well the conditions under which each are required.
• After the message has been processed by the receiving system, an application acknowledgment may be used to return the resultant status to the sending system.

Queries:

• A different data exchange occurs when one system sends a query to another.
• HL7 queries can be formulated using one of several methods (Select statements, stored procedure, Virtual Table requests, Query Filter via QRD and QRF segments, Event Replay Queries).

 

If a patient is unknown, e.g., in a laboratory system, an enquiry using an HL7 query can be generated and addressed to the administrative system. The answer contains the missing patient information.

HL7 MESSAGES

• A message is the atomic unit of data transferred between systems.
• It is comprised of a group of segments in a defined sequence.
• Each message has a message type that defines its purpose.
• For example the ADT Message type is used for Patient Administration (ADT) data from one system to another. A three-character code contained within each message identifies its type.
• The same trigger event code may not be associated with more than one message type; however a message type may be associated with more than one trigger event.

Admit/visit notification - event A01 (admitted patient)
MSH|^~\&|ADT1|MCM|LABADT|MCM|198808181126|ECURITY|ADT^A01|MSG00001|P|2.3|<cr>
EVN|A01|198808181123||<cr>
PID|||PATID1234^5^M11||JONES^WILLIAM^A^III||19610615|M||C|1200 N ELM STREET^^GREENSBORO^NC^27401-1020|GL|(919)379-1212|(919)271-3434||S|| PATID12345001^2^M10|123456789|987654^NC|<cr>
NK1|1|JONES^BARBARA^K|WIFE||||||NK^NEXT OF KIN<cr>
PV1|1|I|2000^2012^01||||004777^LEBAUER^SIDNEY^J.|||SUR||||ADM|A0|<cr>


Patient William A. Jones, III was admitted on July 18, 1988 at 11:23 a.m. by doctor Sidney J.Lebauer (#004777) for surgery (SUR). He has been assigned to room 2012, bed 01 on nursing unit 2000.
The message was sent from system ADT1 at the MCM site to system LABADT, also at the MCM site, on the same date as the admission took place, but three minutes after the admit.


Schematic content of an ADT message with the segments

MSH message header, EVN description of the trigger events, PID patient identification, PV1 patient visit information.

SEGMENTS

• A segment is a logical grouping of data fields. Segments of a message may be required or optional.
• They may occur only once in a message or they may be allowed to repeat.
• Each segment is given a name. For example, the ADT message may contain the following segments: Message Header (MSH), Event Type (EVN), Patient ID (PID), and Patient Visit (PV1).
• Each segment is identified by a unique three-character code known as the Segment ID.

FIELDS

• A field is a string of characters.
• HL7 does not care how systems actually store data within an application.
• When fields are transmitted, they are sent as character strings.

Position (sequence within the segment)

• Ordinal position of the data field within the segment.
• This number is used to refer to the data field in the text comments that follow the segment definition table.
• In the segment attribute tables this information is in a column labeled SEQ.

Maximum length

• Maximum number of characters that one occurrence of the data field may occupy.
• The maximum length is not of conceptual importance in the abstract message or the HL7 coding rules.
• The length of a field is normative.

Data type

• Restrictions on the contents of the data field.
• There are a number of data types defined by HL7.

Optionality

• Whether the field is required, optional, or conditional in a segment. The designations are:
• R - required
• O - optional
• C - Conditional on the trigger event or on some other field(s). The field definitions following the segment attribute table should specify the algorithm that defines the conditionality for this field.
• X - not used with this trigger event
• B - Left in for backward compatibility with previous versions of HL7. The field definitions following the segment attribute table should denote the optionality of the field for prior versions.

Repetition
Whether field may repeat. The designations are:

• N - no repetition
• Y - the field may repeat an indefinite or site-determined number of times
• (integer) - the field may repeat up to the number of times specified in the integer

Extract from the segment table for the PID segment SEQ : Position (sequence within the segment), LEN: Maximum Length, DT: Data Type, R/O: Optionality, RP/#: Repetition, TBL#: Table Number (of referred values), ITEM#: Number of the Item

MESSAGE CONSTRUCTION RULES

• Step 1 Construct the segments in the order defined for the message. Each message is constructed as follows:

a) The first three characters are the segment ID code
b) Each data field in sequence is inserted in the segment in the following manner:

• a field separator is placed in the segment
• if the value is not present, no further characters are required
• if the value is present, but null, the characters "" (two consecutive double quotation marks) are placed in the field
• Otherwise, place the characters of the value in the segment. As many characters can be included as the maximum defined for the data field. It is not necessary, and is undesirable, to pad fields to fixed lengths. Padding to fixed lengths is permitted. Encode the individual data fields as shown in Section 2.8, "DATA TYPES."
• if the field definition calls for a field to be broken into components, the following rules are used:

1. if more than one component is included they are separated by the component separator
2. components that are present but null are represented by the characters ""
3. components that are not present are treated by including no characters in the component
4. Components that are not present at the end of a field need not be represented by component separators. For example, the two data fields are equivalent: |ABC^DEF^^| and |ABC^DEF|.

• if the component definition calls for a component to be broken into subcomponents, the following rules are used:

1. if more than one subcomponent is included they are separated by the subcomponent separator
2. subcomponents that are present but null are represented by the characters ""
3. subcomponents that are not present are treated by including no characters in the subcomponent
4. Subcomponents that are not present at the end of a component need not be represented by subcomponent separators. For example, the two data components are equivalent: ^XXX&YYY&&^ and ^XXX&YYY^.

• if the field definition permits repetition of a field, the following rules are used, the repetition separator is used only if more than one occurrence is transmitted and is placed between occurrences. (If three occurrences are transmitted, two repetition separators are used.) In the example below, two occurrences of telephone number are being sent: |234-7120~599-1288B1234|

c) Repeat Step 1b while there are any fields present to be sent. If all the data fields remaining in the segment definition are not present there is no requirement to include any more delimiters.
d) End each segment with an ASCII carriage return character

• Step 2 Repeat Step 1 until all segments have been generated. The following rules apply to receiving HL7 messages and converting their contents to data values:

a) Ignore segments, fields, components, subcomponents, and extra repetitions of a field that are present but were not expected
b) Treat segments that were expected but are not present as consisting entirely of fields that are not present
c) Treat fields and components that are expected but were not included in a segment as not present.


APPLICATION (LEVEL 7) PROCESSING RULES
In overview this exchange proceeds as follows:
Step 1 the initiating system constructs an HL7 message from application data and sends it to the responding system
Step 2 responder receives message and

• 2.1 when the original acknowledgment rules apply:
  • validates the message syntactically and against the detailed rules
  • passes the message to the application, which:
    • creates a response message, or
    • creates an error message, or
    • creates a reject message
  • Sends the response, error, or reject message Initiator passes the message to the initiating application.
• 2.2 when enhanced acknowledgment rules apply:
  • The responding system receives the message and commits it to safe storage. This means that the responding system accepts the responsibility for the message in a manner that releases the sending system from any obligation to resend the message. The responding system now checks the message header record to determine whether or not the initiating system requires an accept acknowledgment message indicating successful receipt and secure storage of the message. If it does, the accept acknowledgment message is constructed and returned to the initiator.
  • At this point, the requirements of the applications involved in the interface determine whether or not more information needs to be exchanged. This exchange is referred to as an application acknowledgment and includes information ranging from simple validation to a complex application-dependent response. If the receiving system is expected to return application-dependent information, it initiates another exchange when this information is available. This time, the roles of initiator and responder are reversed.

QUERIES

• Immediate vs. deferred response Responses to queries can be either immediate or deferred.
• The query describes this as the expected response time. In the immediate mode, the responding process gives the response immediately or in a short period during which the requesting process will wait for the response.
  

QUERY TRIGGER EVENTS AND MESSAGE DEFINITIONS

• These are the trigger event types associated with queries:

1. a need occurs for immediate access to data that may be available from another application, this may be an initial request for data or a continuation
2. a need occurs for deferred access to data that may be available from another application

Where an original-style query is involved, these trigger events are served by the query message (QRY). When display data is involved, these trigger events are served by the Query (QRY) and Display Response (DSR) and General Acknowledgment (ACK) messages. When the query is for record-oriented data, the QRY message is used, but the response message is specific to a functional area. Record-oriented queries are described in detail in the relevant application chapters. Display-oriented responses are described in detail in this chapter.