Dr Andrew McIntyre posted this a few days ago. (Reposted with Permission)
Extreme e-Health – what’s gone wrong?
Extreme failure in e-Health programs is in the news and Australia, as it usually does, appears destined to repeat the mistakes of others.
There is clearly a fundamental error in the approach to the problem and like the global financial crisis, I would postulate the error is ignoring the lessons of history and the folly of “generic management”, who do not have a deep understanding of what they are managing. Large IT projects fail frequently and this is well established in the IT world. Top down centralised management by persons without a deep understanding of IT or Medicine virtually assures failure and Australia has large doses of both.
You cannot build a complex system on poor foundations and that is what is attempted time after time. Just like getting a building out of the ground is an important milestone when building a physical structure, having reliable, well tested base level functionality is an important foundation for a working e-Health system. Instead we describe castles in the air, like the PCEHR (Person Controlled Electronic Health Record). I am yet to be convinced that it is the right castle, but to build it, inter-provider messaging needs to be in place first and the lessons learned and infrastructure reused. Instead we have an array of unproven, and in most cases non-existent “proto-standards” proposed as the foundations. In software engineering circles the term “code smell” is often used to describe something in the code that is clearly wrong, even if it appears to be working at the moment. To most in the medical software industry the code smell of the PCEHR is overpowering.
We have no solid standards based messaging, with the SMD specification created with a dependency on a non-existent NASH (National Authentication Service for Health) and a non-existent ELS (Endpoint location Service) and a dependency on the recently hacked and over complex WS-Security. Despite having a working and costly Certificate authority with most GPs having Medicare location certificates the wheel has to be reinvented to satisfy someone’s love of xml based web services.
The AMT (Australian Medications Terminology) is brain dead, with no ability to do proper allergy checking or drug disease interactions. We have a license for SNOMED-CT but minimal market uptake of any quality usage of it and scant localization.
Our Unique patient identifiers have no published quality measures or risk assessment and yet all the risk has been hoisted on the users. Our provider identifiers have had no real use, no freely published API and are fundamentally flawed because they are not location specific and cannot easily be used for pathology messaging because of this. We need location identifiers badly, but this is optional in the plans!
We will continue to use HL7 V2 for pathology (and clinical messaging) but no attempt has been made to ensure basic patient safety is protected with many non-compliant implementations and an inability be confident that data will be reliably read at the endpoint. Instead we are to introduce new standards without fixing what is in use and will continue to be used for a long time.
To build a complex system you need all these building blocks functioning reliably, with compliance expectations on both the sending and receiving sides. This is obviously not sexy enough for the politicians, but we have spent several billions on e-Health in Australia with little return so hopefully at some point someone will try a different approach and spend a couple of million on program to mandate compliance with existing proven standards.
We appear to be able to insist that new drugs have trials, but can continue to hoist unproven standards and systems on users without any proper trial. The potential effects of bad e-Health are just as bad as any other unproven treatment and it’s time to take patient safety seriously and use proven standards with an expectation of compliance by all players, including the government sector. It would be costly for many non-compliant systems to become compliant, but this would be money well spent, money that has to be spent and it would have long lasting benefits. The returns on our current castles in the air will be non-existent.
So what would a good strategy look like? Simply mandate compliance with existing standards and as a result create vendor interest in participating in the standards process. The users need to pay the costs of this compliance and funding could be directed to that end, but the focus of the industry needs to be on quality, compliance and creation of standards. If that was mandated then end users would have no choice but to pay the increased costs initially, but over time the free flow of reliable clinical data would result in increased efficiency and patient safety would be ensured. The privacy issues of provider to provider messaging are also already known and solved. A base of high quality implementations would also allow for gradual enhancement of the semantics of the content. Without basic compliance and quality in place the grand plans are a pipe dream.
This entry was posted on Sunday, October 23rd, 2011 at 1:41 pm
The blog is found here:
Andrew’s message on patient safety is an important one - and ought not be ignored!
Agree totally!
David.
6 comments:
Andrew, you say "Simply mandate compliance with existing standards and as a result create vendor interest in participating in the standards process"
How would you mandate compliance with existing standards? and why would that create vendor interest in participating? I've always thought that the problem is that the purchasers aren't interested in such a mandate, and if the government did mandate it, the standard process would suddenly be overwhelmed by the purchasers asking for the impossible.
And do you really want the government to mandate clinical functionality? Isn't that what would result?
Hi Graham,
They can and should only mandate compliance with existing standards, which means that systems must produce compliant messages and must consume compliant messages. They should also undertake some testing. AHML is the one that exists and is not adequate long term, but would be a good start.
If vendors knew they must comply with standards they they are likely to want to have input into changes or additions to those standards if only to protect themselves. Currently the workforce is small because there are very few vendors participating.
I am sure end users would complain about that it increased the cost of their software, but it is for a safety reason.
Clinically I am told I cannot use hot packs in a day surgery because of the risk of burns, but I have to consume HL7 Messages that break all the basic rules of encoding reserved characters and pose a significant risk of mis-communication. The two levels of concern are miles apart, possibly because regulators can see hot packs, but IT errors are below their field of vision. Its time they obtained some glasses.
but *how* do they mandate that? Of course I agree with all you say - how could any one not? But how do you get to that point without bringing all the bad consequences along? I think you've got a pipe dream here.
Well they seem to manage compliance with Australian Standards on Cars, Building material and Hospital Accreditation etc.
Drugs are regulated, as are devices. A regulation that all communication between health care providers comply with standards and all senders and receivers will support standards based messages (HL7 V2 is what we have current standards for) is what is needed.
I have heard it said that they will never do it because the states have poor compliance and it would cost them to fix it... This is the problem as no "ministerial" will convince software to become forgiving, its binary, its correct or it fails. So much of my current effort goes into fixing errors that doing anything new or semantic is impossible. The costs of compliance with AHML, as a first step, would be repaid very quickly. The receiver compliance is probably the biggest priority as you can't actually send compliant messages to a large proportion of receivers now, and as a result compliance is not a target for the big producers. This needs to change.
My small experience with linking 'HL7' enabled systems together suggests we have a long, long way to go before we are anywhere near the grand designs of nehta. Many systems cannot handle repeating fields, many say they are at 2.3.1, but are really at 2.3, many are even confused with the use of referring doctor, local doctor, attending doctor etc, some have trouble with multiple copy doctors, some only use file transfer and not socket transfer. And then there is the numeruous ways in which code sets are used and maintained - even coding for sex is done in different ways.
As Andrew says we need some incentive for people to implement the current standards with some alacrity, before we can charge off to the next wonderous stage.
To some degree I have to concur with much of what Andrew McIntyre is saying. However, the traditional way of thinking about how to resolve the issues and overcome obstacles in the hope of finding a way forward has been tried in various combinations over recent years to no avail.
Almost a decade ago, and on many occasions since, I proposed some alternative ways of thinking about how to lower the barriers to progress. Discussions were held with various people in DOHA, Medicare, HealthConnect and NEHTA to no avail. Consistently responses were “We have never done things that way”, “That approach would never work”, “That is not Government policy”, etc. For whatever reason it seemed to me they simply didn’t understand, or didn’t want to understand, or couldn’t think outside the caged environment of the bureaucracy”. Creative lateral thinking appeared to be actively discouraged in favour of rigid bureaucratic processes. Innovative thinking was foreign.
As someone said recently “surely they’ve tried every way that doesn’t work perhaps it’s time to think about trying another way that will work”. I like to think after 40 years in the business I have learn’t a few things about problem solving. A new way of thinking is what we need. Perhaps that time has come.
Post a Comment