Thanks Tim, useful suggestion, I am corresponding with Ian Reinecke on messaging and security related issues and will put it to him that this is a good way for NEHTA to reconnect with these vitally important down-to-earth issues, confirm their interest in HL7 v2 and add some value. If it's OK with you I'll quote your comments below?
I'll let you know what kind of response I get in any event. Cheers, Tom Tom Bowden <mailto:[EMAIL PROTECTED]> Chief Executive Tel: +64 9 638 0670 Mobile: +64 21 874 154 Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> Web: www.healthlink.net <http://www.healthlink.net/> <http://www.healthlink.net/> Connecting The Health Sector -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Churches Sent: Friday, 23 March 2007 10:47 a.m. To: General Practice Computing Group Talk Subject: Re: [GPCG_TALK] Messaging Responsibilities Osborne, Steve wrote: > Geoff > I'm finding it difficult to understand how this works. My > understanding has always been the ack is generated when the result is > imported to the clinical application. Please correct me if I'm > mistaken in the following. ... It seems to me that many useful points have been raised in this thread, and that there is a fairly urgent need to define standards, even just widely agreed de facto standards in the interim, for the syntax and semantics of application-level ACKs and NACKs. As they stand, the HL7 2.x specs and AS4700.2 and 4700.6 and the handbooks associated with them provide a minimal framework for ACKs, but lack sufficient detail to be actually useful in this respect. But they don't get in the way, which is good. Now, if NEHTA could just sponsor a two-day roundtable for key stakeholders, then I dare say a draft standard for application-level ACKs could be assembled, put out for comment and we'd have useful common ground within a few months. Pats on the back for NEHTA would result Then that de facto standard could be put on Standards Australia's agenda so that it can wave its wand over it, if it so chooses. Tim C _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
