What is the standard behavior with AE/CE in ACK

[David Loveluck]

I'm working with an application to which Ensemble sends a QBP_Q23
looking for a particular MRN and the app sends back information about
the MRN. If it doesn't find the MRN it sends back an AE in the MSA
segment.

Ensemble keeps retrying this and of course it never works. The
application developer says that sending an AE is a valid thing to do
to report a problem witrh a message and they wouldn't expect a retry.

So my question - what does the HL7 standard say should happen when
Ensemble receives an AE? Is the app using a valid option or is it
abusing the standard?

If they are doing it wrong I will prevail upon them to change. If they
have a valid point I'll have to work out how to deal with it.

thanks for your input

dave

[Ted Peck]

Do you mean me or Simon?

Do you mean to add this in EnsLib.HL7.Service.Standard.constructReply() or
in EnsLib.HL7.MsgRouter.RoutingEngine.constructReply(), or both, or
somewhere else?

As I told Simon, there is space for an "ErrorCondition" field at MSA:6 so
the ERR segment could be considered redundant.

Ted

[Ted Peck]

Dave -

Sorry, I was replying to a different email. Here is the answer to your question -

 

Excerpt from the HL7 doc below. It appears your customer is right and we have it backwards in our defaults. To put it simply, AE means don't retry and AR means retry.

 

This can be controlled using the  ReplyCodeActions setting on the Business Operation. The default behavior is:

 ?E=RF,?R=S,~=S,I?=W,T?=C

but the more correct behavior would be

 ?R=RF,?E=S,~=S,I?=W,T?=C

 

That means suspend the message if it's an AE, retry and then fail if it's an AR.

 

Ted

 

From the 2.5 HL7 specs, Chapter 2:

 

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.

The MSH segment in the response is constructed anew following the rules used to create the initial message
described above. In particular, MSH-7-date/time of message and MSH-10-message control ID refer to the
response message; they are not echoes of the fields in the initial message. MSH-5-receiving application,
MSH-6-receiving facility, and MSH-11-processing ID contain codes that are copied from MSH-3-sending
application, MSH-4-sending facility and MSH-11-processing ID in the initiating message.