Attn Andrew McIntyre
Andrew, All the glib patter does not disguise the fact that what you are doing is unsafe, unwise and not good for the sector. 1 You say " There are in fact several levels of ACKs in HL7 and while will will support HL7 acks from PMS systems this ability is not universal as yet" (sic). Surely everyone will recognise that is just an excuse for not doing the job properly! In fact nearly all PMS systems now provide application level acks and messaging service providers should insist that they are used. As I am sure you are aware a number of key sector bodies are demanding application acknowledgement as a prerequisite capability for messaging, and you are saying they are not needed, not universally available etc, etc. Your position on this is something that the whole sector needs to take quite seriously. It is also a totally incorrect assertion on several counts. You are not moving the e-health agenda forward, This is a major issue. Please stop and think about it. Following is a link to a list of all of the major practice management systems confirming that they support application level acks for AS4700.2 messages, , this list is being continuously updated and a number of other systems are under test for HealthLink's accreditation process. NB a similar list is available for AS 4700.6(Ref) messages is available but not to hand. http://www.healthlink.net/healthlink_documents/Vendors.Supporting.AS4700 .2.pdf 2. You say " The level of support for REF messages is still not mature" again in our view this is just a convenient excuse for perpetuating the current muddle. We think you have a responsibility to try and sort it out (which we are doing) rather than turn everything into an ORU message. Once again, you appear to be upholding the right to use unsafe practices rather than trying to properly address what is clearly a critical safety issue. I know of hospitals that you are trying to persuade to deliver their electronic discharge messages as ORU (Observation report/lab result messages). This is a particularly bad approach from an overall point of view. Look at what could be happening, e.g. in WA where a number of hospitals are delivering discharges as REF messages to several hundred practices. Your contention that "support for REF messages is immature" is a situation you should be actively working on rather than perpetuating. 3. You say we are not AHML compliant and that we don't contribute to the standards process etc, etc; this is errant nonsense, we closely worked with AHML to develop the Draft Code of Practice which you appear unwilling to support (mainly for the reasons above I suspect). We don't create messages so AHML can't accredit us in that sense, but we work with them very closely to ensure that our message parsing is directly conformant with their requirements. Ring and ask them if you wish to. We are represented and strongly involved in the REF messaging standards process (Geoff Sayer). Don't please hide behind the fact that the single ORU message format into which all your message types are stuffed was once Ok'ed by AHML. Quality Assurance is a much bigger picture than that. 4. You say that you don't need to have contractual relationships with the EMR (electronic medical record) vendors. As you know we disagree, in a fully integrated electronic environment, support is a big issue and cannot be achieved without integration. Our relationships with vendors aren't hidden at all, if so, why would I be mentioning them here? The fact is that you cannot deliver a good communications model if you dump work onto other parties (testing, integrating, supporting). That is unless as you appear to insist upon doing, you rely upon tenuous (non-standard) end point connections without a proper acknowledgement loop (a time bomb waiting to go off). Now for all your fine talk about standards and interconnection etc, why don't you take a look at the code of practice and interconnection model we are proposing and then start commenting. We have a duty of care to do the job properly. It is about time that some people stepped up to the plate. Regards, 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 Andrew McIntyre Sent: Tuesday, 1 May 2007 9:24 p.m. To: General Practice Computing Group Talk Subject: Re: [GPCG_TALK] If it sounds too good to be true it probably is Tom Bowden wrote: > Dear Colleagues, > > All people reading this list should be aware that unless a messaging > system is fully integrated with the EMR (electronic medical record) > software at either end of the communications link, it is hazardous. > Would-be purchasers should not be taken in by the superficial allure > of a piece of software that provides part of the communications loop > and purports to handle the rest but in fact leaves the rest of the > process almost entirely to chance. Yes, realtime point to point delivery with a distributed architecture - I don't think that arises by chance... HL7 is the integration point. > > A few of the questions that need to be asked... > > > 1. Typically such systems do not provide a full end to end > acknowledgement loop as they rely upon the intermediate (messaging > system) software to acknowledge the incoming messages - This means > that such systems are _absolutely not HL7 compliant_. I know that you feel that if you keep saying it people will think that is true, but it is not. There are in fact several levels of ACKs in HL7 and while will will support HL7 acks from PMS systems this ability is not universal as yet. Healthlink is absolutely not AHML accredited but you continue to allude to the fact that you are. > > /Does this system send its own acknowledgement messages (to itself) or > does it rely upon the recipient application's ability to acknowledge > (which is the right way to do it)? / > > 2. Typically they turn everything into an observation message (ORU) > instead of a referral (REF) message . While technically this is not > "illegal" it certainly bends the rules and creates a very difficult > file management headache for the recipient. The level of support for REF messages is still not mature, and in reality a REF message is a container for multiple ORU messages and Medication details. So the difference is somewhat academic in most ways, especially when the current crop of REF messages often contains a single Blob of poorly escaped RTF. Its the non compliance of the payloads you carry that causes you headaches. Medical-Objects is an active member of the voluntary Standards Australia working group that is specifying the REF message and is also involved in the committees for several other message types and I would appreciate you coming and helping given your strong beliefs. > > /How does this system deliver non observation messages, as ORU or REF > messages? / > > 3. Typically such systems vendors have no support or other > relationship with the EMR vendors and in a number of cases, this one I > fear included . They are therefore viewed as competitors by other > EMR vendors - the net effect is an antagonistic relationship when it > comes to any problem solving and little or no helpdesk collaboration, > joint documentation etc . Medical-Objects takes responsibility for sorting out the issues before we send the messages to try and reduce the issues at the destination. The level of co-operation from vendors varies, and probably mirrors the quality of their end user support. I think that the relationship should be a professional one rather than a business one, but I know you see the world as a place of deals and financial arrangements. We are just old fashioned I know. > > /Does the provider of this system have a contractual relationship with > the EMR software providers at either end of the delivery chain or not? > / > as above.... We see our users as our customers and they have a contractual and financial relationship with their software vendors. I think for us to have a hidden financial relationship with their vendors is unnecessary, but I don't think you agree. The message is transmitted from doctor to doctor and the HL7 and PMS is just the vehicle. > In summary : > > Users should be aware of the limitations and dangers of using > _non-integrated communications systems_. If they persist in using > them, they should ensure that they continue to send paper copies of > _everything_ in parallel, they should advise all of their partner > organisations to ensure their medical indemnity insurance is fully > paid up and advise their patients that they are part of an > experimental programme that aims to show that common sense approaches > to healthcare messaging are no longer needed. I think a positive approach outlining places where you have achieved doctor-doctor messaging would be preferable to scare mongering, As a doctor I live with risk all the time and Medical-Objects has taken the step of becoming AHML accredited and having a deep understanding of the standards as defense against these risks. We are continually moving ahead to enable real time messaging so there will always be some experimental sites, but then again there will be no progress unless this is done. Widespread real time point to point messaging is what we are delivering today and that has only happened with R&D. I appreciate that the healthlink central hub model is old technology that has been experimented on in NZ and is now fit for the Australian masses. > > Electronic messaging has to be a very disciplined business. In a > fully connected Australian health sector approximately 1 billion > messages will be exchanged annually. This cannot be done on a wing > and a prayer. If the sector wants to see a fully interconnected > messaging environment, then this must be done according to rigidly > enforced standards, especially important is adherence to those > standards that relate to delivery integrity. > > It is time to look at this issue in a bit more depth. Yes and I think realtime distributed systems are what we should be aiming for. An open standards based environment is highly desirable to avoid Monopolies developing don't you think? Ideally then the EHR applications could then do their own messaging and avoid the middleman altogether, that would be even safer. Andrew McIntyre Medical-Objects > > Kind regards, > > Tom Bowden > > > > *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* > _______________________________________________ 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
