Appendix 3 Common Errors (Informative)

Common User Errors

SN ( Structured Numeric ) datatype misuse

Users sometimes don’t structure structured numerics according to the SN datatype specifications, which uses a number of components to represent numerical values and ranges.

Common errors are:-

Meaning	Correct use of SN	Incorrect SN	Incorrect SN
<5	<^5	<5	< 5
5	^5	5	+5
2.4 to 2.8	-^2.4^2.8	2.4-2.8	2.4 - 2.8

CE (Coded Entry) datatype misuse

There are several common misuses of the CE datatype which at minimum should have either an identifier+codesystem pair or a text description. If an identifier is supplied, then it should be accompanied by a code for the code system so that the receiving system can interpret the identifier correctly. For fields where an HL7 table has been specified in the standard, then that table should be considered the default valueset for that field.

For labelling observations (OBX-3), a LOINC identifier is often used. Some implementers routinely auto populate the CE.3 component with “LN” for LOINC, even when the identifier used for the value is clearly not a LOINC code. e.g. “|REPORT^Imaging Report^LN|”. In such cases, a “L” should be used to denote a Local code system.

OBR-24 Diagnostic Service Section missing

OBR-24 is used as a coarse level categorisation of report type - e.g. Microbiology vs Anatomical Pathology. Some laboratories still fail to provide this field correctly. The content of the field is often used by receivers or intermediaries to filter or route messages to the correct processing units. See HL7 Table 0074 for correct list of the allowed values.

Symbols and non-standard characters

By default, an HL7 message should only contain 7-bit ASCII printable characters ( and the <CR> end-of-line character for separating segments ). Some implementations fail to observe this, and send 8-bit characters or 7-bit non-printing characters, without correctly specifying the character set in MSH-18. See also HL7 Ambiguities below.

Incorrect HL7 reserved character escaping

This common problem occurs when one of the reserved HL7 field repeat, field, component or subcomponent separators is not properly replaced in the message by the appropriate escape sequence. This particularly occurs in ORU messages for '&', and '^' and '~' characters.

Null values

HL7 v2 supports 3 states for every field - populated, not-populated and null. Null is represented by and empty pair of double quotes "" and should rarely be used. See http://www.healthintersections.com.au/?p=1807 for guidance. Many implementations incorrectly use null ("") values, sometimes even as a dummy empty value for Required fields.

Incorrect ISO+ or UCUM units

Units are commonly supplied for numeric values in OBX-6. This field is a CE datatype, but very often only the first component i.e. the unit code is sent in HL7 messages. By default, this code should be an ISO+ code. HL7 Australia and the Royal College of Pathologists Australasia's PITUS project recommend using UCUM as the preferred system for units, in which case, all three CE components should be supplied. The following table shows commonly miscoded units and their correct form. The first component (CE.1) only is shown.

System	Correct	Incorrect	Incorrect	Incorrect
ISO+	mL/min/1.73m2	mL/min/1.73 m2
UCUM	mL/min/{1.73_m2} or ml/min/{1.73_m2}	mL/min/1.73 m2	mL/min/1.73m2	mL/min/{1.73 m2}
ISO+ or UCUM	10*6	10^6	x10*6	10\S\6
UCUM	24.h	24h	24hr
ISO+ or UCUM	m2	m^2	m*2	m\S\2
UCUM	10.kg	10kg	10.0kg	10Kg
UCUM	mm[Hg]	mmHg	mm{Hg}
UCUM	umol/(24.h)	umol/24.h	umol/24hr	μmol/24hr
UCUM	10*6.[CFU]/L	10*6[CFU]/L	10*6CFU/L

Unique IDs

Some implementations fail to observe rules about uniqueness of Identifiers.

In some implementations duplicate MSH message IDs (MSH-10) are used for the same report to multiple “copy to” doctors. This is contrary to the standard which specifies that every message must have a unique ID and breaks the acknowledgement mechanism. The message ID must be unique within the scope of the sending facility. Previously, the MSH-10 field length (20) did not support a GUID, but the field length has been increased and now does.

Reports are identified by the OBR Filler order number in ORU messages and the Filler order number entity Identifier must be unique within the scope of the Filler HD. Many messages are not scoped by the Filler HD and use very simple values e.g.“123” which makes uniquely identifying documents impossible. This causes duplicate results/documents and creates the potential to ignore documents that are thought to be the same as an existing document but in fact are from different organisations.

Misuse of FT datatype

The FT datatype is used to format text for display and supports multiple lines and emphasized characters. Systems displaying such text are expected to use a fixed pitch font to support alignment across lines, including simple tabular data. Implementers should check that at least 80 columns of text can be displayed or report formatting will be compromised. Common errors are incorrect end of line designators; incorrectly embedding HTML, PDF, or RTF strings; not correctly escaping special HL7 characters; illegal characters for the default or nominated ascii character set.

