ACK Message - Real World Scenario
February 1st, 2007 by Mike Stockemer
(10 votes, average: 4.4 out of 5)
Loading ...Posted in HL7 Messaging, HL7 Integration
In my last two posts - acknowledgement (ACK) message definition and Original Mode ACK, it is important to remember that not every system will handle acknowledgments the same way in HL7 messaging. You will interface with systems that send you HL7 messages and do not wait for a response of any kind prior to sending the next message. In this scenario, your system will not be able to send back acknowledgment messages. This type of HL7 messaging delivery is never recommended.
Also, not all systems will review the values that are placed in MSA-1. So even though your application may be setup to send back an AE value in MSA-1, if you fail to receive a message, there is no guarantee that the sending system will review this value. Why is this important?
Consider this scenario:
Your lab application is setup to send back a negative acknowledgment (’AE’ value in MSA-1) if it receives a message that it cannot enqueue. The HIS system at the hospital where your application is installed does not review the MSA-1 value of the ACK message that you send back. At 2:00 pm, there is a hardware problem on the machine where your application is installed, and although you are able to receive messages, you cannot enqueue them. So you send back a negative acknowledgment letting the other side know you have a problem and were unable to enqueue the last message. The HIS ignores the details of this response, and sends you the next message, which will also fail to be enqueued.
An hour later, doctors begin to call the lab looking for results for the orders that they have placed. The lab staff claims they have never received those orders. The HIS administrator is called, and after a quick review of the interface, claims that the orders are being sent and acknowledged by the lab system. This, of course, is because the HIS is only using the first level of qualification.
A quick review of the lab system reveals the problem. Once the lab system has recovered, all of the lost messages need to be reloaded before the interface can be brought back online to receive real time messages again. These messages will need to be resent from the HIS. This may require downtime for the HIS and other systems in the hospital.
These problems can be avoided upfront if the implementation team has a solid understanding of how ACKs will work between the systems. It is important to review the HL7 integration specifications of any application that you will be interfacing with to gain a thorough understanding of how their system sends and receives HL7 acknowledgment messages.
In particular, you need to understand the level of detail an application will go to when qualifying an HL7 response. While this may only be a small piece of an HL7 interface, it is often overlooked in the beginning and is only addressed once the issue has been encountered in production. A little preparation upfront can save you a lot of time, and messages, in the long run.
Last 5 posts by Mike Stockemer
- Comparing HL7 Messages to HL7 Documents - January 25th, 2008
- Monitoring and Alerting for HL7 Interfaces - October 22nd, 2007
- Variations of the HL7 ORU^R01 Message Format - September 10th, 2007
- Point-to-Point Interface vs. Interface Engine in Healthcare - August 23rd, 2007
- Getting Started with Your HL7 Interface - August 16th, 2007
HL7 Acknowledgement Archiving, Necessary?
In HL7 transactions, I understand it to be common practice for the sending party to be able to provide the control id from the HL7 Acknowledgement if a message is missed. Having the sending party produce control ids for sent messages proves successful HL7 acknowledgement from the receiving party, showing that the problem is on the receiving side.
This situation reminds me of examples from everyday life experiences .
Example One: Person comes in wanting cash refund for merchandise. Employee says, “Do you have your receipt?”. A receipt would be ‘proof of purchase’. If the person desiring a refund cannot provide ‘proof of purchase’; then standard procedure is to cut your losses and issue a gift card.
Example Two: Renter at the apartment complex doesn’t pay rent. Manager sends notice to renter to pay rent or move out. Manager takes renter to court seeking eviction. The judge asks whether the renter was given proper notice, that if they did not pay rent they would be forced to move out. The manager can’t say I told the renter pay rent, they have to provide commonly accepted ‘proof of notice’. The Manager presents a certified letter receipt to the judge as ‘proof of notice’.
Just having the sending party ‘resend messages’ seems a lot like giving a gift card to the person without ‘proof of purchase’; you cut your losses and move on without knowing what actually happened.
This sounds like a situation in which someone pays lip service to supporting HL7 but really implements only those portions of the standard that are essential to solving their particular interface problem. They tend to treat HL7 as an interesting variant of a custom interface rather than as a standard.
The notion that one has to “review the other vendor’s HL7 specifications” further suggests that one cannot rely on Hl7 implementations to follow the standard.
Unfortunately, this is all too common. In my experience, I have even seen ostensibly HL7 compliant interfaces proposed (by very large vendors in the field) that lack the MSH unique identifier!
In the proposed scenario, the lab system would actually be better off NAKing or failing to respond at all than to provide an ACK since, presumably, the HIS would stop sending and would store up transactions until the lab system was back up. (Of course, the sysops would be going crazy about the accumulation of stuff in the queue - but that would just provide more incentive to resolve the issue).
From an operational perspective, surely SOMEBODY in the lab would notice a sudden cessation in the influx of orders. One would hope this would prod somebody into looking at things. Would it take an hour to notice this? Depends on the lab, I guess.
This scenario describes what I would conceive of as a communications-level acknowledgement protocol. There is no data validation going on; just verifying that a message was sent, received and submitted for processing.
What if the reason for an AE response is that there are data that are missing or improperly formatted? An application-level ACK as it were. Since most HL7 messages are handled asynchronously to user input, how would you expect those to be handled?
For example, a physician enters an order for a medication that requires a patient weight, but the nurse has not acquired a patient weight. The pharmacy system replies to the order message that it can’t process the order because it needs a weight. The physician is long since gone on to other things… how would that be handled?
Unfortunately, it is more common then one would think to interface with a clinical system, or interface engine, that does no validation of the HL7 ACK messages they receive. From their point of view, if it was written to the socket, it must have been delivered. Even worse is the sending system that does not wait for an HL7 ACK prior to sending the next message, it just sends them as they are ready to go.
We often refer to the HL7 standard as a ‘framework for negotiation’ rather than a firm standard which must be followed. People tend to pick the pieces of the standard that are important to them, and implement them. Sometimes the strict enforcement of HL7 ACK validation doesn’t make it on the list. Reviewing an interface vendor’s specification is crucial, just for that reason. All interfaces are custom, which is why interface engines are typically used in a hospital environment. It is their job to massage the data between systems, so that those systems do not have to be modified to interface with each other. This may be custom and the communication level, where one system supports ACKs correctly, and the other system does not support them at all.
It is amazing what you run into in the field doing HL7 implementations. MSH-10 not present, no trigger value sent in MSH-9-2, HL7 encoding characters in message data without being properly escaped, etc… The list goes on and on. The good news is applications are getting better, interface engines are making interfaces easier to bring up and maintain, and more people are getting trained on HL7. Also, there are new standards being introduced which are designed for specific clinical scenarios, CCR, CCD, and CDA are just a few that are gaining momentum in the industry.
As for the lab scenario above, you would be surprised (or maybe not) to know that many times, without the proper alerting system in place, a lab system may go hours before reporting a problem. You’re right; it would depend on the lab.
As for an application responding with an AE if data is missing from a message: Validation of an HL7 message is usually done within the application itself, not at the communication level. If you are able to read a message from the socket (correct MLP wrapping) and verify it is HL7 (starts with MSH followed by correct sequence of encoding characters, usually |^~\&) then the message will probably be ACKed at this point. Of course you would hope the application at least looks for the required values in the MSH segment to build a proper ACK. A system may generate an AE if they cannot enqueue the message because of a problem on the machine. For instance if the application uses SQL server to store messages, and the server is down, you would want to send back a NACK with an AE value.
You will find that most systems handle the HL7 message validation, ‘application-level ACK’, within their application. If a required value is missing, it would be flagged as such, and this information would need to be gathered and populated in their system. If this happens to often, you can bet they will be getting on the phone with the sending system to get this straightened out.
This could also happen at the interface engine level. The engine may do the validation of the message according to the business rules that are defined for the application that will be receiving the message. If this system does not want messages without this required information, the engine could be setup not to send them on, but instead to error the message. With the error identified, an alert e-mail could be sent to notify the application administrator that a message failed and will need manual intervention to resolve the issue.
Consider the alternative, every time there is a problem with a message, missing data for example, the flow of messages stops until somebody resolves the issue. In a hospital or lab environment where tens of thousands of messages are flowing everyday, would you really want to stop everything because John Doe didn’t provide his weight information?
I would expect the interface to keep running so that messages continue to flow, but that somebody gets alerted immediately to take a look at the message that errored, and resolves that issue, without obstructing the rest of the flow of data into the system.
Thanks for the feedback!
There is also the situation whereupon a message from the sending system will be subscribed to by more than one receiving application.
The question then becomes who returns the ACK/NACK.
This could be the case for the integration engine returning an ACK and storing the messages on it’s queues. This would result in the integration engine handling the application ack and deciding on whether to send the following message or not.
[…] interfacing in the real world, it is important to remember that not every system will handle acknowledgments the same way. You […]