HL7 – More than one ACK

[David Harrison]

Cloverleaf 5.6 on Solaris 10

I have a situation where I am sending messages to our Radiology system and awaiting replies for 5 seconds and resending if no ack is received. I am using hcitpsmsgkill to kill the replies. Problem is that the receiving system is acking the message and then sending an ACK with an error if it has a processing problem.

Topic

[Keith McLeod]

One ACK per message has been my experience….

[Jim Kosloskey]

It is possible to receive multiple acknowledgment messages. The first is to indicate receipt of the message, the subsequent acks are to indicate if the message was actually applied or if not what the issue was.

This design goes back to the old point-to-point days and has little value today unless the integration is a query/response integration.

The question is just what would anyone expect an Integration Engine to do with the error? What should happen is the receiving system should only send the ‘receipt of message’ acknowledgment. Any errors detected should be reported in the Receiving system (an error or exception log perhaps) and those exceptions should be worked on the Receiving system side.

If on the other hand an error occurs in receiving the message, then that should be expressed with the first acknowledgment. Then assuming the acknowledgment makes use of the ERR components that can contain a code, the engine could do a ‘triage’ and determine if the connection needs to be stopped because an intrinsic flaw has occurred wherein no message will ever process.

It look like this receiving system is making use of the ERR segment properly but it also looks like this is a Reciving system issue and not a message issue.

email: jim.kosloskey@jim-kosloskey.com

[David Harrison]

Thank you gentlemen; this confirms my thinking. I will ask the vendor to just send a single response to my message although I am not hopeful that they will be able to address it. If they can’t then I will have to use modified recover_56 procs to check the message id of the ACK against that sent with the message.

Regards,

Dave

[Jim Kosloskey]

I think the challenge is greater than that.

I believe the subsequent acknowledgment messages will be treated as ‘DATA’ Type message by Cloverleaf(R) and thus will not go through the reply handling. Moreover if the outbound thread is configured as ‘Outbound Only’, the DATA type messages are ignored _ you never see them.

I think you will need to have a proc in the Inbound Tps to do the checking for acknowledgments after the first acknowledgment.

If the acknowledgments come back-to-back you might be able to get away with knowing that with an ‘Outbound Only’ thread, any messages received after the first acknowledgment but before the next issuance of an outbound message will be thrown away automatically by Cloverleaf(R).

In addition, it appears the Control IDs in the Acknowledgments are incorrect (unless it is just a coincidence).

The MSH of the acknowledgment should have a Control ID of the Receiving system, the MSA segment then should have the Control Id of the message sent by Cloverleaf(R). It appears that botht he MSH and MSA Control IDs are the same in the acknowledgment – this should not happen.

It is the MSA Control ID you will use to check against the Control ID of the message you are sending.

email: jim.kosloskey@jim-kosloskey.com

[David Harrison]

Jim,

That explains why the error ACKs are going into the error database with a trxId error – Cloverleaf is treating these replies as data. I’m guessing that these messages will not affect the normal message flow control.

So if I configure the inbound side of the outbound thread to ‘Outbound Only’,

should it fix my problem? Or should I configure a route for the inbound data messages and send them to a dummy thread?

Thanks,

Dave

[Jim Kosloskey]

If you set the outbound thread as ‘Outbound Only’ that can appear to solve your problem as long as the multiple acknowledgments arrive within the timeout and before the next message is sent.

What can happen is this:

   Message goes out – waiting for reply…

   First ack comes in satisfies waiting for reply

   Next message goes out (maybe there is a queue from a shutdown, maybe there is just a very high arrival rate) – waiting for a reply…

   Second ack for first message arrives is treated as 1st ack for second message

    First ack for second message arrives – is treated as DATA and discarded because ‘wait for reply’ has been satisfied.

  and so on …

That scenario may not be what you want because you do not have any idea if you are reacting to the correct acknowledgment and might miss an acknowledgment that means there is a transimission ‘receipt of message’ problem.

You could use a Tcl proc in the Inbound Tps of the Outbound thread and handle the message there (including KILLing it if that makes sense). If the subsequent acks have valuable intelligence, perhaps you could email or page an Alert to the responsible parties and move on.

Or you could put a route back to the outbound thread (that way no need to build an additional dumm thread) and use hcitpsmsgkill to unilaterally KILL all inbound messages meeting that routing characteristic (which could be static routing).

Lot’s of options – you will need to decide what will work best for your situation.

email: jim.kosloskey@jim-kosloskey.com

[David Harrison]

Food for thought indeed!

This is a live PAS-Radiology interface used for order communications so I can’t leave anything to chance.

On occasions we have had more than two ACKS and, from my observations, these seem to come one after the other. So the scenario you outlined could result in a subsequent outbound message being ACK’d when it hasn’t been seen by the receiving system.

I have contacted the vendor.

Many thanks,

Dave

[Charlie Bursell]

Firts, I think Await Replies of 5 seconds is much too short.  I usually set mine for 45 seconds.  It does not affect the throughput as the engine will send as fast as the reply is received.  I set it long because sending duplicates is as bad as losing messages.

The only thing the timeout accomplishes is if a system goes away for some reason, we will come knocking on hs door 45 seconds later.  Aslo remember the engine does not attempt to send unless the connection is UP.

To preclude receiving multiple responses set OB Only on the inbound tab.  If the Await Reply flag is not set the message will be discarded.  The Await Relply flag will be cleared as soon as the IB Reply proc issues a KILLREPLY

[Gary Atkinson]

I had this situation before.  I was receiving second ack from the system.  The first ack was that the message was received and the second ack was that the database received the message.  I add hcimsgkill proc in the inbound tps to delete this extra ack.

[Bob Richardson]

Gentlemen,

If you are on CIS5.6 Integrator, it might be advantageous to document why an hcitpsmsgkill or other non-standard configuration exists for a thread in the NOTES for the thread or the process.   I have implemented some interfaces with non-standard logic and then scratch my head six months later wondering why this configuration was set up in the first place.

That NOTES feature to me is a yet untapped resource for the Integrator product.

Just my thoughts.

Have a great day!

[Gary Atkinson]

I am on 5.5, but yet another reason to upgrade.   😛

[Robert Milfajt]

C’mon, take a tip from Klingon programmers, documentation is for the weak and timid!   😈

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Gary Atkinson]

<a href="http://www.psych.usyd.edu.au/pdp-11/rp.html&#8221; class=”bbcode_url”>http://www.psych.usyd.edu.au/pdp-11/rp.html

😆

[Author]

Replies