Andrew McIntyre wrote: > On the question of the correct use of ACKS: This is from chapter 2 > > "The HL7 Standard makes no functional interpretation of the requirement > that a system commit the data in a > message to its database before acknowledging it. All that is required is > that the receiving system accept responsibility > for the data, providing the same integrity test that it would apply to > data from any source. To > continue the prior example, the ancillary system may acknowledge the > order after placing it in an input > queue, expecting to fully process the order into its database at a > future time. The only assumption is that > the input queue is maintained at the same level of integrity as the > database."
When we first sat down and actually read the HL7 2.x specification, in 2003, we were a bit staggered to find the above paragraph. In other words, the official HL7 specs do not require application level ACKs, or rather, they don't really specify exactly what is meant by an ACK or which part of the receiving system should send it. Nor do the HL7 2.x specs have much to say about the semantics of NACKs either - that is, what does a sending application do if it receives a NACK. Now, a NACK may mean that the HL7 content was badly formatted. So what is the sending app supposed to do? Just resending the same message is no help. If the sending app does resend in response to a NACK, then an endless loop of send/NACk results, unless the sending app has a message cycle detection feature, which then brings such messages to the attention of a human at the sending end. Do any clinical apps have this currently? Hands up if you do. But the NACK may be because the receiving app has, say, run out of disc space and can't save the incoming HL7 message. In that case, the correct thing to do is for the sending app to keep resending. There are several variations on this theme, but the HL7 specs are silent on how apps should behave in these various circumstances. Without a standard for how apps should behave, it is very difficult to any other app to know how to respond correctly. > Now I support application ACKs, but deleting the input queue before > committing it to the database is quite poor practice, Only a small > number of applications generate ACKs and many do not yet support HL7 at > all. I think this is the key point. ACKs and NACKs do need to be at the application level - as well as at the transport level, although the latter is redundant if there are app level ACKs/NACKs, but do no harm. This implies that the "smarts" need to be built into the sending and receiving clinical applications, and that putting smarts, sophistication and features into the transport layer is the wrong thing to do. Thus, simple, ubiquitous transport such as encrypted SMTP Internet email or Web services calls is all that is needed at the transport level, and all the real effort should go into improving the HL7 standards with respect to app level ACKs/NACKs, and then implementing those standards in clinical applications. Sending standards-based encrypted messages via SMTP or by Web services is not rocket science, and clinical application vendors should really just integrate this directly into their products, and thus cut the added complication of a messaging carrier out of the equation - it is just needless complicating layer (and middle-man). The Internet works as well as it does because all the smarts are at the edges, in the applications, not in the actual Internet networking infrastructure itself, which is very simple (and hence reliable and scalable, given the immense scale of the thing). So it should be with clinical messaging - let the oversight function for messaging, which ensures its reliability and safety, be built into the clinical applications, and have the simplest possible transport mechanism in between. Tim C _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
