Acknowledgement TypeCode Changes
This page documents an INM Workitem, i.e. an issue within scope of the INM Committee that either is still being discussed, or the resolution of which has not yet been included in an INM ballot.
This is a page of type Category:InM Closed Action Items.
Acknowledgment TypeCode Changes
Opened 20080629 Lloyd McKenzie assigned: 20100120 Patrick Loyd
Description The current values and approach to the use of Acknowledgement.typeCode were inherited from HL7 v2. However, their use doesn't take into account the prevalence of the use of receiver responsibilities, and more importantly, doesn't allow distinguishing situations where a request was unable to be processed due to non-compliance of the inbound request vs. a decision by the receiver to not act on a request due to some internal business driver. It also causes issues where there's a business response that isn't clearly an error. For example:
- A refusal due to contraindications that might be overridable
- A refusal accompanied by a counter-proposal
- A decision to defer processing of the request
- A decision to act on part of the request
- A decision to act on a varient of the request
This action item is a proposal to limit the use of the AE acknowledgement code to circumstances where there is an error in such that the content of the acknowledged message does not conform with the identified version of the specification and any declared profiles or templates. All other issues, resulting from business validation against id sources, decision support logic would not be treated as "errors". Instead, the AA acknowledgment code would be used in these circumstances and the specific decision of the receiver (to refuse, to counter-propose, etc.) would be conveyed by the ide of the receiver responsibility interaction invoked and the corresponding controlAct.code, as well as the ControlAct.reasonCode.
Proposal Specifics
Define three terms:
Transport Error: A circumstance where an instance is unable to be delivered to the intended recipient or where the intended recipient does not support the specified request and is therefore unable to process and respond to it
Validation Error: A circumstance where an instance does not comply with the specifications associated with the declared interaction id, version code, profile ids and/or template ids. This includes: Failure to agree with minimum and maximum cardinalities, mandatory, fixed values, vocabulary value-sets, etc.
Business Issue: A circumstance where an instance representing a request is not fully acted on based on a business rule beyond the specification. This includes validation of identifiers against repositories, decision support rules, permission checking and other internal business rules related to evaluating the acceptability of a request.
Add the following text:
"Transport Errors may be dealt with purely within the transport protocol without involvement of the message transport wrapper. Where the transport protocol does not support independent conveying of transport errors (e.g. release 1 of the MLLP protocol), the error may be conveyed in the transmission wrapper with an acknowledgement typeCode of AE.
- Why not introduce an error code "T" for 'transmission' ? Rene spronk 07:51, 15 July 2008 (UTC)
Validation Errors, when detected, may be raised in the transport wrapper either at the commit or application acknowledgement level. These errors are conveyed with an acknowledgement typeCode of AE.
Business issues are always handled at the ControlAct level. In the absense of transport or validation errors, these responses will have an acknowledgement typeCode of AA.
Impacts
Applications would now have a clear test whether there was an error with the data in the outgoing instance (which would theoretically be correctable) vs. a business-level concern that might be temporary in nature.
There would no longer be a need to flag issues as "errors" when they weren't necessariliy errors
This is NOT a (backwards) compatible change. Rene spronk 07:51, 15 July 2008 (UTC)
Existing applications might need to revise how they populate the Acknowledgement.typeCode based on these new guidelines.
This also has an impact on the use of the C* error codes. We may simply want to drop them, aser they only lead to confusion. Only AA, AE and AR will be used - or better yet: just A, E and R or 'accept' 'error' and 'reject'. Rene spronk 07:51, 15 July 2008 (UTC) 20100120- Phoenix - Wrappers R2 issue send to Patrick Loyd
