4

Placing an ASCII 10 (0A) character somewhere inside of a segment of an HL7 message to represent a new line character. Is this valid?

From what I can see it is recommend to use \X0D\ or \X0D0A\ to represent a new line character for plain text format HL7. Is using just the 0A ASCII character explicitly invalid HL7?

Ay Rue
  • 228
  • 1
  • 3
  • 15
  • 1
    If you are unfamiliar with HL7 escape sequences, take a look at this page or do a search. There are certain characters that you will want to take special consideration of and escape them if they are just text in a field (&, ~, ^, |, ...). http://corepointhealth.com/resource-center/hl7-resources/hl7-escape-sequences – Dale M Feb 23 '16 at 23:54

3 Answers3

4

To respond to the question "Is using just the 0A ASCII character explicitly invalid HL7?":

The character 0A is not mentioned anywhere in the HL7 specs as being special.

Extract from the HL7 2.5 US specs:

2.5.4 Message delimiters

In constructing a message, certain special characters are used. They are the segment terminator, the field separator, the component separator, subcomponent separator, repetition separator, and escape character. The segment terminator is always a carriage return (in ASCII, a hex 0D). The other delimiters are defined in the MSH segment, with the field delimiter in the 4th character position, and the other delimiters occurring as in the field called Encoding Characters, which is the first field after the segment ID. The delimiter values used in the MSH segment are the delimiter values used throughout the entire message. In the absence of other considerations, HL7 recommends the suggested values found in Figure 2-1 delimiter values.

Strictly speaking this would mean that you could use the character 0A just as any of the characters other than the 6 previously mentioned.

<end of "formal" reply>

That being said, I concur with Dale H. that you should better stay away from using this character in the content of an HL7 message. Since most editors (except old-fashioned Notepad on Windows) will display this character as a new line, you might unwillingly think that a segment was truncated or malformed. And I've had at least one instance where the interface engine indeed handled that character as a segment termination (which in itself is invalid, and the interface engine build was modified to not do this anymore).

So better avoid this. But in situations where you don't control the output, it doesn't seem to be a formally disallowed character...

Emilien
  • 2,971
  • 2
  • 22
  • 32
1

Linefeeds (0x0A) are not allowed in HL7 messages. If you edit messages with notepad, wordpad and many other text editors, they will convert carriage returns (0x0D) to CR/LF (0x0D 0x0A) and if you save, you now have a corrupt HL7 message. Avoid LFs (0x0A).

Dale H.
  • 36
  • 6
  • 1
    While I agree that Linefeeds (0x0A) should preferably not be sent in HL7 messages, I am not able to find a hard indication that it's prohibited. Chapter 2 (version 2.5 US) mentions in section 2.5.4 "Message delimiters" that there are 6 special characters (segment terminator, field separator, component separator, subcomponent separator, repetition separator, and escape character), with the segment terminator always being 0D and the other characters being defined in the MSH segment. But nothing about 0A not being allowed... Which would tend to mean it's "just another character". – Emilien Jul 31 '17 at 09:13
1

If you only send 0A then there is no way to determine that you wanted ASCII 10/line feed and it would be assumed you wanted a zero and an A.

Standard HL7 with the escape character being a \, then yes the recommended way would be \X0A\. The \X representing the start of hexadecimal data, followed by two-character hexadecimal values, ending with a \.

That being said, if you are sending this data to a system then they should be able to tell you what they accept for lines feeds. I've seen systems that use \.br\ or the repetition character ~ to determine a new line. And sometimes they want repeating segments. For example below, each OBX segment is a new line of a report in the system.

OBX|1|TX|||This is line one
OBX|2|TX|||This is line two
Dale M
  • 833
  • 16
  • 21