The HL7 standard states very precisely that each segment should be terminated with just one 0x0D (ASCII 13) character. A very common problem occurs when developers receive HL7 data from log files or do transfers of HL7 data via FTP using the ASCII mode.

When HL7 messages are saved in log files, the segment terminators are often converted to 0x0A (ASCII 10) characters or 0x0D 0x0A characters. What makes this confusing is that:

• These changes do not show up in text editors.
• Because the message browser strips out linefeed characters, the messages which are failing to parse programmatically will parse just fine in the browser.
• The error message will usually say that an unrecognized segment was encountered or that the segment grammar was wrong which masks the true problem.

If the 0x0D characters are missing at the end of each segment altogether, Chameleon ends up treating the message as one large MSH segment. This usually violates the segment grammar for the message so you get an error message such as the following:

Error in message grammar for LabResult message. It should be MSH PID [PV1] 
[ORC] [{NTE}] OBR [{OBX}] [DSC] 

If the 0x0D characters are present but followed by 0x0A characters, Chameleon will not be able to identify the second segment in the message. This is because it's trying to match a four character identifier, where the first character is 0x0A. The error message you typically see is that there is no such segment defined for this message, even though at first glance the segment appears to be present in your message definition file.

Fortunately there is a very easy way to diagnose this problem. When an exception is thrown in Chameleon, a large error report is generated about the exception. One especially useful part of that report is the hexadecimal dump which shows the exact characters that were given to the parser. One can inspect this printout visually to determine how each segment is terminated and whether there are illegal 0x0A characters there, or if the 0x0D characters are missing.

This following example error printout shows a message which incorrectly has additional 0x0A characters at the end of each segment.

Hex Dump of message data:
4D 53 48 5E 5C 7C 7E 26   5E 43 48 43 53 5C 4C 41   MSH^\|~& ^CHCS\LA
42 43 48 5E 4E 30 30 31   38 33 5E 44 41 54 41 47   BCH^N001 83^DATAG
41 54 45 5E 33 4D 5E 32   30 30 32 30 36 32 38 30   ATE^3M^2 00206280
31 30 30 35 34 2E 30 2D   30 34 30 30 5E 5E 4F 52   10054.0- 0400^^OR
55 5C 52 30 31 5E 4E 30   30 31 38 33 2D 32 34 31   U\R01^N0 0183-241
37 31 38 30 31 34 5E 50   5E 32 2E 33 5E 0D 0A 50   718014^P ^2.3^..P
49 44 5E 31 5E 5E 31 39   38 35 38 34 5C 5C 4E 30   ID^1^^19 8584\\N0
30 31 38 33 5E 32 30 2F   32 32 34 2D 35 32 2D 31   0183^20/ 224-52-1
37 33 34 5E 4D 49 54 43   48 45 4C 4C 5C 57 49 4C   734^MITC HELL\WIL
4C 49 41 4D 5C 41 5E 5E   31 39 32 30 30 33 32 30   LIAM\A^^ 19200320
5E 4D 5E 5E 4E 5E 36 33   36 20 52 49 56 45 52 43   ^M^^N^63 6 RIVERC
52 45 45 4B 20 52 44 5C   5C 43 48 45 53 41 50 45   REEK RD\ \CHESAPE
41 4B 45 5C 56 49 52 47   49 4E 49 41 5C 32 33 33   AKE\VIRG INIA\233
32 30 2D 30 30 30 30 5E   5E 37 35 37 2D 35 34 33   20-0000^ ^757-543
2D 36 33 34 32 5E 5E 5E   4D 5E 50 42 54 5E 5E 32   -6342^^^ M^PBT^^2
32 34 2D 35 32 2D 31 37   33 34 5E 5E 5E 39 5E 5E   24-52-17 34^^^9^^
5E 5E 5E 34 31 38 34 5C   55 53 4E 20 52 45 54 20   ^^^4184\ USN RET 
4C 4F 53 20 45 4E 4C 49   53 54 45 44 5C 5C 4E 33   LOS ENLI STED\\N3
31 5E 0D 0A 4F 52 43 5E   52 45 5E 30 32 30 36 32   1^..ORC^ RE^02062

There are four ways to resolve this issue:

• Use the 5.0 Parser Engine. This is the best and easiest solution since the 5.0 parser engine automatically bypasses any \n characters that may have been accidentally inserted after \r characters in segments.
• Fix your data and make sure it adheres to the HL7 standard.
• Use the Delimiters tab available in the Options window in Chameleon to change the segment terminator from 0x0D to 0x0A.
• Use the preprocessing python function (Chameleon > Global Inbound Script) to remove or transform illegal 0x0A characters from in the incoming HL7 message.