Common practice for handling HL7 ACKs?

[Kyley Jex]

As a new user of Cloverleaf, I’m trying to understand what the common or suggested practice is for when the HL7 ACK is sent.

Currently, I’ve configured our site to immediately return the ACK from the IB thread.  However, when routing the message to another application, and the application ACKs with an Application Error, how is that normally handled?  My first thought is that the original sending application should be notified of the application error (ie. required field is missing, message is incomplete) — and that I should return the ACK from the application.  But that can get messy as more than one application is added to process the message.

I’ve read a few similar posts that suggest that the Application Error should trigger an alert that notifies the sending application via another method, rather than waiting for the ACK.

Is that the commonly suggested/practiced method?  Any suggestions or pitfalls to be aware of.

Cheers,

Kyley

Topic

[Jim Kosloskey]

Kyley,

You are correct in your thinking that passing acknowledgments from the receiving system(s) back to the sending system just does not make sense in a multi-point integration environment.

Typically one would hope that modern receiving systems have isolated their message handling layer from their application business rules such that the checking of the message is done after the message is received and acknowledged. So we would expect the receiving system to simply assure they have a properly structured message and acknowledge simply that a properly structured message was received or the message was not properly structured.

Given the above, once we get are finished thoroughly testing our integration, we should expect to only see positive acknowledgments. However, we still should provide handling for Negative acknowledgments.

What you do when you receive a negative acknowledgment is up to you and you can do almost anything you want.

Here, since a negative acknowledgment is not supposed to happen and must mean that a mal-formed message was sent, we send out page and email alerts to appropriate entities and stop the connection (if we have a mal-formed message most likely the next message will fail as well).

If you have a receiving system that is also going to check to see if there is a data content or receiving application issue and send a negative acknowledgment based on those conditions, then hopefully they will properly use the acknowledgment to fully identify the reason for the negative acknowledgment. In the case of HL/7 that would be the MSA segment.

I cannot recall any vendor that does application acknowledgments that properly uses the MSA segment for HL/7 – including 3M.

In any case, if you receive a properly populated application negative acknowledgement reflecting a receiving system application error just what would you be expected to do with it?

The most you can do is to alert the appropriate entities that you did receive the negative acknowledgment and what it contained. The correction would need to be done by someone else.

By the way this is not unique to HL/7 – any message type that has acknowledgments can participate in the same discussion.

There is more, but to sum up:

Try to make sure the receiving systems only check for proper structure not data content or applicability for acknowledgment purposes.

Then when you receive a negative acknowledgment you can alert the appropriate folks (probably the Integration Archtects/Engineers) and work on why you built an improperly structured message.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Max Drown (Infor)]

For 99.9% of our interfaces, we simply kill the ACKS with the hcitpsmsgkill proc.

-- Max Drown (Infor)

[Kyley Jex]

Thank you for your responses.

Jim, with what you prescribed, is it appropriate to delay the ACK until after the xlate–to ensure that all the proper fields are populated?  Or would that be checking for data content?  If so, is the generating of the ACK always done from the xlate(proc call) rather than from the TPS Inbound Data?

[Charlie Bursell]

The IB ACK proc is always  (at least 99.9% of the time) the first proc in the IB thread.  You want to do a minimum amount of testing here so as not to hold up the sender.  Structural and field errors will be discovered later in Cloverleaf.

The proc we provide and support is named hl7Raw_ack and is included with 5.7.

Do no lose sight of the primary purpose of ACKs.  It is for flow control so the sender cannot send faster than the receiver can receive.  The warm, fuzzy feeling you get from knowing the receiver received the message is nice but flow control is primary.

When receiving ACK messages on an OB thread , and the vendor is sending NAKs, it is a good idea to check for them and take an appropriate action.  Again we supply procs for that, either recover_22 or recover_56.

As Max said, if your vendor never sends a NAK, hcitpsmsgkill is sufficient.

FWIW, common ACK/NAK will be built in to 5.8 released in December this year

[Author]

Replies