View source for InM V2 Err Discussion

{{INM Workitem}}
=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? 
*#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?
*#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==
===Receiver processing===
*2.9.2	Message response using the original processing rules
**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:
***Note:	Both MSH-15 - accept acknowledgment type and MSH-16 - application acknowledgment type are null or not present.
***a)	the value in MSH-9 Message Type is one that is acceptable to the receiver.
***b)	the value in MSH-12 Version ID is acceptable to the receiver.
***c)	the value in MSH-11 Processing ID is appropriate for the application process handling the message.
***If any of these edits fail, the protocol software rejects the message. That is, it creates an ACK message with AR in MSA-1 Acknowledgment Code.
**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. 
*2.9.3	Response using enhanced acknowledgement
**2.9.3.1	Accept and validate the message in responding system
***Upon receipt of the message, when the Enhanced Acknowledgement rules are used, the protocol software in the responding system makes an initial determination as to whether or not the message can be accepted, based on factors such as:
***Note:  At least one of MSH-15-accept acknowledgment type or MSH-16-application acknowledgment type is not null.
***a)	the status of the interface
***b)	the availability of safe storage onto which the message can be saved
***c)	the syntactical correctness of the message, if the design of the receiving system includes this type of validation at this phase
***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
***It then examines the Message Header segment (MSH) to determine whether or not the initiating system requires an accept acknowledgment.
**2.9.3.2	Transmit general acknowledgement message
***A general acknowledgement message is not always required by the initiating system, but if it is the responding system sends one of the following:
***a) a commit accept (CA) in MSA-1 Acknowledgment Code if the message can be accepted for processing
***b) a commit reject (CR) in MSA-1 Acknowledgment Code if the one of the values of MSH-9 Message Type, MSH-12 Version ID or MSH-11 Processing ID is not acceptable to the receiving application
***c) a commit error (CE) in  MSA-1 Acknowledgment Code if the message cannot be accepted for any other reason (e.g., sequence number error)
**2.9.3.3	Transmit application acknowledgement                               
***If the message header segment indicates that the initiating system also requires an application acknowledgment, this will be returned as the initial message of a later exchange.
***For this message, the receiving system acts as the initiator. Since the message it sends is application specific, the layouts of these application-level response messages are defined in the relevant application-specific chapter. If needed, this application acknowledgment message can itself require (in MSH-15 Accept Acknowledgment Type) an accept acknowledgment message (MSA). MSH-16 Application Acknowledgment Type, however, is always null, since the protocol does not allow the application acknowledgment message to have an application acknowledgment.
***For this response, the following values are put in the MSA segment. Note that the field definitions for the MSA segment fields are in Section 2.14.8, "MSA   message acknowledgment segment".
==ERR segment==
*2.14.5 ERR - Error segment
**Severity: A receiving application needs to communicate 2 "error or exception statements." One is an "error;" the other is a "warning". To accomplish this, an acknowledgement message with 2 ERR segments is sent. Upon receipt, the sending application can display both, including the appropriate severity, to the user. 
**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).
*'''Note''' this is a user defined table.

==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:] Section C.2.3 
**Note particularly lines 800 - 810 
*S&I IG [http://www.hl7.org/documentcenter/public_temp_264367C4-1C23-BA17-0CF4CF8F574FF933/standards/dstu/V251_IG_SIF_LABRESULTS_R1_DSTUR2_2015SEP.pdf 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:
***#'Hard Error' – stop; suspend processing and notify sender, do not commit data to patient record
***#'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==
*IMHO the standard is straightforward on the use of ERR-3
===ERR-3 - original processing rules===
*IMHO 2.9.2.1 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".
*IMHO I infer from this that error codes 0, 200-203 are returned at this point.
===ERR-3 - Enhanced processing rules===
*Enhanced mode acknowledgement allows verification beyond that of original:
*IMHO 2.9.3.1 '''Mandates''' verification of:
**a) Status of the interface
***Code 207 Rejection: A catchall for internal errors not explicitly covered by other codes
**b) the availability of safe storage onto which the message can be saved
***Code 206 or 207 
**c) the syntactical correctness of the message, if the design of the receiving system includes this type of validation at this phase. 
***Codes (100 - 104)
**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.
***Codes 200-203

===ERR-5 ===
*2.14.5.3 requires ERR-3 if there is an error from HL7 0357.
*00357 does not require a 999 - If the application wishes to report an error that is not defined in HL7 0357 then 207 "Rejection: A catchall for internal errors not explicitly covered by other codes" should be in ERR-3.
*Then the application populates 
**ERR-4 with the severity from HL7 0516 
**ERR-5 with the code from User defined table 533
**ERR-6 with the error parameter(s)
**And the other fields as required.