Tom Bowden wrote: > > Andrew, I think our readers could be confused by your comments.
Tom, I think this is getting a little long winded and beyond this I think its time to stop! All this positive talk about other messaging providers is obviously stopping you sleeping. > > Firstly, you say "An ORU message can be made to go into Results/letters > or documents using undocumented mechanisms and at times non-standard > message types" then you say you are "following documentation provided by > HCN". Which is it? OK, it is "Difficult to Obtain" documentation provided by HCN. Being inter-operable is viewed as a commercial thing by some, and its difficult to get an co-operation from some large vendors, I know Argus has had the same problems along these lines. So has E-Clinic, whom we have shared some of this documentation with. When HCN had autoreport it was only Autoreport that could magically get messages to appear in some places. The non-standard message types are the ones used by Healthlink. > > Secondly, why is Argus automatically excluded from the draft code of > practice? If so, why did Andrew Shrosbree make complimentary remarks > about the process and become the only other provider so far to indicate > some support for it? Well the process was supposed to be a mutual one, and as other message providers have said off this List "Every message provider has problems with parts of your proposal" You turned a mutual process of negotiation into a public one, that's your style. > > Thirdly, you talk about "the fact" that "just messaging doesn't work". > Clearly it does if done properly, with examples locally and around the > world. While purporting to be right in behind the various standards > initiatives, you say that "The way we achieve that is to make the > messages we carry and produce standards compliant". Are you > manipulating/massaging/ changing the messages at either end of the > process? If you are, in our view this merely serves to confirm you are > creating enormous levels of risk. If not, explanation may give us all > greater confidence and admiration. Well Healthlink did not work, after 12 months of trialing in some places we have been and one of our engineers had it working in about about a hour. We work with the people with the information they want to send to create compliant HL7 messages that do work. Don't worry we also have a Healthlink style of "Just Transport It" as well, but in the real world many organisations struggle to produce high quality HL7 and need some assistance. The major Pathology companies are very able, but we do provide interface engine technology to them also to enable eg The transformation of SNOMED-CT codes into local codes for internal processing. Medical-Objects is an integration company that also has messaging. Apart from the major pathology messages, which we can transport unchanged, virtually all of the traffic on the medical-objects network is AHML compliant. I think the risks involved in sending non-compliant messages are far greater than other risks you mention. The lack of attention to escaping HL7 Reserved characters is a huge concern to me. if you Type "\" or "|" or "&" into a document and send it unescaped and what comes out the other end is not what goes in, as whole paragraphs vanish!!! Medical-Objects does create an enormous variety of compliant messages for a huge variety of raw material and this is often what is needed as the organisation may have the data in an atomic form but lack the ability to transform it appropriately. We also provide the technology for digital signatures within the HL7 message, which satisfy the Act and allow paperless referrals. Despite the compliance we know that correct HL7 will not be processed by some applications and it we create the message then we have the ability to transform it at the client end can apply this selectively, to messages that we created eg We can archive the digitally signed message and evaluate the signature realtime and replace the signature with an OBX that reports the result of that evaluation. We can also strip eg RTF display segments that, despite the fact that they are 100% compliant cause some PMS import routines to crash! (The RTF display Segment is actually outside the signed data) We also generate messages for inclusion in standards and generated the HL7 V2.3.1 Trusted Message set. The knowledge we have gained about the issues has been fed back into standards Australia and you will find that the new standards and as yet unreleased technical reports contain explanations of how to do things properly in HL7 to enable interoperability to occur. This is what we mean about interoperability via standards rather than contracts. A contract between a Messaging provider who just does transport and a Vendor does not achieve much for the community as a whole, but is a commercial activity. I would suggest you offer to write a technical report to be considered for a standards committee rather than wax lyrical about how we got hold of documentation that was supposed to be commercial in confidence. > > Finally, as Andrew Shrosbree states, the EMR vendors should be sending > compliant messages. They should be encouraged in every way possible as > the Code of Practice suggests by all parties involved in messaging > thereby reducing the exposure of the sector as a whole to unnecessary > clinical risks. Well it doesn't say that now, AHML compliance for vendors is something I have been pushing for quite some time. They are far from compliant at the moment and in some cases quite dangerous, specifically escaping reserved characters in HL7 is not done and is an invitation for disaster. ( as Typing "|" in the middle of a letter will put all text after that character into a new field which the text is not read from at the other end) > > The Code of Practice is about doing the job properly and we would > welcome constructive progress in this area. We would think that many > parties in the sector including the clinical systems would be > signatories to it not just the messaging companies. We would also be > more than happy to get endorsements from professional organizations, > NEHTA and governments as well and we have approached them to progress > this. > A code of practice should not mandate business practices or interoperability by commercial arrangement. The whole point of standards is free and open interoperability WITHOUT the need for contracts. I am sure you would love an exclusive contract with HCN so that only healthlink has access to the documentation about how to get this result in this folder, and knowing you, you probably already have it signed, but I will never sign a code of conduct that mandates that Tom. Andrew McIntyre _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
