InM V2 Err Discussion

ERR Guidance Discussion

Problem Statement

• In collaboration with the PHER work group, the CDC and the American Immunization Registry Association (AIRA) are working on a version 2 implementation guide for messaging immunization data. As part of this work, we are trying to compile a list of error codes for use in an ERR segment. We hope that by standardizing the error codes, we can make it easier for an EHR (or any system submitting data to an Immunization Information System) to understand when data they sent in caused an issue and how to rectify the issue (if necessary and possible).
• Some of our general questions are:
• What advice/guidance/best practices are there for how to populated these two fields? Is there a particular type of error that should be reported in ERR-3? Does the “communications” reference meaning anything? Is ERR-3 restricted to things like MSH segment errors, violations of basic HL7 rules (wrong data type, unexpected segments/fields) or conformance issues when a message claims conformance to a particular profile?
  1. It also seems like some of the value listed in Table 0357 (103, 204, 205, 206 in particular) may make more sense as an application error in ERR-5 as they may require a level of processing of the message beyond just a validation of the construction of the message. Can you explain the intent of these codes being part of table 0357?
  2. Do you know of any plans to extend either table with new values? I recall that some of the lab folks were looking into at least one new code in 0357 (add a code of 999 if I recall correctly).
• We know this is a pretty big topic and one that would benefit from some face to face discussion. If possible, we’d like to start this discussion via email but also put this on the InM agenda for San Antonio and get a quarter to discuss this further. Please let us know if you think that is possible.

Standard

1. From V2.8.2 Chapter 2
   • 2.9.2 Message response using the original processing rules(if both MSH-15 and MSH-16 are empty or not present)
   • Step 1 - communications validation - ERR-3 (MSA-1 = AR)
     • 200 the value in MSH-9.1 Message Type(Message code) is NOT one that is acceptable to the receiver.
     • 201 the value in MSH-9.2 Message Type (Trigger Event) is NOT one that is acceptable to the receiver.
     • 202 the value in MSH-11 Processing ID is NOT appropriate for the application process handling the message.
     • 203 the value in MSH-12 Version ID is NOT acceptable to the receiver.
   • 22.9.2.2 - Application evaluates message and returns errors in Application Error Code.
     1. The application may return any of the errors in table 0357.
   • 2.9.3 Response using enhanced acknowledgement(Where either/or MSH-15, MSH-16 NOT empty)
     • In this case any error from 0 - 203 are supported -
   • 2.9.3.1.a)Status of the interface
   • 2.9.3.1.b) the availability of safe storage onto which the message can be saved
   • 2.9.3.1.c) the syntactical correctness of the message, if the design of the receiving system includes this type of validation at this phase. (100 - 104)
   • 2.9.3.1.d) the values of MSH-9 Message Type, MSH-12 Version ID, and MSH-11 Processing ID, if the design of the receiving system includes this type of validation at this phase(200-203) returns CA if 200-203, all others returns CE.
   • All of the above are ERR-3 errors - where ERR-5 is populated from User Defined Table 0533.
2. From V2.8.2 Chapter 2
   • 2.14.5 .Application Error Code: A receiving application generates an error that reports an application error code and returns this information in its response. This code in turn is used by helpdesk staff to pinpoint the exact cause of the error, or by the application to prompt an appropriate response from the user. (Ex. Deceased date must be greater than or equal to birth date).

References

