1. Recommendations from the EHR-S Functional Requirements IG: Lab Results Interface Error Handling 7/10/2014

2. 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?

3. To Do Verify treatment of hard errors for LRI –Describe best practice permissible to stop validation on hard error? continue and report all error if possible? –stop on hard error and no commit of any ORC/OBR One ACK with “hard error” notification (MSA1=AR) –Partial consumption (e.g. 5 ORC/OBR groups, where only 1 cannot be consumed) Get one ACK with “combined error” notification –if YES, then use MSA-1 = new code, ERR-4 = ? Get 5 ACKs –4 with MSA-1 = AA or AE if soft errors –1 with MSA-1 = AR Guidance for use of 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

4. Message Flow (needs diagram) Message received at destination –Send system ACK to last hop Process message for compliance with IG (includes value sets) –No Error – continue –Soft Error – note and continue –Hard Error – Application ACK MSA-1 = AR Process message for ability to consume and associate –No Error – continue –Soft Error – note and continue –Hard Error – Application ACK MSA-1 = AR Consume/store message content –Success – Continue –Failure -- Application ACK MSA-1 = AR Application ACK –MSA-1 = AA (no soft errors) –MSA-1 = AE (soft errors)

5. Acknowledgement Message Structure TABLE 3‑2. ACK^R01^ACK ABSTRACT MESSAGE SYNTAX SegmentNameUsageCardinality C.LENDescription MSHMessage HeaderR[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 SegmentO[0..*] MSAMessage Acknowledgment R[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 }]ErrorC(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). No changes here. Assumption is 1 ACK/message

6. MSA TABLE 3 ‑ 6. ACKNOWLEDGMENT SEGMENT (MSA) SEQElement NameDTUsageCardinalityValue SetDescription/Comments 1Acknowledgment CodeIDR[1..1]HL70008 2Message Control IDSTR[1..1] 3Text Message X Excluded for this Implementation Guide, see Section 1.3.1 4Expected Sequence Number O 5Delayed Acknowledgment Type X Excluded for this Implementation Guide, see Section 1.3.1 6Error 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. No changes here. Assumption is 1 ACK/message Consider use of MSA-1 to indicate hard error vs soft error

7. Table 0008 Acknowledgement Code ValueDescription AA Original mode: Application Accept - Enhanced mode: Application acknowledgment: Accept = NO ERROR AE Original mode: Application Error - Enhanced mode: Application acknowledgment: Error = ANY OTHER ERROR AR Original mode: Application Reject - Enhanced mode: Application acknowledgment: Reject = ERROR in MSH-9, MSH-11 or MSH-12 or NOT MESSAGE RELATED CA Enhanced mode: Accept acknowledgment: Commit Accept = NO ERROR CE Enhanced mode: Accept acknowledgment: Commit Error = ANY OTHER ERROR CR Enhanced mode: Accept acknowledgment: Commit Reject = ERROR in MSH-9, MSH-11 or MSH-12 or NOT MESSAGE RELATED Immunization Use

8. Table 0008 Acknowledgement Code ValueDescription AA Original mode: Application Accept - Enhanced mode: Application acknowledgment: Accept = NO ERROR AE Original mode: Application Error - Enhanced mode: Application acknowledgment: Error = ANY OTHER ERROR AR Original mode: Application Reject - Enhanced mode: Application acknowledgment: Reject = ERROR in MSH-9, MSH-11 or MSH-12 or NOT MESSAGE RELATED CA Enhanced mode: Accept acknowledgment: Commit Accept = NO ERROR CE Enhanced mode: Accept acknowledgment: Commit Error = ANY OTHER ERROR CR Enhanced mode: Accept acknowledgment: Commit Reject = ERROR in MSH-9, MSH-11 or MSH-12 or NOT MESSAGE RELATED MACombined mode: Message Accept: No Errors MSCombined mode: Message Soft Errors: Soft Errors MPCombined mode: Message Partial Hard Errors: No/Soft/Hard (partial consumption) MRCombined mode: Message Reject: Hard errors (nothing consumed) Option 1: Creating IG specific codes to indicate hard vs soft error

9. Table 0008 Acknowledgement Code ValueDescription AA Original mode: Application Accept - Enhanced mode: Application acknowledgment: Accept = NO ERROR AE Original mode: Application Error - Enhanced mode: Application acknowledgment: Error = SOFT ERROR(s) AR Original mode: Application Reject - Enhanced mode: Application acknowledgment: Reject = HARD ERROR(s) CA Enhanced mode: Accept acknowledgment: Commit Accept = Not used CE Enhanced mode: Accept acknowledgment: Commit Error = Not used CR Enhanced mode: Accept acknowledgment: Commit Reject = Not used Option 2: Use existing codes to indicate hard vs soft error

