HL7 ERROR MANAGEMENT
ONC LABORATORY TIGER TEAM
PREAMBLE
This document describes errors that occur when the data contained within HL7 messages do not file successfully. In this
document, data contained within HL7 messages are considered to have filed successfully when ALL of the following criteria
are met:
1. All of the data within the HL7 message which are intended to be displayed to the intended end-user(s) of the receiving
system(s) are in fact completely and accurately displayed to the intended end-user(s) of the receiving system AND
2. Display on the correct patient AND
3. in the expected locations of the receiving system AND
4. in the expected format that was approved after validation of the interface was completed.
For example, if the locally defined expectation by the receiving system and its end-user(s) is that the data contained in an HL7
message containing a laboratory result is that the result should completely and accurately display in the ordering provider’s
inbox such that the ordering provider can see the complete and accurate result, then data contained within an HL7 message will
be considered to have successfully filed only when that data completely and accurately populates the inbox of the ordering
provider.
TYPES OF ERRORS (AND HOW TO RESOLVE THEM)
1.
Error which allows a system to consume an HL7 message successfully, but for which there is some other problem
that prevents the end-users of the receiving system from being able to use the information that the system has received
Sending
System
Receiving System
Successfully
sends HL7
message
Receives
HL7
message
Can consume
HL7 message
successfully
Can match patient in
HL7 message to a single
unique patient in the
receiving system
Yes
Yes
Yes
Yes
a.
b.
c.
All required
data
received,
accurate and
complete
Yes
Successfully
files
data within the
HL7 message
Yes
Examples:
i. No specimen arrives despite receiving the order.
ii. Specimen arrives but something is wrong with the sample and it cannot be processed
In other words, the system has functioned correctly but the humans surrounding it have dropped the ball
somehow
I would suggest that this is out of scope for this particular discussion because both the sending and receiving
systems sent messages that were accurate and consumable
2. Error which allows a system to consume an HL7 message and match it to a single patient (according to the locally
defined patient matching algorithm) and which does NOT cause any problem with successful filing of the result
Sending
System
Receiving System
Successfully
sends HL7
message
Receives
HL7
message
Can consume
HL7 message
successfully
Can match patient in
HL7 message to a single
unique patient in the
receiving system
Yes
Yes
Yes
Yes
a.
b.
All required
data
received,
accurate and
complete
Yes
Successfully
files
data within the
HL7 message
Yes
Examples:
i. I don’t remember what the examples for this were (sorry!)
Receiving system must log this error as a warning with “pending review” status.
Author: Alexis B. Carter, MD
Page 1 of 5
Version Date: 17 Apr 2014
HL7 ERROR MANAGEMENT
ONC LABORATORY TIGER TEAM
c.
These warning errors must be reviewed by a locally defined system user. The review and any action taken as a
result of the error must be documented before the warning error can be marked as “completed”.
d. Maximum time for completion of error review should be locally defined.
e. Error review logs should be easily retrieved by system users for inspection.
3. Error which allows a system to consume the HL7 message and match it to a single patient BUT which causes a
problem with filing of the information such that it can be used by the intended end-user (order, result, billing, etc.)
Sending
System
Receiving System
Successfully
sends HL7
message
Receives
HL7
message
Can consume
HL7 message
successfully
Can match patient in
HL7 message to a single
unique patient in the
receiving system
Yes
Yes
Yes
Yes
a.
b.
All required
data
received,
accurate and
complete
Yes
Successfully
files
data within the
HL7 message
No
Examples:
i. The dreaded tilde (~) key used in an AP report for which the system truncates the report text.
ii. Local system has determined that laboratory results should go to the ordering provider’s inbox, but
the result does not file to the inbox.
iii. Local system has determined that orders should go to the pending order list in the LIS, but they do
not go to the pending order list.
Dealing with this type of error will depend upon the specific category of error
i. Is the error something which a computer algorithm can reliably and 100% of the time detect as being a
problem created by the sending system?
1. E.g., Detecting illegal/forbidden HL7 characters in the data (e.g., tilde) – Checksums? (see
note on error #6 below)!!!!! – Bob, how can we brainstorm issues with the tilde key?
2. If the answer is yes, these should be handled with an automated ERROR DETECTED
message back to the sending system
a. ERROR DETECTED – illegal HL7 characters in encoded data
b. ERROR DETECTED – data integrity issue (checksums don’t match)
3. This ERROR DETECTED electronic message will file to a high priority (fatal) error log in
the sending system with “Pending Review” status
4. The sending system should correct the data and resend the HL7 message
5. If the error is not reviewed and marked “Resolved” by locally defined timeframes (but never
longer than 24 hours), then the sending system will automatically send an ERROR NOT
FIXED message back to the receiving system as a failsafe to let the receiving system know
that the sender has not addressed the issue. These ERROR NOT FIXED messages will file
in a high priority error log in the receiving system in a queue for staff to work.
ii. If the error cannot be reliably detected as a sending system error in an automated fashion, then the
receiving system should handle this type of error according to the mechanism described in #4 below.
4. Error which allows a system to consume an HL7 message but…
a. the information does not exactly match any existing patient record according to the locally defined patientmatching algorithm (data does not successfully file)
Sending
System
Successfully
sends HL7
message
Author: Alexis B. Carter, MD
Receiving System
Receives
HL7
message
Can consume
HL7 message
successfully
Can match patient in
HL7 message to a single
unique patient in the
receiving system
Page 2 of 5
All required
data
received,
accurate and
complete
Successfully
files
data within the
HL7 message
Version Date: 17 Apr 2014
HL7 ERROR MANAGEMENT
Yes
Yes
ONC LABORATORY TIGER TEAM
Yes
No
No
No
i. Examples:
1. One of the multiple patient identifiers does not match the information that the receiving
system has on the patient according to the rules that the organization has set for patient
matching
ii. Receiving system logs the error as a high priority error that requires immediate review and manual
intervention by a locally defined receiving system user(s)
iii. Documentation of intervention is required, and short turnaround time for addressing the error is
required
iv. If manual intervention by the designated receiving system user(s) does not resolve the issue (i.e., error
in the error log is not marked as “resolved”) within X timeframe
1. the receiving system staff handling the error manually initiate an electronic ERROR
DETECTED message or contact (e.g., phone call) the sending institution and perhaps also
the sending provider about failure to consume the message
a. If using the ERROR DETECTED message, this message files to a high priority error
log in the sending system which must be worked as described previously
2. May require staff from the sending system to examine, fix and re-post the message
3. If examine, fix and re-post does not work, may require faxing a paper order/result and
manual entry of information into the receiving system
4. If the error in the receiving system is not marked as “resolved” within X timeframe, then …
a. Standard electronic ERROR NOT FIXED message sent back to sending system that
data has not successfully filed in the receiving system and has not been resolved
(meaning that a provider has not gotten a result or a lab system has not gotten an
order)
5. X timeframe to be determined locally to ensure that patient care is not compromised (stat vs.
routine, etc.) but never longer than 24 hours
v. If manual intervention does resolve the issue, then no further action (except for documentation and
marking the error as “resolved”) is required.
b. There is required information missing (blank) from the transmission (patient demographics, “must have”
answers to ask-at-order questions)
Sending
System
Receiving System
Successfully
sends HL7
message
Receives
HL7
message
Can consume
HL7 message
successfully
Can match patient in
HL7 message to a single
unique patient in the
receiving system
Yes
Yes
Yes
Maybe
All required
data
received,
accurate and
complete
No
Successfully
files
data within the
HL7 message
No
i. Examples:
1. No date of birth
2. No order number
3. No ICD-9 code
ii. These are errors that a receiving system can easily detect upon receipt and respond to in an automated
manner.
iii. Receiving system sends an automated ERROR DETECTED message back to the sending system
1. ERROR DETECTED – missing data – specify which data
iv. This ERROR DETECTED electronic message will file to a high priority (fatal) error log in the
sending system with “Pending Review” status
v. The sending system (either automated or via manual intervention) should add the data and resend the
HL7 message
Author: Alexis B. Carter, MD
Page 3 of 5
Version Date: 17 Apr 2014
HL7 ERROR MANAGEMENT
ONC LABORATORY TIGER TEAM
vi. If the error is not reviewed and marked “Resolved” by the sending system by locally defined
timeframes (but never longer than 24 hours), then the sending system will automatically send an
ERROR NOT FIXED message back to the receiving system as a failsafe to let the receiving system
know that the sender has not addressed the issue. These ERROR NOT FIXED messages will file in a
high priority error log in the receiving system in a queue for staff to work.
vii. If manual intervention does resolve the issue, then no further action (except for documentation and
marking the error as “resolved”) is required.
5. Error which prevents a receiving system from consuming the HL7 message
Sending
System
Receiving System
Successfully
sends HL7
message
Receives
HL7
message
Can consume
HL7 message
successfully
Can match patient in
HL7 message to a single
unique patient in the
receiving system
Yes
Yes
No
No
a.
b.
c.
All required
data
received,
accurate and
complete
No
Successfully
files
data within the
HL7 message
No
Examples:
i. Faulty HL7 message received which is garbled (checksums don’t match? what standards already exist
to ensure that the data included in an HL7 message didn’t get truncated or otherwise garbled in the
process? )
ii. Portion of HL7 message exceeds the cardinality rules that we discussed previously (too many OBX
statements, etc.)
Receiving system should send a standard message back (similar to but the opposite of an ACK) called
“FATAL ERROR” or something similar which indicates that the message could not be consumed.
Sending system when they receive this “fatal error” message from the receiving system should flag this has a
high priority error for manual intervention under the algorithm described in #4.
6. Error which prevents a receiving system from receiving an HL7 message
Sending
System
a.
b.
c.
Receiving System
Successfully
sends HL7
message
Receives
HL7
message
Can consume
HL7 message
successfully
Can match patient in
HL7 message to a single
unique patient in the
receiving system
Yes
No
No
No
All required
data
received,
accurate and
complete
No
Successfully
files
data within the
HL7 message
No
Examples:
a. HL7 message lost on the network
Detected when sending system does not receive an ACK back on the HL7 message
Sending system should log this as a high priority error to be worked as described previously. If the issue cannot be
resolved and the message cannot be sent, the sender should be notified so that other arrangement can be made for
sending the data (paper, fax, etc.)
7. Error which prevents a sending system from sending an HL7 message
Sending
System
Receiving System
Successfully
sends HL7
message
Receives
HL7
message
Can consume
HL7 message
successfully
Can match patient in
HL7 message to a single
unique patient in the
receiving system
No
No
No
No
Author: Alexis B. Carter, MD
Page 4 of 5
All required
data
received,
accurate and
complete
No
Successfully
files
data within the
HL7 message
No
Version Date: 17 Apr 2014
HL7 ERROR MANAGEMENT
a.
b.
ONC LABORATORY TIGER TEAM
Examples
i. Sending system could not successfully construct an HL7 message or could not send the HL7 message
(software and network problems, etc.)
Sending system should have a mechanism to detect and resolve this issue. Receiving organization/institution
does not get involved unless the order/result can only be sent using manual methods (fax).
Author: Alexis B. Carter, MD
Page 5 of 5
Version Date: 17 Apr 2014