Simon James wrote: > Andrew Patterson: > >> This was my understanding of the 'interface' used as well - I would suggest >> that monitoring a directory to see when/if files disappear is a far cry >> from the semantically strong application level ACK's that healthlink >> imply their system implements. > >> If the claim is that Healthlink only >> generates an ACK when it is guaranteed that the message has been >> viewed and dealt with by a clinical professional, I would imagine there >> must be a much richer interface between the clinical app and healthlink >> to achieve this? > > Hi Andrew, > > My understanding.... > > Generating application level ACKs isn't the messaging software's > responsibility. When and how application level ACKs are generated is > something the clinical software vendor needs to sort out - the messaging > vendors role is to transport these to the intended destination reliably. > > For me, the questions that need to be asked are: > > 1. Does clinical application X create HL7 compliant messages (and if so, to > which HL7 standard/s). > 2. When clinical application X receives a HL7 message, does it generate a > HL7 compliant ACK. > 3. When clinical application X receives a HL7 message, when does it generate > this ACK. > 4. When clinical application X receives a HL7 message, what user-centric > flags are raised (ie how does the user know the message has arrived)?
Although it is important, as Brian advised, to always look on the bright side of life, it does also pay to think about things occasionally going wrong. Hence NACKs (Negative ACKnowledgements) also need to be considered, things like "I got your message but it is invalidly formatted and so I can't do anything with it.", or "I got you message but it may have been sent to me by mistake." or "I got your message but my disc is full or my database server is broken and so I can't file it and I've probably just forget about it because without disc storage my medium- to long-term memory is as good as that of your goldfish." Or in response to one incoming message, application A sends back "ACK, looks hunky-dory." and application B (in the same practice) sends back "NACK, that was utter crap, please try harder." The sending app needs to know how to handle all these scenarios, and many more. As I said, a two-day workshop and most of these can be teased out, documented and de facto standards for how to deal with them created. NEHTA should sponsor such an event - would be a small amount of money very well spent. Tim C _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
