Following Andrews comment, this is the reason for getting folk together at HL7 path/radiology messaging workshop on 22nd March.
www.hl7.org.au - follow the link to meeting notice Regards Peter Please note: due to increasing problems with SPAM, I am using SPAM ARREST - http://www.spamarrest.com/affl?4034505 - a relatively inexpensive service which extends my current email service and prevents automated SPAM attacks by checking with email senders that they are bonefide people needing to communicate with me. If you are not already in my address book and reply to this, you may receive a confirmation email asking you to respond. Once you answer, the email is on the way and will receive my attention. I am evaluating this service and would appreciate any feedback on it. I also have information on the corporate configuration of the service. Peter Macisaac MacIsaac Informatics Consulting in health informatics, HL7 and terminology [EMAIL PROTECTED] peter_macisaac (skype) 61 2 61611327 (landline) 61 411403462 (mobile/cell) www.macisaacinformatics.org -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew McIntyre Sent: Sunday, 11 March 2007 11:49 PM To: General Practice Computing Group Talk Subject: Re: [GPCG_TALK] Messaging Responsibilities syan tan wrote: > get rid of babel ? that would be like cooking the goose that lays the > golden eggs. I think there is plenty of work to be done without the problem being turf protection. It is a tower of Babel because the applications cannot participate in the HL7 discussion at the level that they need to. The actual transport is only a very small part of whats needed to achieve the interoperability everyone wants. As well as transport you need to insert a babelfish into the clinical applications ears. Most of the work Medical-Objects does is on the Babelfish and not the transport. Without a rich and flexible layer to massage data it simply will not work with todays clinical applications. We have seen failures with slightly different versions of the same Companies application, even the Same application fails to import messages it produces! While there is quite a bit of complexity in secure messaging, its not "The problem" - its the lack of standards support and AHML accreditation. Most Path lab data is pretty good, and not far from compliance at all, but go outside that arena and all hell breaks loose. Even PIT compliance is an issue! If you want to fix the issue, the attack has to start at the compliance level. Andrew McIntyre > > On Sun, 2007-03-11 at 10:16 +0900, [EMAIL PROTECTED] wrote: > >> 1/ if you set a clinical app <-> messaging app standard, why not set a clinical >> app <-> clinical app messaging standard and do without messaging apps altogether? >> 2/ given 1/, and that transmission is guaranteed by the ACK, what does a >> commerical 'messaging provider' do? >> >> Ian >> >> _______________________________________________ >> 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 > > __________ NOD32 2106 (20070310) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > > _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.441 / Virus Database: 268.18.7/713 - Release Date: 7/03/2007 9:24 AM -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.441 / Virus Database: 268.18.7/713 - Release Date: 7/03/2007 9:24 AM _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
