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
