ehr-s functional requirements ig: lab results interface error handling 7/7/2014
Post on 17-Dec-2015
217 Views
Preview:
TRANSCRIPT
Acknowledgement Message Structure
TABLE 3‑2. ACK^R01^ACK ABSTRACT MESSAGE SYNTAXSegment Name Usage Cardinalit
y
C.LEN Description
MSH Message Header R [1..1] The message header (MSH) segment contains information describing how to parse and process the message. This includes identification of message delimiters, sender, receiver, message type, timestamp, etc.
[{SFT}] Software Segment O [0..*] MSA Message
AcknowledgmentR [1..1] The Message Acknowledgment Segment (MSA) contains the information sent as
acknowledgment to the result message received by a Electronic Health Record System.
[{ ERR }] Error C(R/O) [0..*] Condition predicate: If MSA.1 (Message Acknowledgement) is not valued AA or CA
Guaranteed delivery is required. Where use of an ACK is appropriate for the transport mechanism it should be used as described in this guide. All other acknowledgement methods are beyond the scope of this document (e.g., acknowledgement of batches using the HL7 batch methods).
MSA
TABLE 3 6. ACKNOWLEDGMENT SEGMENT (MSA)‑
SEQ Element Name DT Usage Cardinality Value Set Description/Comments
1 Acknowledgment Code ID R [1..1] HL70008 2 Message Control ID ST R [1..1] 3 Text Message X Excluded for this Implementation Guide, see Section 1.3.14 Expected Sequence Number O 5 Delayed Acknowledgment Type X Excluded for this Implementation Guide, see Section 1.3.16 Error Condition X Excluded for this Implementation Guide, see Section 1.3.1
The Message Acknowledgment Segment (MSA) contains the information sent as acknowledgment to the result message received by a Electronic Health Record System.
ERR
TABLE 3 7. ERROR SEGMENT (ERR)‑
SEQ Element Name DT Usage Cardinality Value Set Description/Comments1 Error Code and Location X Excluded for this Implementation Guide, see Section 1.3.12 Error Location ERL O RE [0..1] Use to identify segment/field where error occurred3 HL7 Error Code CWE R [1..1] HL70357 Expand table values4 Severity ID R [1..1] HL70516 Possibly limit5 Application Error Code CWE O
C(RE/O)[0..1] HL70533
(2.7.1)CP: If ERR-3 is valued “code for application error”Empty table, can supply suggested values as a base set for lab IGs, remains user defined and is extendable
6 Application Error Parameter O 7 Diagnostic Information TX RE [0..1] IS OPTIONAL IN IMMUNIZATION
Definition: Information that may be used by help desk or other support personnel to diagnose a problemLength: 2048
8 User Message TX RE [0..1] IS RE IN IMMUNIZATIONDefinition: The text message to be displayed to the application user. Length: 250
9 Inform Person Indicator O 10 Override Type O 11 Override Reason Code O 12 Help Desk Contact Point O
The ERR segment is used to add error comments to acknowledgment messages.
Table 0008 Acknowledgement Code
Value Description
AA Original mode: Application Accept - Enhanced mode: Application acknowledgment: Accept
AE Original mode: Application Error - Enhanced mode: Application acknowledgment: Error
AR Original mode: Application Reject - Enhanced mode: Application acknowledgment: Reject
CA Enhanced mode: Accept acknowledgment: Commit Accept
CE Enhanced mode: Accept acknowledgment: Commit Error
CR Enhanced mode: Accept acknowledgment: Commit Reject
Table 0357 Message error condition codes
Value Description
0 Message accepted
100 Segment sequence error
101 Required field missing
102 Data type error
103 Table value not found
200 Unsupported message type
201 Unsupported event code
202 Unsupported processing id
203 Unsupported version id
204 Unknown key identifier
205 Duplicate key identifier
206 Application record locked
207 Application internal error
Table 533 suggested codes
Value Description
Can’t match Patient Can’t match ProviderCan’t match local code
1 Illogical Date error
Date conflicts with another date in the message.
2 Invalid Date
Date is not valid or lacks required precision.
3 Illogical Value error
The value conflicts with other data in the message
4 Invalid value
The value is not valid. This applies for fields that are not associated with a table of values.
5 Table value not found
The value is not found in the associated table.
6 Required observation missing
A required observation, such as VFC eligibility status, is missing.
Table 0516 Error Severity
Value Description
E Error
F Fatal Error (v2.7.1) = hard error
I Information
W Warning
Error Handling OverviewERROR HANDLING • As a follow up item to the LRI and LOI IG publications November 2013, the S&I Lab
WG analyzed and discussed the various error situations that should be formally addressed with consistent guidance and testing to ensure consistent and robust end-to-end interoperability from the construction of a laboratory order within an EHR to the receipt of results by an EHR.
• The topics were originally addressed as two tracks – LOI [item LOI 1.7, LRI [item LRI 1.5] – but were merged into a single conversation and set of decisions reflected in item LRI-1.5, excerpted below.
Definitions– NEED TO DEFINE WHAT THE RESPECTIVE MESSAGES FOR THESE LOOKS LIKE (not used in immunization that way)• Hard Error – full stop; suspend processing and notify sender, do not commit info to
patient record• Soft Error – notify (as directed) but can continue to process message unless a
hard error is encountered prior to end of message processing; may commit error-free data to patient record while continuing to resolve soft errors with sender.
Handling of Non-Cardinality ErrorsHandling of errors other than cardinality failures
Categories: length, cardinality, invalid codes (value can’t be found, format, which code sets, etc.), what constitutes ‘hard’ vs. ‘soft’ errors, encourage folks to bring concerns to add to list of categories, anything that keeps the result from getting to the provider, e.g., provider ID, procedure codes, organization code mismatch with provider codes.
• Length– which fields are ‘in-scope’? NTE-3, OBX-5– NTE-3 is tied to cardinality conversation
• Adopt consistent failure criteria– if the error results in the inability to file the results to the database, it is a
‘hard’ error, the sender must be notified. • Missing data
– only where usage is ‘R’• Cardinality
– See CardinalitySegmentFieldManagement V13.xlsx
Order ErrorsMATCHING – FOR ORDERS (LOI):
– Patient• out of scope for orders in ambulatory setting (systems that have no tight coupling, not owned
by same organization)• in-patient is not within the LOI IG scope as currently published, but may be addressed in
future release• There is no prohibition on a lab sending an error if patient matching fails
– Provider • soft error (inform/resolve but don’t stop processing)• copy-to-provider – soft error (inform but don’t stop processing)
– new order (ORC/OBR)• Placer Order Number – see missing data• OBR-4 – service identifier – hard error• OBX
– OBX-3 – observation ID not match with what expected in OBR-4 – soft error– OBX-5 – inconsistent with what was expected – soft error
– cancel order (ORC/OBR)• Placer Order Number – hard error
Result ErrorsMATCHING – FOR RESULTS (LRI):
– Patient within ordering provider system• No match – hard error back to Lab (how matching occurs or defining confidence levels
are not within scope of the IG)
– Patient within copy-to-provider system• No match – no expectation that a copy-to-provider system would be able to resolve
who the ordering provider is and/or be able to communicate using application-level ACKs
• Out of scope for this version, but may be addressed in the future due to complexity
– Provider• No match – soft error
– Order (ORC/OBR) – Not applicable to copy-to receivers• Placer Order Number – local decision on level of error
– OBR–4 – service identifier – hard error for this pair in the event that it is not on the patient record, can continue with other pairs
» Does not apply when specimen action code is ‘G’ for reflex testing
– Specific data
Cardinality Errors
Source: two action items, one for LOI, one for LRI re: cardinality errors and test limits for senders and receivers, these were addressed in a single track and resulting artifact noting the agreed upon limits. During discussions errors and omissions in the respective guides were identified and are queued for disposition as errata updates to each guide.• LRI-1.6 Testing of stated and implied cardinality limits • 5/22/2014 - closed on LRI call • Log CR for LRI – change PID-5 (Patient Name) to [1..1] to sync with LOI• See CardinalitySegmentFieldManagement V13.xlsx
Questions• Do we have the standards (message and value sets) to report
errors for Laboratory Results?• If not, what needs to be changed
– Message standards• MSA• ERR• other
– Value sets• 0008• 0357• 0516• other
Issues
• Is there a requirement to have a 1:1 relationship between application level ACKs and the messages?
• If yes, then can you mix order control codes within the same ACKs (ORL = LOI question)
• If no, you can send multiple ACKs for a message?• Can you mix order control codes in OML?
To Do
• Verify single error message response for LRI• Verify treatment of hard errors for LRI• Change usage for per slide 4 in ERR segment• Define value set for HL70516 = codes for hard and soft error and
explain what that means – E and F not well defined• Add values and create value set for HL70537(must have application
error code)• Create value set for HL70533• Guidance for ERR-7 and ERR-8• Guidance for use of ERR-3 vs ERR-5 in single ERR segment• Flow diagrams for message processing at each step• Guidance: permissible to stop validation on hard error, best practice?
top related