Common practice for handling HL7 ACKs?

Homepage Clovertech Forums Read Only Archives Cloverleaf Cloverleaf Common practice for handling HL7 ACKs?

  • Creator
  • #51140
    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.



Viewing 3 reply threads
  • Author
    • #68916
      Jim Kosloskey


      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.


    • #68917

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

      -- Max Drown (Infor)

    • #68918
      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?

    • #68919
      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

Viewing 3 reply threads
  • The forum ‘Cloverleaf’ is closed to new topics and replies.

Forum Statistics

Registered Users
Topic Tags