[EMAIL PROTECTED] wrote: > > On Sat Mar 17 14:43 , Tony Eviston <[EMAIL PROTECTED]> sent: > >> Tim Churches wrote: > >>> 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. > Currently there is no API which allows the clinical app to report problems > back to the messaging app: they are "over-separated". > Obviously it's that happy standards-based medium between the monolithic > super-app > and the current scenario we are looking for.
Yes, exactly, but it is insufficient to just say, as Tom is, "implement what HL7 2.x says regarding ACKs", because as Andrew points out, HL7 is vague on whether ACKs should be at the application level or the transport level or both, and as I point out, it is even vaguer about what to do in response to a NACK. It is not just the absence of an ACK that needs to be dealt with. >> It would also allow a one to many relationship between the message >> broking agent and the onsite clinical applications. > This means each clinical application has to keep it's own record, and > creates havoc with defining ACKs: what if one clinical app accepts the > message, but the other rejects, what's the messaging app to do then? At the end of the day, when a messaging problem has been detected and has failed to be resolved with simple resends, whether that problem is a failed ACK indicating possible non delivery, or a NACK indicating some problem with the message or a problem at the receiving end, then it needs to be brought to the attention of a human. In a GP setting, the obvious place to build these message alerting and troubleshooting functions is into the clinical application itself, because that's what the GP and other practice staff will be interacting with all day. At a big lab, sending thousands of result messages, then having this messaging oversight function built into specialised messaging software like Argus or Mirth probably makes sense. The main thing is that errors and problems like failed deliver are brought to someone's attention, and that it is administratively their job to do something about those problems, not just ignore them. Errors in yer face is the name of the game. My understanding of the way HL7 messaging works within hospitals is that typically there is a central HL7 messaging hub, typically Sun/SeeBeyond e*Gate. On the local hospital network, HL7 MLLP (minimum lower level protocol) over TCP/IP or sometimes just simple file polling is used by each application to send messages to other applications via the e*Gate. ACK handshaking occurs between the sending app and the e*Gate. ACK handshaking also occurs between the e*gate and the receiving application. The e*Gate is assumed to be a perfectly reliable store-and-forward mechanism, and rarely is app-to-app ACK handshaking implemented. The difficulties arise when there are NACKs - the e*Gate really needs to pass these through to the originating application, but because of the extreme vagueness of HL7 specs on the semantics of NACKs, there ends up needing to be point-to-point debugging and special case handling of NACKs for each pair of communicating applications. e*Gate includes all sorts of sophisticated messaging rewriting rules and other programmable actions to help deal with these situations, but it is still messy and very implementation-specific. Such is the nature of HL7 2.x The open source Mirth HL7 engine has similar facilities. I think Argus has some message rule facilities, but not so sophisticated? Not sure. Tim C _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
