Its clear that I am not a fan of Australia’s attempts to progress eHealth. Its probably time to look at some details. The devil is in the details after all.
The first basic error of HealthConnect and NEHTA Mark 1 & 2 is a violation of a principle that I think is very important in this field. This comment from “Joel on Software” relates to Netscape’s decision to rewrite Netscape Navigator from scratch. The full post is worth a read and is available here
“making the single worst strategic mistake that any software company can make:
They decided to rewrite the code from scratch.”
This error has been repeated again and again by every NEHTA clone in the last 10 years. Despite declarations that Australia has decided on using HL7 V2 on several occasions, attempts have been made to “roll our own” standard. This has of course failed again and again but this lesson is continually forgotten. Even the UK NHS backed up with 30 Billion pounds and a draft HL7 V3 standard has failed dismally to achieve this and its time we decided to use whats in place, proven and tried to improve the quality of implementations rather than somehow develop something new.
The fact is the HL7 V2 standards have been proven to work for a large variety of the indications we desperately need and there is actual support out there in existing local and international applications. The support may not be perfect but its a base to build on. The fact that its 20+ years old is often used against it, but code does not rust in my experience and something thats been refined over 20 years is likely to be a far better bet than something shiny and new that has never been proven to work. Its ugly in places and has all the warts and battle scars of a standard that was, and never will be perfect, but has been proven in battle. This same idea of avoiding a rewrite from scratch is a lesson that HL7 has learned the hard way with HL7 V3, which despite good intentions and much work fails to be a viable replacement for HL7 V2 after 10+ years of work.
NEHTA, not having any real expertise in HL7 V2, have a blind spot to what is actually working in the landscape and how it works and treat the existing messages as some sort of “blob” and as a result fail to understand that the important business processes of healthcare are deeply embedded and supported in HL7 V2. Ignorant of this they have wasted precious resources in re-engineering the business processes in services that have come and gone and never been used in anger. These services were to use HL7 V2 but the details of this “blob” content was never understood and the defense was that the people they talk to didn’t want to use HL7 as they did not understand it. I assert that this is the problem. HL7 V2 supports the business processes in a proven manner, often in far more detail than these first draft services could ever hope to achieve. Overlaying 20 year old proven HL7 V2 services with naive first draft services that often conflict and overlap with the actual message is not a recipe for success. HL7 V2 needs only one service, and thats a security wrapper to allow secure authenticated transmission. Duplicating a small percentage of the richness in the service only creates confusion. What do you believe the payload or the wrapper? The payload has been refined in over 20 years of real use and lack of understanding of the payload is not an adequate defense for producing a pale imitation of it.
Its this blindness to the ecology of healthcare IT that results in the unforgivable lack of push for compliance testing of existing HL7 V2 implementations. Its hard to be critical of the quality of messages you don’t understand yourself and you simply nod and say “it looks like HL7 to me, but it does not work. I have no idea why, lets build our own standard”. It will never work and the half a billion dollars proposed for ehealth in the recent Budget is a waste, just like the Billion $ wasted over the last 10 years. Nothing, not even identifiers, has any value until quality issues are addressed in the current environment.
There are certainly deficiencies in HL7 V2, mostly because it has been neglected because of the focus on HL7 V3. These deficiencies can be addressed, but only when basic quality checks are in place. To try and improve semantics without addressing the basics is misguided. One basic functionality we could have is allergy checking. That is assuming we had some building blocks that worked.
The “Simple” task of allergy checking is in fact not at all easy. A patient may have a penicillin allergy recorded, but patients are not prescribed “penicillin” these days. They are prescribed Augmentin, or Timentum etc These drugs contain a penicillin derivative, and should not be used but we need to know that they are children of penicillin and this is where a medication terminology is supposed to step in. The “AMT” or “Australian Medication Terminology” was supposed to fill this gap and has had 50 people working on it for 4 years or so. Surely this can be used for this basic task? The answer is no…. It fails to provide any mechanism to identify that Augment contains penicillin!! SNOMED-CT – the terminology its based on certainly does but the AMT is isolated from SNOMED-CT and cannot do this. You would have to manually go through it and pick out every drug containing penicillin, using some sort of external data source. This is the exact role a medications terminology is supposed to fulfill and while it might look like a medications terminology its just a big dumb pick list.
To progress eHealth we need an organisation that uses existing standards, potentially tries to improve existing standards and understands in a very low level way how those standards could be used to achieve the things that eHealth promises. Ideally it would test those things and provide expertise and workers for standards bodies. NEHTA as it stands is a political organisation mainly that produces very nice visions and glossy brochures. It also has some very talented super specialists who know nothing of the big picture and is lacking in individuals (or not empowering them) who can see a path to evolve the current landscape into one that really works reliably and safely and can contribute to the process in a positive way.
The examples of the lack of low level understanding of the technical details and true state of the current landscape or abilities of the current standards are virtually endless. I have presented some personal views on a couple of them. There is no forum for this type of discussion in the current environment and everything is done at a level where the technical details are out of scope. This really makes success out of scope and value for money ($500,000,000 in fact) out of scope. Health IT needs to get into the technical details, managements role is to make this easy for the people involved and shield them from the political process. Its the equivalent of a hospital staffed only by administrators and quality control consultants, but no nurses or doctors. From memory that hospital won the “Florence Nightingail Award” for cleanliness in Yes Minister. Patients are unlikely to benefit.