10. ERR TABLE 3 ‑ 7. ERROR SEGMENT (ERR) SEQElement NameDTUsageCardinalityValue SetDescription/Comments 1Error Code and Location X Excluded for this Implementation Guide, see Section 1.3.1 2Error LocationERLO RE[0..1] Use to identify segment/field where error occurred 3HL7 Error CodeCWER[1..1]HL70357Used to identify issues based on conformance profile in message (structure and vocabulary) – may use the immunization codes here OR to indicate application error Expand table values – must include a code for application error 4SeverityIDR[1..1]HL70516This is where you look, if the identified error is a HARD ERROR or a SOFT ERROR, if we have only 1 ACK message/message Create specific codes for HARD ERROR and SOFT ERROR (and warning?) 5Application Error CodeCWEO C(RE/O) [0..1]HL70533 (2.7.1) Used to indicate error in content – nothing wrong with the message, but system cannot use the data 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 6Application Error Parameter O 7Diagnostic InformationTXRE[0..1] IS OPTIONAL IN IMMUNIZATION HL7 Definition: Information that may be used by help desk or other support personnel to diagnose a problem Length: 2048 8User MessageTXRE[0..1] IS RE IN IMMUNIZATION HL7 Definition: The text message to be displayed to the application user. Length: 250 9Inform Person Indicator O 10Override Type O 11Override Reason Code O 12Help Desk Contact Point O The ERR segment is used to add error comments to acknowledgment messages – ONE FOR EACH ERROR.

11. Define ERL datatype SEQElement NameDTUsageValue SetDescription/Comments (from HL7 base for discussion only) 1Segment ID STR 2Segment SequenceNMR Is this absolute position in message? Or for the specific segment the x occurrence? 3Field PositionNM RE Not used, when entire segment is referred to 4Field RepetitionNM RE If not specified repetition is assumed 1 5Component NumberNM RE Not used, when entire field is referred to 6Sub-Component NumberNM RE Not used, when entire component is referred to

12. Table 0357 in ERR-3 Message error condition codes (HL7 defined) ValueDescription 0Message accepted 100Segment sequence error 101Required field missing 102Data type error 103Table value not found 5**Table value not found = The value is not found in the associated table. 200Unsupported message type 201Unsupported event code 202Unsupported processing id 203Unsupported version id 204Unknown key identifier 205Duplicate key identifier 206Application record locked 207Application internal error TBDApplication Error – see ERR-6 TBDCardinality Error 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. 6**Required observation missing = A required observation, such as VFC eligibility status, is missing. **From Immunization in HL70357

13. ValueDescriptionDefinition from base E Error Transaction was unsuccessful (or use this for hard error) F Fatal Error (v2.7.1) Message not processed due to application or network failure condition I Information Transaction was successful, but includes information e.g., inform patient W Warning Transaction successful, but there may be issues (or use this for SOFT ERROR) Table 0516 in ERR-4 Error Severity (HL7 defined) These definitions are not very helpful Suggestion: Create 2 new codes that indicate HARD ERROR and SOFT ERROR respectively Hard error- Application cannot meaningfully consume the message content – content NOT processed Soft error – application cannot meaningfully consume part of the message content as indicated in ERL, but consumed remainder of message sections

14. Table 533 suggested codes (empty user defined table in base HL7) ValueDescription Can’t match Patient Can’t match Provider Can’t match to local code Can’t match order number 1**Illogical Date error = Date conflicts with another date in the message. This is logic check – could also be done in application not just message, keep here? 2**Invalid Date = Date is not valid or lacks required precision. Message level – NOT HERE 3**Illogical Value error = The value conflicts with other data in the message. This is logic check – could also be done in application not just message, keep here? 4**Invalid value = The value is not valid. This applies for fields that are not associated with a table of values. Need more information to decide what this would mean in LRI 5**Table value not found = The value is not found in the associated table. Message level – NOT HERE 6**Required observation missing = A required observation, such as VFC eligibility status, is missing. This is a logic/business rule check – could also be done in application not just message, keep here? **From Immunization in HL70357

15. Table 533 suggested codes (empty user defined table in base HL7) ValueDescription Can’t match Patient Can’t match Provider Can’t match to local code Can’t match order number 4**Invalid value = The value is not valid. This applies for fields that are not associated with a table of values. Only for user defined values or mapping tables 6**Required observation missing = A required observation, such as VFC eligibility status, is missing. This is a logic/business rule check – could also be done in application not just message, keep here? **From Immunization in HL70357

16. Example Hard Error 1 ACK message – application level MSA-1 = AR ERR-2 = MSH^1^12 ERR-3 = code for Message Header Error ERR-4 = E (or code for hard error) ERR-5 = empty ERR-7 = Incompatible version of HL7 message ERR-8 = Cannot process results; call or FAX results See Chapter 2, section 2.9.3 for clarification

17. Example Hard Error 1 ACK message – application level MSA-1 = AR ERR-2 = PID^1^3 ERR-3 = code for Application Error (or would we use 0 = message processed?) ERR-4 = E (or code for hard error) ERR-5 = code for cannot match patient ID ERR-7 = Cannot match patient ID, message content not processed ERR-8 = Cannot match patient ID; message content not processed; call or Fax results

18. Example soft error 1 ACK message – application level MSA-1 = ACE ERR-2 = OBX^1^3 ERR-3 = code for Application Error (or would we use 0 = message processed?) ERR-4 = W (or code for soft error) ERR-5 = code for cannot match to local code ERR-7 = empty ERR-8 = Resulted test code does not match what is expected based on ordered test; results stored; call to resolve for future results

19. Error Handling Overview ERROR 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.

20. Handling of Non-Cardinality Errors Handling 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

21. Order Errors MATCHING – 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

22. Result Errors MATCHING – 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

23. 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.xlsxCardinalitySegmentFieldManagement V13.xlsx