• NANI IG references [ http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Rev8-0_Vol2x_FT_2011-08-19.pdf IHE ITI TF-2x: C.2.3]
• S&I IG HL7 Version 2.5.1 Implementation Guide: S&I Framework Lab Results Interface, Release 1- US Realm 2.6.2 ERROR HANDLING
  • After receiving an LRI message the EHR responds with an Accept Acknowledgment Message to the immediately preceding sender, returning a Communication Accept code in MSA-1 of “CA” or a Communication Reject code “CR”. If the message is rejected (MSA-1 = “CR”) the EHR-S has completed the message acknowledgement workflow for the message.
  • If the message is accepted (MSA-1 = “CA”), the EHR-S evaluates the ORU message for both conformance to the LRI guide and whether it is able to consume and associate the message contents, and finally the EHR-S consumes and stores the message contents. If all of these steps succeed without an error, the EHR-S responds with an Application Acknowledgment Message to the originating system returning an Application Accept code in MSA-1 of “AA”. If there are hard errors, the processing of the message is aborted at any of these steps and the EHR-S responds with an Application Acknowledgment Message to the originating system returning an Application Reject code in MSA-1 of “AR” with the error(s) listed in fields ERR-3 and/or ERR-5. If there are soft errors the EHR-S responds, after consuming and storing the message, with an Application Acknowledgment Message to the originating system returning an Application Error code in MSA-1 of “AE” with the error(s) listed in fields ERR-3 and/or ERR-5. This is illustrated in Figure 2-4.
  • There are two error severity categories:
    1. 'Hard Error' – stop; suspend processing and notify sender, do not commit data to patient record
    2. 'Soft Error' – notify (as directed) but continue to process message unless a hard error is encountered prior to end of message processing; may commit data to patient record while informing sender of soft errors.
  • Errors can be reported at two levels:
    • HL7 error code (ERR-3) - These are errors in the structure or the message content that can be identified during validation against the guide profile.
    • Application error code (ERR-5) – These are errors related to the message content that are not computable from the guide profile, but related to the receiving application’s functionality, or are not related to the message or its content, but report on other application failures.
• 4.9 details ERL - Error Location (ERR-2).
• 5.3.3 ERR ERROR SEGMENT
  • ERR-2 To reduce ambiguity, each error will have an individual ERR segment
  • ERR-3 Used to identify issues based on conformance profile in message (structure and vocabulary) or to indicate an application error was identified and is communicated in ERR-5 (Application Error Code).
• Includes its own value-sets(by reference) and the binding.

Tony Julian Interpretation

ERR-3

• IMHO the standard is straightforward on the use of ERR-3
  • 2.9.2.1 Accept and validate the message in responding system
    • Upon receipt of the message, when the Original Acknowledgement rules are used, the protocol software in the responding system validates it against at least the following criteria:
      • This sentence mandates (while not using modal verbs, the mood of the sentence is imperative) validation of MSH-9,MSH-11,MSH-12 with failure resulting in an "AR - Application Reject".
      • One may infer from this that error codes 0, 200-203 are returned at this poing.
• It goes on to state:
  • 2.9.2.2 Accept and validate/process the message in the receiving application
    • Upon successful validation by the responding system, the message is passed to the receiving application, which performs one of these functions:
    • a) process the message successfully, generating the functional response message with a value of AA in MSA-1 Acknowledgment Code.
    • b) send an error response, providing error information in functional segments to be included in the response message with a value of AE in MSA-1 Acknowledgment Code.
    • c) fail to process (reject) the message for reasons unrelated to its content or format (system down, internal error, etc.). For most such problems it is likely that the responding system will be able to accept the same message at a later time. The implementers must decide on an application-specific basis whether the message should be automatically sent again. The response message contains a value of AR in MSA-1 Acknowledgment Code.
  • Enhanced mode acknowledgement allows verification beyond
• From V2.8.2 Chapter 2
  • 2.9.2 Message response using the original processing rules(if both MSH-15 and MSH-16 are empty or not present)
  • Step 1 - communications validation - ERR-3 (MSA-1 = AR)
    • 200 the value in MSH-9.1 Message Type(Message code) is NOT one that is acceptable to the receiver.
    • 201 the value in MSH-9.2 Message Type (Trigger Event) is NOT one that is acceptable to the receiver.
    • 202 the value in MSH-11 Processing ID is NOT appropriate for the application process handling the message.
    • 203 the value in MSH-12 Version ID is NOT acceptable to the receiver.
  • 2.9.3 Response using enhanced acknowledgement(Where either/or MSH-15, MSH-16 NOT empty)
    • In this case any error from 0 - 203 are supported -
  • 2.9.3.1.a)Status of the interface
  • 2.9.3.1.b)the availability of safe storage onto which the message can be saved
  • 2.9.3.1.c)the syntactical correctness of the message, if the design of the receiving system includes this type of validation at this phase. (100 - 104)
  • 2.9.3.1.d) the values of MSH-9 Message Type, MSH-12 Version ID, and MSH-11 Processing ID, if the design of the receiving system includes this type of validation at this phase(200-203) returns CA if 200-203, all others returns CE.