Thanks Tom, >From our discussions with the other vendors I do not think you can say you have the full support of the other vendors.
Our position it that we we should be using common open interfaces and that the interface to the clinical system should also be standard (Ideally the same in fact). To suggest that you have a contract with every player is unworkable. The contract is that they process Compliant messages in a reasonable way and produce compliant messages. We tested the REF message support in January in the Hunter and it is still not working to an acceptable extent. You had been testing it for 12 months prior. I do not think the relationship between messaging and Clinical vendors should be a financial one, but a standards based one, You have not responded or given any assurances there. We may well have software components that overlap in functionality with other vendors but in a component based world that is always the case. As a "Son of Orion", Healthlink also has that issue. Our components are actually in use by other vendors and it allows them to produce AHML compliant HL7 messages easily, and at this point in time I would argue that just messaging is not enough to make it work, and we have demonstrated that we can make it work between GPs and specialists now. The actual messaging is only part of the story. Compliance with standards and message transformation to achieve that is another layer that is needed now. We even offered to integrate our tools to integrate with Healthlink sending, but you declined. Andrew McIntyre Tom Bowden wrote: > Ladies and Gentlemen, > > Following is a response to Andrew MacIntyre of Medical Objects, for some > reason it did not get sent two days ago. > > > Andrew's original post is provided below. It appears to be suggesting > that messaging should be provided as independently as possible of the > clinical systems. We however prefer an integrated approach but with > clear demarcation and the clinical applications responsible for message > acknowledgement. We are now seeing an interesting contrast in > approaches. > > > Andrew, > > I totally agree that there needs to be a tightening of the current > messaging specifications and implementation guides. I have instructed > staff that we will only participate in Connectathons if we have AHML > approved messages to hand a week prior and that has in the past proved > difficult because of the standards we have being so interpretable and in > some cases downright vague. Frankly I'd like to see AHML being given a > far stronger mandate to sort this stuff out. Thanks for your constant > effort to promote use of AHML and HL7 standards, we are in full > agreement on that course of action and endeavouring to do likewise. > > I note the way in which you have been able to interpret chapter 2 of HL7 > as not requiring an application level Ack. Irrespective of that > interesting interpretation, I put it to you that in the current > Australian environment, use of application acks by recipient systems is > actually very necessary as it creates a clear demarcation of respective > responsibilities and clarifies the individual responsibilities of the > parties in multiple delivery chains across a fragmented, diverse, > heterogenous IT environment. Unfortunately perhaps it also obviates the > need to open proprietary interfaces to the standard (If I understand > what you are saying this is what you appear to advocate as being the > right approach to take at this time?) > > I think it is important that we encourage those last few vendors that > cannot generate application acks or whose packages incorrectly handle > incoming REF messages to fix their systems. However I think it is quite > misleading to paint a picture that proprietary interfaces are widely > required, because to be quite frank, that requirement is disappearing > very quickly indeed and thank goodness. Your information regarding the > availability of REF message handling amongst vendors is well out of > date. > > And further to that, re use of correct message types, I am simply > advocating that we stop telling hospital IT managers that the only way > they can deliver electronic discharge summaries to GPs is by shoehorning > them into ORU messages, those days should be over. It is time to > implement the correct message types for the correct purposes. > > Our paper, and the accompanying draft code of practice (both of which > are receiving support from a range of parties including other messaging > system providers) aim to galvanise support for full adoption of > application acks (removal of proprietary interfaces that seek to replace > them) use of REF messages where appropriate and > finally.........Advocating a viable contractual framework where > integrators/service providers such as ourselves can work closely with > practice management system providers to deliver properly integrated > communications and security services. As an analogy, how would you like > to fly on an airline that had no contractual framework with any airports > it hoped to land at and expected the airport controllers and ground > staff to work for no payment? > > I think that a similar situation arises in an environment in which some > messaging service providers expect practice management systems vendors > to take messaging related support calls at no cost, integrate their > products at no charge, accept liability for unspecified legal damages as > they expose them to undefined risks, while at the same time in at least > one case, trying to sell the same clients competing clinical systems on > the side. > > Andrew, the current situation isn't working! However the practice system > vendors are, with few exceptions, ready and willing to make it work > properly. Let's not stand in the way of progress. Progress is long > overdue. > > Kind regards, > > Tom Bowden > CEO HealthLink Ltd > > PS An updated version of our Safety Through Quality document containing > the proposed Messaging Code of Practice has just been posted and the > link to it is below. > NB this version has had detailed input from AHML and a range of other > organisations with an interest in quality. > http://www.healthlink.net/healthlink_documents/brochure/Electronic%20mes > saging%20safety%20Issues%20-%20HealthLink%20viewpoint.pdf > > > > PPS Chris Scott: From our experience a 'fit for purpose Laboratory > Information System (LIS) should have an automated ' message manager ' > function for displaying non-acknowledged and negatively acknowledged > messages. With such a system negative acknowledgements are highlighted > and they have to be remedied and resent immediately on receipt of a > negative acknowledgement. Non acknowledged messages (ack not received > within 48 hours) are resent one further time before notifying the > service provider who intervenes on the sender's behalf if the message > has not been acknowledged within a further 48 hour cycle. Notification > can be manual or automated. > > Message from Andrew Macintyre > > > Thanks Tom, > > I printed out your document and left it on my Desk overnight, but there > is now Tojan Horse Poo all over my desk..... > > I am all for application acks, and correct ones at that, but this would > achieved if PMS applications were AHML accredited and a standard > interface to the PMS was adopted. Your proposal turns standards based > interoperability into interoperability based on contracts. Surely this > would lead to kickbacks where the messaging provider pays the PMS > provider for the > (?exclusive) ability to interface with it. Please assure everyone that > this is not part of your plan! "Plug and Pay" is perhaps the best term. > > This may well be Healthlink's Business model and the PMS vendors might > appreciate another income stream but It would be at the expense of the > users, as someone has to pay for that access. We have already seen > pathology companies forced to pay PMS providers for the privilege of > getting non standards based electronic orders and this proposal adds a > new toll both in the other direction. > > You need to reread the HL7 standard as your interpretation of it is > incorrect. "Pathology Messages" as you describe them, are in fact for > any clinical data, this is directly lifted from Chapter seven (ORU > Messages) > > "These transaction sets permit the transmission of any kind of clinical > observations including (but not limited to) clinical laboratory results, > the results of imaging studies (excluding the image), EKG pulmonary > function studies, measures of patient status and condition, vital signs, > intake and output, severity and/or frequency of symptoms, drug > allergies, problem lists, diagnostic lists, physician and nursing > history, physicals, progress notes, operative notes and so on. These > transaction sets carry information that is reported as text, numeric or > categorical values" > > On the question of the correct use of ACKS: This is from chapter 2 > > "The HL7 Standard makes no functional interpretation of the requirement > that a system commit the data in a message to its database before > acknowledging it. All that is required is that the receiving system > accept responsibility for the data, providing the same integrity test > that it would apply to data from any source. To continue the prior > example, the ancillary system may acknowledge the order after placing it > in an input queue, expecting to fully process the order into its > database at a future time. The only assumption is that the input queue > is maintained at the same level of integrity as the database." > > Now I support application ACKs, but deleting the input queue before > committing it to the database is quite poor practice, Only a small > number of applications generate ACKs and many do not yet support HL7 at > all. > > Healthlink also uses Non-Standard "RSD" messages for clinical data. > Thats not a message type I can find in the HL7 Manual? > > We have tested the available REF messages in The Hunter trial and found > that while 2 PMS's could import them, they were not brought to the > attention of the target doctor, and were not felt safe to use because of > this. > > wrt The discussions at the HL7 Meeting next week I would suggest: > > 1. A common interface for PMS data import be created which allows > for application ACKs to be reliably checked. This could be eg: > 1. Directory Based > or > 2. A SOAP interface into the PMS > > 2. A commitment made by PMS vendors to achieve AHML accreditation > for created messages within 12 months. > > 3. A test set of Compliant messages be developed that test > (and stress) the import capabilities of PMS systems. Ideally > this testing should be done by a third party eg: AHML > > 4. A common SOAP interface be developed for encrypted HL7 data transfer > so that PMS vendors can implement their own interfaces and > message transport in the future. > > 5. A common SOAP/HL7 interface be developed for Provider lookup and PKI > key management to allow for 4. to be implemented > > 6. A commitment by messaging providers to implement 4. and 5. within > 12 months and publish a per/kb fee for message delivery to allow > for open competition based on standards. > > > This would open the market and make interoperability a technical issue > rather than a contractual one. Compliance with existing standards would > do more to improve patient safety than a bonus load of contracts ever > would. > > The long term aim is to be able to turn up at a connectathon and > inter-operate with multiple vendors without having to speak to their CEO > to negotiate terms first. > > This level of interoperability is not easily possible at the moment > because of compliance issues rather than a lack of signed contracts. > Medical-Objects has participated at both HIC Connectathons in Australia > and made it happen, Argus has participated in the first, I note > Healthlink did not deliver any messages in either event, despite showing > just enough interest to get your logo in place for both. > > Andrew McIntyre > Medical-Objects. > _______________________________________________ > Gpcg_talk mailing list > [email protected] > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk > > __________ NOD32 2129 (20070320) 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
