Tom Bowden wrote: > I note the way in which you have been able to interpret chapter 2 of HL7 > as not requiring an application level Ack. Irrespective of that > interesting interpretation, I put it to you that in the current > Australian environment, use of application acks by recipient systems is > actually very necessary as it creates a clear demarcation of respective > responsibilities and clarifies the individual responsibilities of the > parties in multiple delivery chains across a fragmented, diverse, > heterogenous IT environment. Unfortunately perhaps it also obviates the > need to open proprietary interfaces to the standard (If I understand > what you are saying this is what you appear to advocate as being the > right approach to take at this time?) > > I think it is important that we encourage those last few vendors that > cannot generate application acks or whose packages incorrectly handle > incoming REF messages to fix their systems. However I think it is quite > misleading to paint a picture that proprietary interfaces are widely > required, because to be quite frank, that requirement is disappearing > very quickly indeed and thank goodness. Your information regarding the > availability of REF message handling amongst vendors is well out of > date.
I'll re-iterate what I see as the implications of Tom's recommendations, above: 1) Standards or guidelines are urgently required for the semantics of application-level alerts, ACKs, absent ACKs and NACKs. In other words, how should an application behave when a) it correctly receives a properly formatted message (should it tell someone, should it just file it away?); b) it fails to receive a message it was expecting c) it receives a bad message d) it fails to receive an ACK for a message it sent e) it receives a NACK for a message it sent. None of these semantics of ACKs and NACKs are specified anywhere, nor are the semantics of how to instruct applications to handle particular messages eg "serum sodium is 120, receiving clinical application, please alert someone NOW!". Where in any HL7 specs is this behaviour specified or standardised? Nowhere, but that's the behaviour that counts. 2) Clinical information system and lab information system vendors will need to build quite sophisticated HL7 message parsing, validation and storage facilities into their applications in order to generate ACKs and NACKs of the right type at the right time and in order to generate appropriate alerts for humans. That's fine, but if there were an Australian standard for interoperable secure health message encryption and transmission (i.e an open standard, as Internet standards are) then it would be very simple to build the encrypted transmission aspects of messaging into their applications as well, and in a blink there would be no need for separate providers of secure messaging software. One less company to deal with, one less layer of proprietary software to go wrong and be supported, less expense for everyone. Good. 3) Application level ACKs imply that there may be multiple responses from a single practice to a single incoming message eg if an incoming message is consumed by a clinical app, a decision support app and a practice management app, then application-level ACKing implies that three ACKs will be sent back. They may not all be positive ACKs. What if only two of the three applications send back an ACK. The sending application doesn't know that it was supposed to get three ACKs from that practice, not just two. Thus the behaviour of sending applications in response to these multiple ACKS needs to be defined, and it is not currently defined anywhere. Thus, there is quite a lot of homework to be done with respect to application-level ACKs via HL7. Tim C _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
