Understanding HL7 delimiters
- Eliot Muir
Consider an example HL7 message:
MSH|^~\&|EPIC|EPICADT|SMS|SMSADT|199912271408|CHARRIS|ADT^A04|1817457|D|2.5| 2
PID||0493575^^^2^ID 1~04494444|454721||DOE^JOHN^^^^|DOE^JOHN^^^^|19480203|M||B|254 MYSTREET AVE^^MYTOWN^O 3
NK1||ROE^MARIE^^^^|SPO||(216)123-4567||EC||||||||||||||||||||||||||| 4
PV1||O|168 ~219~C~PMA^^^^^^^^^||||277^ALLEN MYLASTNAME^BONNIE^^^^|||||||||| ||2688684|||||||Each line in the message starts with a three letter identifier and ends in \r 0x0D in hexadecimal. These are called “segments”.
Then each segment has a number of fields which are separated by the | character. The fields defined by the HL7 standard for the segment.
There are different versions of the standard and in fact most vendors are forced to interpret the standard and find places for the data that they have in their databases in the standard. This is a large source of variation which unavoidable.
Underneath | characters for fields we can have repeating fields which are delimited by the tilda ~ character:
|0493575^^^2^ID 1~04494444|Each field can have sub fields delimited with “^” character and we can even have sub sub fields which are delimited by the & character - that can be frequent source of bugs since user data often contains & characters.
A good HL7 implementation will escape these special characters with the escape sequences which all have the form \X\ - the character X will vary depending on the special character.