Simon James wrote: > Both are needed really, they serve different purposes. I guess the thing to > be aware of with application ACKs is when they are generated. EG An > application level ACK generated when the clinical package imports the > incoming message doesn't tell the sender the message has been read by the > recipient (or necessarily tell the recipient the message has arrived). As > such, additional checks and balances need to be in place to provide these > assurances.
This is what I keep banging on about in this discussion: the need to define the semantics of ACKs: what does and ACK really mean, and when should a NACK be issued instead, or as well? None of this is defined in the HL7 specs or Australian standards, and they need to be. So Tom Bowden is correct, applictaion level ACKS are needed, but his view is far too simplistic and standards need to be developed around how apps are supposed to behave when they do (or don't) receive a message eg issue an alert, seek positive confirmation from an authorised human that it has been read, just file it away etc, and how they indicate that action to the sending application. And Andrew McIntyre is completely correct that all this needs to be defined in open standards, not based on application-vendor to messaging service provider deals. If we had such standards, as well as standards for the transport/encryption layer for messaging, then application vendors could and would just implement messaging directly in their products and the mini-industry of health secure messaging which has sprung up will just melt away, and life will be simpler and cheaper for everyone. >> Healthlink and medical-objects should be licensing their >> message layers to clinical app vendors to integrate fully into >> their programs. > > Can you indicate what you mean by "integrate fully" and give an example > where the functionality of such "full integration" couldn't be achieved > using the "uncoupled" architecture present in the market? Say a path lab sends an HL7 message to a general practice indicating a sodium of 120 in a patient, and marks it as "urgent" (does HL7 2.x or AS4700.2 have a defined facility of marking items as "for urgent attention"? If not, they need to.) The message is delivered to the GP's clinical application, which reads it, files the data on the patient's record, and pops up an alert or posts a alert message in the clinical applications messages panel which requires positive and authorised acknowledgement from a medical staff member that the message has been noted. The clinical app then generates and sends an application-level, properly formatted, HL7 2.x ACK containing the information that the message has been read and acknowledged by Dr Z. Smith at the Jupiter2 General Practice. Lab receives that ACK and files it away. Everyone happy and all bottoms are medicolegally covered, and most importantly, the patient survives. So what is the role of the "secure messaging provider" in all this? Frankly, not much - just look-up of the message recipient address and public key details, encryption and dispatch of the message. At the moment, each messaging vendor does this in a different way, mostly using their own proprietary infrastructure (even Argus has its own LDAP servers, out of necessity). But the software technology used to do these things are all now rather commonplace, and are provided by native or plug-in libraries in most programming and software development environments (LDAP lookup, X.509 encryption/decryption). Remember that clinical and other applications need to understand HL7 message parsing, validation and construction anyway - that is definitely not a job for the messaging provider.. So one is left wondering, if we had proper open messaging standards (meaning standards for address lookup, encryption and message transport), what role would there be in the medium-term for separate messaging providers? I'd suggest none - just build message encryption and sending/receiving into the clinical application. There may be a role for something like SeeBeyond e*gate in each practice (not actually e*gate - far to complex and expensive) that acts as a message store-and-forwards buffer and handles the actual comms bit. But that ought to be just an appliance, like your router is an appliance. Indeed, the open source Mirth HL7 messaging software is available in just that form - as an appliance that you just plug in - see the 'appliances" tab at the top of the Mirth home page at http://www.mirthproject.org/ Secure messaging providers in health are not somehow owed a living, and have no intrinsic right to exist in the health ecosystem - they should be tolerated as an extra layer of complication and expense only so long as they are absolutely required and play a useful role. I am suggesting that given some decent open standards for what they do, that useful role can just be subsumed into applications and/or a little appliance, and the current secure messaging vendors can just wither or re-invent themselves to play some other useful role. We shouldn't actually care - software products are ephemeral, just tools, and software vendors and IT service providers likewise. >> The current situation (of separation) is a strange confluence >> of events and surely will pass? > > Not any time soon, at least for the transmission of messages between > competing clinical packages. For obvious reasons, clinical vendors "A" and > "B" are more likely to deal with messaging vendor "Z" than each other. Standards are needed to overcome this - see my posts to this list yesterday regarding news from Britain re GP-to-GP data interchange, between different vendors' systems. If a govt body defines standards and bangs vendors heads together, then suddenly they discover that interchange of data between each other can be done, after all. Will we have a govt prepared to do that in Oz in the foreseeable future? Maybe. Tim C _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
