Health Level 7

Health Level Seven (HL7) International is a not-for-profit, ANSI-accredited standards developing organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services.


Under HL7, a "message" is two or more "segments" building in series, with each set of segments ("message") and resulting, generally speaking, in:

<Hex 0b>
<Message header segment><Hex 0d>
<e.g. Event segment><Hex 0d>
<e.g. Patient id PID segment><Hex 0d>
<e.g. Patient visit PV1 segment><Hex 0d>
<e.g. Diagnosis segment><Hex 0d>
<e.g. Allergy segment><Hex 0d>
<Hex 1c><Hex 0d>

where HEX values 0b, 1c, 0d correspond to ASCII/decimal 11, 28 and 13.

The MSH segment is required for all messages and will always be the first segment in the message. Thus every message will have at least two segments (over 120 different segments are available for use in HL7 messages). Each segment is characterized by (normally) pipe-separated fields in the form:

3-letter-segment-identifier|field1|field2|field3|field4|... etc.|<Hex 0d>

Observation results

Messages that contain observations include
  • lab test results
  • textual documents / reports such as pathologist and radiologist consultation reports

The applicable segments for message types identified within the MSH as 'ORU' (unsolicited) include:
  1. exactly one MSH segment which must be the first segment
  2. exactly one PID segment
  3. one or more ORC segments (each paired with, and followed by, an OBR segment)
  4. one or more OBR segments (each paired with, and preceded by, an ORC segment)
  5. zero to many OBX segments (none, for example, where an OBR is communicating a status of "pending" or where the ORC OBR contains only an NTE serving as a general comment on the order)
  6. optional other segments (e.g. NTE notes / comments) whose order among segments may vary

A restaurant "food order" analogy:

Concept Food Lab MSH 004 ORC 003 OBR 004 OBX
Order = one item or a combination of items Meal order involving one or more courses Lab order involving one or more test panels Laboratory name e.g. … multiple ORCs can share the same accession number while being otherwise internally differentiated e.g. … one OBR will follow each ORC, where sequence 004 might contain e.g. … zero to many OBX, but eventually ≥ 1, to follow each OBR e.g. …
Combination item, yielding multiple results: Protein with starch and vegetable Renal profile MDS 05-994065004-RENAL RENAL^Renal Profile six OBX segments will result:

Single item, yielding single result: Sliced strawberries Random blood sugar (aka random glucose) " 05-994065004-RBS-1

(trailing '-1' denoting first of two at same accession)
RBS^Glucose Random one OBX segment will result:

Glucose Random
double order two servings of sliced strawberries two specimens, whether taken at the same time or staggered " 05-994065004-RBS-2

(trailing '-2' denoting second of two at same accession)
RBS^Glucose Random one OBX segment will result:

Glucose Random

Following is an example of an XML-wrapped HL7 lab test result message, performed by lab BCB and delivered via the brokering system PATHL7 via receiving application HTTPCLIENT by receiver (praxis) 'ttest2' with the date stamp shown, declaring the message type to be an 'ORU' observation result, for fictitious patient Arfur Smiff, on whom a lab test order for just two electrolytes (sodium and potassium as 'LYTE') had been ordered by Dr Ian Medic, which was performed in the CHEM section of the lab and which is a completed ('F' final) result, and which is being copied to Dr William Osler, and which includes the specific results shown: Sodium 145 mmol/L (reference range 135 - 145) and Potassium 4.6 mmol/L with reference range of 3.5 - 5.0:

<?xml version="1.0" encoding="UTF-8" ?> 
- <HL7Messages MessageFormat="ORUR01" MessageCount="8" Version="2.3">
- <Message MsgID="1">
- <![CDATA[ 
OBX|1|NM|2951-2^Sodium||145|mmol/L|135 - 145|N|||F|||20010214154500
OBX|2|NM|2823-3^Potassium||4.6|mmol/L|3.5 - 5.0|N|||F|||20010214154500

Field separators, Encoding characters, and more

Segment Sequence Element name Local usage notes and reference
MSH 1 Field Separator by convention, the pipe |
2 Encoding characters ^~\&

Assuming the messages conform to the standard in the table above,
  • fields are separated by the "pipe" symbol, '|'
  • field components (composite field components) are separated by the "caret" symbol, '^'
  • repeating values within fields are separated by the tilde, '~'
  • escape character is typically the backslash, '\'
  • field components may be subdivided and separated by the "ampersand" symbol, '&'
  • blanks may be space-padded to their field lengths, but are more often simply omitted:
    • empty field: '||'
    • present but null" field '|""|' (null values being indicated by two double quotes)
    • empty components: '^^'

In the OBX segment, seq 2 (Value Type), the two-character codes may be

  • For atomic numeric results: ‘NM’ or ‘SN’
  • For atomic text results: ‘ST’ (‘TX’ is not recommended)
  • For full text reports: ‘FT’ or ‘ED’.
    • TIFF, FAX, JPEG, MSWORD etc. :‘ED’
    • HTML, PIT, RTF, and other ASCII formats: ‘FT’

The ‘begin new output line’ command (‘\.br\’) replaces carriage return and/or line feed

Python HL7 parsers

Nick Orlowski's code code lacked support of HL7 version-dependent field-naming.

John Paulett's code had limited object orientation. An overview of it is provided at

Luke Leighton refactored John's code.

There exists also a commercially-available library.

Topic revision: 13 Jul 2011, JamesBusser
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback
Powered by Olark