This wiki has undergone a migration to Confluence found Here

Acknowledgement TypeCode Changes

From HL7Wiki
Jump to navigation Jump to search

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.


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