Incorrect use of character set in MSH-18

The default character set for HL7 messages is 7 bit ASCII. Even when implementations explicitly populate MSH-18 with 'ASCII', there are sometimes 8 bit characters included in some messages. If users need to use 8-bit characters then MSH-18 needs to indicate the character set used.

Incorrect usage of HL7 separator characters in ST for OBR-18, OBR-19, OBR-20

The special placer and filler fields in OBR are designed to allow individual systems to concatenate various pieces of information into the one field. Some implementers use '~' or '^' characters as separators, without escaping. This is incorrect usage.

Incorrect interpretation of PV1-Patient Class value 'N'

In a number of ADT and other message types, PV1 is a required segment. There are valid circumstances where this does not make sense, i.e. where no visit is associated with the message and therefore PV1 is irrelevant. HL7 introduced a special value PV1-2 (Patient Class) to support such circumstances. The value 'N', denoting "Not Applicable", should be used to indicate that the segment itself is not applicable and should be ignored. HL7 did this to maintain backwards compatibility. i.e. PV1 must still be sent for those message types where it is denoted a required field, even when it makes no sense. If the segment were not sent, then some receiving systems might reject the message as invalid.

The misuse of this special 'N' value is when systems send an 'N' for PV1-2 patient class when they wish to denote that a value for the concept "Patient Class" is not applicable, rather than the entire segment. Some pathology systems send an otherwise valid PV1 segment that may contain important information such as patient location (at time of sample collection) and referring doctor. Receiving systems could rightly ignore the content of this segment on the basis of the 'N' that has been misapplied. Although it may seem reasonable for a lab to believe that there is no visit by the patient to the lab, the intent of the standard is that the patient class refers to the context in which the request for a test was made. Table 0004 may not appear to have appropriate values to cover all contexts, e.g. 'visits' under the national Bowel Cancer Screening Program where an individual submits a sample to the lab in response to a solicitation by the Program. In such cases were a PV1 segment is sent in an ORU message, PV1-3 should be set to 'U' for "Unknown".

HL7 Specification errors and Anomalies

CM datatypes

CM (Composite) is not really datatype at all, but variable assemblies of simpler datatypes. The assemblies are context specific - i.e. vary from field to field within a message. For example, there are 5 completely different variants of CM datatypes in an OBR segment. CM was an anomaly introduced in certain fields of early versions of HL7. Those fields retained the rogue CM types in HL7 versions up until v2.5 when each CM was replaced by a proper, individual datatype for each relevant field. Thus HL7 v2.4’s OBR-32 (Principal Results Interpreter) changed from the rogue type CM to a dedicated NDL (name with date and location) datatype.

IS vs ID inconsistencies

In HL7, an ID datatype denotes that the coded value or identifier gets its meaning from a published HL7 table, managed by HL7 International. An IS datatype denotes that the code gets its meaning from a user defined table. Unfortunately there are some inconsistencies in the published HL7 specifications where

In v2.4 Chapter 2, a CX datatype specifies ID datatype for component Identifier Type code and points to HL7 Table 0203 - Identifier Type.

In v2.4 Chapter 2, an XCN datatype specifies ID datatype for component Identifier Type Code in the XCN structure table, but also IS datatype in the explanatory section and (wait for it) also points to HL7 Table 0203 - Identifier Type ( for suggested values ). This was partly corrected in v2.7 where ID is specified in both sections of the XCN specification.

HL7 Ambiguities

Case sensitivity

HL7 v2 standards have generally not been prescriptive about case sensitivity in Segment names, identifiers or field values.

Whitespace in fields

HL7 v2 standards are not prescriptive about leading or trailing whitespace ( SPACE character and TAB character ) in fields. This particularly plays havoc when trying to compare received values against stored values. It is a general problem in health data messaging and also occurs with the distribution and use of agreed code tables stored in spreadsheets.

Context alters meaning

OBR-7 (Observation Start Date/Time) and OBR-8 (Observation End Date/Time) mean different things, depending on whether a specimen is collected. If so, then they don't relate to the observation time at all. They relate to the collection time. The standard doesn't explain "collection", but appears to be collection from the patient, not collection from the collection site. E.g. a patient might take a urine sample, take it to a Laboratory collection site, perhaps at a health clinic, and then it is collected by the Laboratory courier and taken to the Lab for analysis. In this case, the Observation start and end times refer to the date/time the patient produced the sample.

Some segments and fields require or expect to be different between an order message vs a report (ORU) message.

HL7 Fields

OBR-16 Ordering provider

This field is not necessarily the sender or recipient . Refer to 4.4.1.16 OBR-16 Ordering provider (XCN) 00226.