Smile CDR v2024.05.PRE
On this page:

27.14.1HL7 v2.x Protocol

 

HL7 v2.x support in Smile CDR is based on HL7 v2.5. The transaction, segment, and field definitions are described in the following sections.

Any data found in segments or fields not explicitly listed in this documentation will be ignored by Smile CDR.

27.14.2Encoding Format

 

Smile CDR supports both the HL7 ER7 (pipe-delimited) and XML encoding formats.

27.14.3ER7 (Pipe-Delimited) Format

 

As allowed in the HL7 v2.x specifications, any characters may be chosen as the special and/or delimiter characters specified in MSH-1 and MSH-2. By convention the following characters are generally chosen:

  • Field delimiter: | (pipe)
  • Component delimiter: ^ (caret)
  • Repetition delimiter: ~ (tilde)
  • Escape character: \ (backslash)
  • Subcomponent delimiter: & (ampersand)

The segment delimiter is expected to be a \r (ascii-13) character; however, Smile CDR will also accept \r\n (ascii-13 followed by ascii-10) in order to be lenient.

27.14.4Minimal Lower Layer Protocol (MLLP) Transport

 

Smile CDR allows the use of the MLLP protocol for transmission. This protocol consists of a simple TCP socket with the following payload:

[0x0b] [message payload] [0x1c] [0x0d]

27.14.5HL7 over HTTP

 

As an alternative to the MLLP protocol, the HL7 over HTTP transport may also be used.

This transport expects that requests and responses will be transmitted as plain text, using the MIME type of: application/hl7-v2

27.14.6Character Encoding / Charsets

 

Character encoding problems are a common pitfall in dealing with HL7 v2.x messages. It is common for non-US-ASCII characters to be lost when transmitting data using this format.

HL7 FHIR mitigates this issue by requiring the use of UTF-8 encoding; however, this is not a common approach for HL7 v2.x.

By default, Smile CDR will parse incoming messages using the platform default charset (often UTF-8 on modern servers). There are two strategies that may be used to override this behaviour, and these should be considered if you are deploying in an environment where non-US-ASCII data is expected.

27.14.6.1Using MSH-18

Sending systems are expected to provide their encoding charset as a value in MSH-18. For example, the following MSH header declares that the message is encoded using ISO 8859/1: MSH|^~\&|||||20171114141219||ADT^A08|001||2.3|||||DE|8859/1

This field is often misused in real world applications due to the blend of transport protocol and payload encoding in the HL7 v2.x design. If you know that MSH-18 will be populated correctly in your system, the charset.respect_msh18 property may be used. When this property is set to true, the message will be parsed using the value in MSH-18.

Note: This option is not used by HL7 over HTTP.

27.14.6.2Hardcoding a Charset

If the sending systems are known to use a specific charset in all messages, another approach is to force the use of a specific charset.

The charset.forced property allows you to specify a charset that will be used in all cases for the given listener.

Note: This option is not supported with HL7 over HTTP.

27.14.6.3Specifying Charset in HTTP Header

For HL7 over HTTP, if an incoming message includes a valid Charset with the Content-Type header, the message will be decoded using the specified Charset.