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 to 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 its 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.

Posted in DECISION SUPPORT, EHR, HL7, MESSAGING, SOAP, STANDARDS | 2 Comments »

Australian eHealth still at the Cross Roads!

It’s interesting that there is such a emphasis on xml as the solution when its just an encoding format.

I implemented HL7V2 (classic) <–> HL7V2 (xml) functionality about 7 years ago but have found no real world use cases or demand for it as all it does is bloat the message for little advantage. If xml was the critical factor this should be in demand.

It is the functional models that are important and the encoding of the data should be pushed down to a lower level of the software functionality, and is not a critical factor in success.

CDA gives us a xml document format and easier mechanisms of dealing with hierarchical data. It provides no messaging functionality at all so would need to be encapsulated in HL7V2 messages or a new layer of messaging functionality provided. Hierarchical data can be encoded in HL7V2 and EN13606 archetypes can provide metadata that allows rich functionality wrt hierarchical data that is comparable with CDA. Even without archetypes implementation guides for specific data would work, if they were developed.

Given the funding available I doubt all endpoints can be made capable wrt CDA within 10 years (Given that PIT only systems still exist). Medication management standards in HL7V2 already exist and were even trialled in the “Better Medication Management System” but it appears all this knowledge was lost when HealthConnect Version XX was killed. The current HL7V2 medication standard is more in line with existing implemented medication functionality and supports a rich range of functionality.

Given the expensive failures in the UK and our limited budget the pragmatic solution is enhance what we have and build on existing knowledge. It may not be “trendy” but its probably the smart solution in the face of our limited budget and the fact that we already have widespread V2 support at some level.

We do need compliance programs and in many ways they already exist at a basic level in the form of AHML. Most of the current issues relate to poor compliance with standards.

I agree with Eric Brown that we need a lot more work on Terminology support to achieve semantic interoperability, but we need a sensible overall direction before that can be tackled. What we actually want is stable V2 standards where extensions in functionality are achieved by better use of terminology rather than changes to the standard. This is the basis of decision logic.

The performance of some of our terminological efforts is less than stellar however as AMT is virtually devoid of semantics and will not deliver in its current form. The fact that this is not apparent to people who should know concerns me greatly and suggests that there is no big picture understanding of where we are heading. This concern also applies to CDA based Medication management which appears to support just one transaction: “Deliver script to Pharmacy”. I appreciate this is what people want first, but a brief look at the Medication standard will reveal 76 interactions where only about 10 don’t have a V2 message specified. The scenario of deliver script to pharmacy is just one of the 76 and it is specified.

I think many underestimate the complexity of the task and how well HL7V2 is actually working at the moment and keep asking external experts to solve the problem. After about 2 years of work they usually realise that the problem is huge and not easily soluble with “xml”. The solution requires high quality standards compliant implementations that build on working solutions rather than trying to reinvent the wheel. There is no quick fix and the current 2yr PCEHR program is likely to fail as it fails to build on working solutions, or even a agreed work plan. Its also largely a standards free zone and that should ring alarm bells. The only way to interoperability is a single implementation for all or standards. A single implementation for all is just not going to happen.

I think the evolution of the internet from basic view only type functionality in the early 90’s to rich Web 2.0 functionality in 2010 is the best analogy. HTML and Javascript have not changed much, but the quality and compliance of the browsers and web servers have improved to the point where high level functionality is possible. A similar 10 year plan for improving quality and compliance of our existing eHealth standards would lead to a similar transformation. CDA may form part of that program, but its not the “solution” and is not the priority at the moment.

Posted in EHR, HL7, MESSAGING, SNOMED, STANDARDS | Comments Off

Why CDA is a poor choice for prescribing

There are some who feel that a move to CDA for electronic prescribing is a better option than using HL7 V2 messages. I would contend that this is seriously misguided.

Prescribing is in effect an ordering activity and orders have line items and are not documents in any logical sense. While printed prescriptions may appear to be documents to a casual observer they are in fact a collection of orders and as is usually the case with orders each line item has state that changes in an independent fashion form the other line items. It is not uncommon the cancel an order, or modify the dose or form and this needs to be done at a line item level, not a document level. In effect each line item has methods to change its state, eg from ordered to cancelled or to update it. In a similar fashion the dispenser may substitute one line item for another or decide to cancel one line item. Also they may want to forward one line item to another dispenser, but dispense the others. In effect each drug order is an object with state and methods which supports an extensive array of methods that change its state and allow these state changes to be notified. A brief glance at the HL7 V2 Medication standard produced by Standards Australia with show a vast array of interactions and state changes rather than transfers of simple documents. Supporting these with a document is messy at best as the document is supposed to be static, when in fact every line item is dynamic with a life of its own. To do this with CDA would require adding all the methods as external logic and result in a huge number of new documents, without any good mechanism to identify which line item was changing.

In contrast HL7 V2 has a mature and if need be complex array of ways to effect these state changes. The challenge to is fact to define what you want to eliminate to make it easier to implement rather than a complete lack of abilities. Having a mechanism that supports the full range of state changes may seem complex at first, but ignoring the complexity of the real environment and going for a simple document solution may seem attractive at first but the pain is merely delayed as the lack of support for the know use cases will make future changes extremely difficult and the document model is wrong.

To suggest that CDA is more advanced is wrong. It is a technology that is still under development and a move to V3 of CDA, which is not backward compatible, is planned. The HL7 V3 medication messaging model would be more suitable, but is not ready and in a similar fashion there are changes planned with a move to V2 of the HL7 V3 data types (and V3 of the CDA standard).

We have a standard and well defined use cases in HL7 V2 and know that the model can support the rich interactions that should be part of the future. With CDA we have a trendy document format, never designed for Medication orders, and unproven in this role. The basic functionality of sending a document would be relatively easy, but that is the tip of the iceberg and all other interactions will involve re-engineering the order interactions that have been a proven part of v2 orders for many years. Its fools gold and will not provide us with a path to the future, but will be an expensive diversion. If HL7 V3 is the target we need Medication Messaging and not documents. Medication messaging is harder because the use cases are harder.

What we have in CDA is a solution for the easiest use case, but no path to a rich eHealth landscape.

Posted in DECISION SUPPORT, EHR, HL7, STANDARDS | Comments Off

NASH, Lies and Ideologically Driven Architecture

Like many people, the idea of e-Health excited me in the mid 1990’s and I got the bug, and wanted to contribute to it. After 15 years, countless standards meetings and international plane trips to attend meetings I would expect us to be further ahead than we are. In fact most people would expect that.

The traditional answer from bodies such as “Health Connect” is that the problem is “change management”. This is pretty unhelpful overall. While change management is required, we first need working solutions and the lack of specifying those is the real problem. There will never be a final solution as Medicine will always change, but what we need for national programs to work is real solutions to build on. In typical public service fashion, no one has been brave enough, or pragmatic enough to actually select one. I guess if it’s a work in progress it can never fail, except many of us believe that the governance has failed in a big way and mainly because of a lack of pragmatism and no deep understanding of the domain.

The glaring example of this is “NASH” – the national authentication service for Health. This is Nehta’s baby and they have failed dismally. For about 10 years we have had HESA Medicare PKI which after a woeful start actually delivers a PKI service for health that is real. Its initial architects could not see much past Email, and it was aimed at that, but it supplies Encryption and Authentication certificates that are actually in existence for the vast majority of general practices in this country. It is not however restricted to email and there is a freely available library available from Medicare that does PKCS-7 encryption and digital signature in a cross platform way. Despite the howls of protest, it does work cross platform and we have been using it in this fashion for many years. It’s not a speed daemon, but it works and it’s free. It even has a SQLite database for the key ring management which shows remarkable foresight as this is a binary cross platform file format as well! It’s this technology that powers the online billing in this country. Despite some suggestions that it was “never designed” for clinical content, it was, and this was enshrined in the electronic Transactions act from 1999 to 2009.

However when we (the industry and Nehta) came to debate the SMD – “Secure Message Delivery” standard Nehta would have none of this, They told us they had NASH which would solve all the” issues” with the Medicare PKI and this would allow us to use the latest and greatest xml encryption and despite having message level security they wanted to add TLS as a requirement. This is a function that requires certificate usage outside of the Medicare Certificate usage and means that the Medicare Certificates are not sufficient. Newer versions of some IDEs’ also require extended certificate usage to perform xml encryption which also invalidates the certificates for this supposed advance.

As someone who protested that the practices already had Medicare certificates and the PIP incentive was to use them, I was suggesting a more pragmatic solution using PKCS-7 which could be used with REST or a more simple SOAP specification. The response was that the PIP requirement was to “apply” for the certificates and did not require “using” them! We were told NASH was “close” to being available and would solve all the issues.  Thus the pragmatic solution was not going to be considered.

It’s now apparent that Nehta’s attempts to implement NASH  have failed! They are going out to tender not just for implementation, but for design! It is hard to believe that it was “close” when this issue was debated. So now we are left with a PKI infrastructure that can’t be used without a lot of workarounds and a specification that is now missing all the components that it needs to make it work. We have no NASH, no Provider directory, no endpoint location service and to make things worse no compliance program to ensure that the content meets any standards.

The primary reason for this situation appears to be some sort of idealistic view that WS-Security will solve all the issues when in fact it depends on a stack of other services that do not yet exist. In addition to this naive ideology driven utopian view we have seen no effort to standardise content to actually make sure the payloads work. From what I hear Nehta have a similar outlook to content. On top of this stack of unimplemented services they are going to define all the business rules for health as web services and move to a pure document content. This may well work in one enterprise with a tight talented team and one implementation talking to itself but it will never work in the world that I inhabit of greater than 50 vendors of systems with wide variation in quality and ability.

Over the last 15 years Medical-Objects has implemented a HL7 V2 based SOA stack with HL7 based Provider Directory and Endpoint location service along with Medicare PKI support with automated discovery and connection setup to new practices We have push based real time delivery to clients located behind firewalls (SOAP and REST). We have implemented all the services required and have an in depth knowledge of what is required to achieve this. Any system like this will not scale without a working NASH equivalent and an Endpoint location service linked to a provider directory. The HL7 V2 content can easily support CDA based documents and any other data requirements that people may want.  The Nehta plans could have worked if they had been busy implementing and testing services that scale for the last 5 years, but it is clear that is not the case. We are still many years away from that point. We could implement SMD, but configuring it manually would make such a service impossible to scale as it lacks all the required services to automate it.

Despite their own failures they appear the think that the barrier to inter-operability is the messaging providers! The messaging providers that deliver clinical documents know that the major barrier to interoperability and the lack of content standards compliance and the resulting lack of reliability of endpoint interoperability. We all try and compensate for that in different proprietary ways which means that the interconnection of messaging providers ultimately depends on the standards compliance of the content, which is a subject that has been totally ignored, presumably out of ignorance. I suspect that the ignorance reflects the idea that “enterprise solutions” by enterprise focused architects will scale to the internet level, which is simply not the case. The best hope we have to achieve results in Australia is to use the existing Medicare PKI to deliver PKCS-7 secured HL7 V2 messages (which could support CDA documents), where the semantics are in the messages and not the SOAP and content compliance is given its rightful place.  That path is the pragmatic solution that could work, and does work now at a basic level. Surely 10 years of ideology driven failures is enough?  The recommendation to use HL7 V2 to move forward has been made several times but has been blocked by ideologues who knew better. It appears they were wrong.  I guess when you are spending $160,000/day of someone else’s money there is no urgency to produce a working solution! At some point someone needs to accept that our current path is off in the weeds.

Posted in EHR, HL7, MESSAGING, SOAP, STANDARDS | Comments Off

PDF Healthcare – A risk to meaningful use?

We are often faced with organizations wanting to transmit PDF documents. This is superficially attractive as the presentation is usually good and it’s a single file. Is there a problem going down this path?

I think it’s a huge dead end. Australia started eHealth with a local format called PIT which in its day was a great advance, but it is now slowing down adoption of atomic HL7 reports for the simple reason that its presentation abilities, with coloured text and simple yet powerful text formatting commands are better than the equivalent HL7 V2 Free Text format. Users see the PIT reports as superior because of this and to a human reader they are, but there is no atomic data at all. Does human view-ability constitute meaningful use?? I think not. We need atomic data to allow for decision support and most of the future value lies with decision support. While pdf can contain text components most pdfs generated by a variety of Health applications do not.

PDFs I have seen of late are also commonly 5mb in size, which contrasts with a HL7 version of the same report being under 10K. With terabyte hard discs you may say so what… However in my clinical practice we have over 2 million clinical reports and when you multiple 2 million by 5MB you start to see scalability problems appear.

While having a PDF display version of a report is a good option it is unacceptable not to have the same data in atomic format. I want the Clinical decision support engine to be able to know the patients Ejection Fraction is on 30% before the patient is lines up for a colonoscopy as a routine request. PDF echo reports without atomic data prevent this type of activity and lack meaningful use capabilities.

We desperately need some leadership and governance to stop this happening. Every new device on the market appears to output a PDF report and often there is no way to access the raw data. This is not good enough but in the absence of governance this is becoming the norm. It may be a lot harder to export raw data but it’s essential if we are going to “move forward”

PDF risks becoming the new PIT of healthcare, all show and no go, and not meaningful use. Luckily at the moment most PMS systems are quite bad at importing PDF files automatically but this may change.

Posted in DECISION SUPPORT, EHR, HL7, STANDARDS | Comments Off

e-Health in Australia – Time to actually move forward!

Well we have had the election and there is no clear winner but it appears that the Rudd/Gillard government is the loser. eHealth is up for some reassessment and it certainly needs some.

From all reports $5 Billion of taxpayers money has been spent over the last 10 years and we have little to show for it. 10 years is long enough for any reasonable plan to bear fruit and there is clearly some fundamental flaw in the methodology.

The decision to purchase a SNOMED-CT license, and a Certificate Authority  is the only positive I can find. We do have a Secure messaging standard, but it is flawed by the fact that it really depends on Nehta “NASH” service for suitable certificates rather than working with the existing Medicare certificates. (and NASH is vapour ware) Virtually every general practice has Medicare certificates as part of the PIP program and the reason that the secure messaging standard was not designed to work with them lies with the dysfunctional relationship between Nehta and Medicare.

Dysfunctional organisations seem to be at the heart of the matter. We have not had one organisation for 10 years, but about 4 or 5 each of which has been rebadged and restarted only to repeat the same mistakes. That mistake, or the core of it is the idea that they have to “solve” the problem and produce software. Government is hopeless at doing this, indeed most large organisations are hopeless at producing software and large projects tend to fail. What we need is government to provide governance to move the industry forward rather than trying to do the heavy lifting. After 10 years the things that were working at the start are still working and all the things that are working are based on consensus standards. What we need is governance to comply with those standards and progress the standards in an incremental way. Currently we see much talk of Nehta inventing standards and despite some very capable people inside Nehta this is doomed to failure. Standards have to be created by consensus, as then the industry will engage with the painful standards process in order to prevent silly ideas becoming a standard and to fix errors where they occur. They will only engage when they know they have a duty to comply with the standards and this is where the lack of governance is failing us.

The standards process has become orphaned because Nehta have said they will be dictating the path, and they have failed to produce any clear path. More recently they have tried to steam roll standards and this is also likely to fail as without adequate review the standards will be poor.

Out there is the real world, which is the world that Medical-Objects inhabits, we see significant advances in communication with the number one obstacle being poor standards compliance. Because of a lack of governance large vendors feel that they can flout the standard and dictate the formats though sheer market size. Because of a lack of compliance anything that does work is fragile because it is never quite right, but has to be wrong in exactly the right way in order for it to work.

The dreams of the connected health landscape are often formulated by people with no knowledge of the importance of the lower levels. We can connect to the whole world of internet services because of compliance with the invisible things like tcp/ip and http standards and not because some middle manager dreamed of the internet. The dreams of a connected eHealth world rely on applications supporting the creation and consumption of high quality, standards compliant messages and not on the glossy pdfs produced by Nehta.

I don’t think we need Nehta, the states are not the eHealth leaders in this country and Nehta was setup as an uneasy alliance of the states, many of whom ignore Nehta anyway. What we need is good governance and a focus of standards compliance of all the applications that make up the landscape. There does need to be funding of the standards process and there needs to be a mechanism for providers of healthcare to pay to buy standards compliant software, which if built properly, will be more expensive than they are paying now.  However, the money they are saving is working against the big picture of a connected landscape and this is where governance and some well directed funding could make a huge difference. If every health application was required to be standards compliant we would see an enormous spike in interest in the standards process and the consensus process could be resuscitated for its premature death and we could start moving forward one level at a time.

The big bang process has failed, as it was bound to do and we need a return to proven paths. The cost would be a fraction of what was planned and the results, though slow would be much more solid. The tortoise is still in the race, its time to stop trying to follow the scatterbrain hare!

Posted in EHR, HL7, MESSAGING, SNOMED, STANDARDS | Comments Off

HL7 V2 just keeps on keeping on

It is interesting that so many people are keen to rubbish the encoding of HL7 V2 data. “It old and outdated” is a common comment. After a serious amount of time playing with it and experimenting with many encodings I am now convinced its brilliant.

The “xml will solve everything” mantra is fading as people realise its inefficient, and bloated and in my experimentation it works, but really offers few advantages. I use and like JSON and this is a no brainer when working with javascript. I have recently also been playing with erlang term encoding. This is used heavily in some pretty impressive scalable applications.

I have now converted clinical data into all three formats and it has made me realise the absolute brilliance of HL7 V2 encoding. Bloat with xml is a scalability issue, and the DOM structure holds up processing data as a stream, although this is not a serious issue. The human readability aspects of it is a joke. If you are going to process medical data then having it humanly readable is the last priority, especially as humans are so fallible. It is also not backward or forward compatible and no easy mechanisms exist to overcome these issues. In contrast HL7 V2 encoding, when parsed according to the rules, allows  great flexibility. A field can be made repeating, or,  eg. expanded from a simple string (IS) to a coded value with good backward and forward compatibility. The lack of field names is not an issue as the computer knows where the data should be. It reduces bloat significantly.  It is also possible to process the data as a stream as you don’t have to wait for a closing tag. Absent values can just be omitted, further saving space. New values can be appended to the data types or segments without breaking parsers.

JSON is much better than xml, but still bloats because of field names and changing a string into an object causes significant issues. Erlang terms omit the field names, but require absent values to be encoded as blank and are inflexible when new fields are appended, making backward and forward compatibility problematic.

While free of off the shelf parsers are available for the other formats I think this up front advantage quickly fades once the other issues appear. HL7 V2 encoding does at first seem old hat, but it was developed in an age when most people in the industry were computer science gurus as the resources available were so limited, and things had to be efficient to actually run. After actually implementing transforms into the common alternatives and realising that these formats are likely to cause problems when version changes appear I have a new respect for the HL7 V2 encoding. I suspect the critics have not really used it in anger, as it just keeps on keeping on.  xml might be great for a quick and dirty data exchange format where efficiency is not high on the list. Its also essential when astronaut architects are at the helm!  JSON is very efficient talking to a html/javascript front end. However for the core backbone of health messaging that has to cope with multiple version of data and be efficient and not consume vast quantities of disc space I still think that well implemented HL7 V2 is simply brilliant. Despite being the poor cousin of the modern formats, its position as the most used medical messaging format does not surprise me. The tortoise might yet win the race!

Posted in EHR, HL7, MESSAGING, STANDARDS | 1 Comment »

eHealth – What is going wrong?

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.

Posted in EHR, HL7, STANDARDS, Uncategorized | 4 Comments »

eHealth – Where is the duty of care?

After watching the failure of the Government Home Insulation Scheme and the Payroll issues with Queensland Health unfold its clear that the eHealth issues in Australia are part of a much bigger problem.

There is enormous potential for eHealth to cause damage and there is a duty of care to make sure the risks are minimised. Currently the push to roll out parts of the eHealth agenda is just as flawed as the home insulation scheme and the payroll system. We need to get some basic quality controls in place first or the consequences will be worse than what we have seen with these programs. Poor, missing or incorrect patient data  can be just as deadly as Foil insulation in the hands of untrained installers.

Nehta, I am sure, has some great talent in its ranks, but I don’t see anyone with an overall understanding of the issues that face eHealth or how to fix them. They are unwilling to listen to the practical concerns of people with experience and now it seems they are under political pressure to deliver and just like these other rushed programs the risks are very high.

I have multiple levels of concern, but chief amongst them is to try and steamroll connectivity in a physical sense when in a practical sense it is badly broken. The quality of the data being moved is low and very non-compliant with standards and this is well known. There appears to be a block on the idea of a quality program for the messages, despite the machinery to do this at a basic level existing for over 5 years. Applications fall over importing good data and often fail to display it correctly and in many cases can’t support HL7 (Health Level 7) at all. Blindly sending data around, even with shiny New Health Care identifiers is a recipe for disaster.

We need to get some compliance programs going for existing health data and once that is done it is possible to try and move to the next level. No matter how much political pressure you apply computers are very stubborn when the bits and bytes are in the wrong place and will not budge. It seems that politicians NEHTA and the public service are yet to learn this. Failure to do this will expose us to the first big eHealth Train wreck, that is clear.  Large applications are built from components and to make something big work you have to have confidence that the components work reliably, currently they do not. We don’t need radical change, we need an expectation of quality and a requirement for quality, backed with testing. I am sure the underlying intentions of the Home Insulation scheme and a New Payroll for Q Health were sound. They both failed because of a lack of compliance testing on the components.  At the moment Nehta is heading down the same track and the bridge is out just around the bend.

Posted in EHR, STANDARDS | 1 Comment »

NEHTA – On the road to nowhere?

National Health IT programs do not have a good record of success in general, and Australia has been a good example of that to date. I don’t think anything is about to change.

The reasons for this will no doubt be well understood in time, as history looks back and shakes its head in dismay at the wasted resources and opportunities.  Its hard to pinpoint the reasons for failure until you have success to contrast it with. I think a large part of the problem is the top down approach to a problem that can only be solved bottom up. By many measures Australia has been a leader in eHealth to date, but I don’t think any of that can be attributed to government policy or support as its mostly been bottom up. Certainly the National eHealth Programs of the past have failed to progress the situation and have in many ways just distorted the market for the worse.

While some will say the issue is “Change Management”, I think this is wrong. To have change management you need to have a change worth implementing and to date the quality has not been there to justify change. The quality needs to be in the software and eHealth is a complex beast to tame. To progress it we need to have the foundations to build on and currently they are sitting on swamp. Netha appears determined to adopt the tunnel vision of its “Stakeholders” ie. The state health departments and ignore the bigger picture of the international markets and standards bodies. Despite ample evidence that the existing infrastructure is cobbled together and working in the most fragile manner conceivable they want to march on and implement  national programs without any compliance agenda on the horizon for at least 2 years. Building anything on the current infrastructure without a resolute compliance program is a recipe for disaster.

Australia currently has good penetration of HL7 V2  messaging, but the quality is patchy and the interoperability extremely fragile. Any change to messages results in failures and in effect we are locked into a situation where only a few systems can handle compliant data. This is interconnectivity and is a long way from interoperability, its a road to nowhere and in reality the known errors in existing lab messages cannot be corrected because of the fear of breaking existing systems. Despite Australia having compliance testing available there appears to be a complete lack of understanding of its importance by Nehta. Rather than underpin the cracking foundations before trying to renovate the building Nehta is determined to add another 3 stories to the building.  The earthquake in Haiti demonstrated the dangers of a city built without adequate building regulation. Nehta’s plans will result in major loss of life at the first sign of a tremor, even if they manage to build something (which they have failed to do to date).

Interconnectivity without interoperability is a recipe for disaster and this appears to be the agenda. Delivery at all costs appears to be the political motivation and I think its time to reject the short term political goals and try and attack basic compliance and quality now.  The software term “Design by Contract” was never meant to mean a business contract, but a compliance contract. Nehta appears not to get this and wants to substitute “contracts to deliver a business plan” for “contracts to comply with standards”. Computers are quite bad at being politically correct and will reject business plans that lack credibility at the binary level.

The real issue in eHealth is a lack of quality, and subsequently a lack of interoperability and safety. There are fundamental engineering deficiencies in the real world and a lack of realization that only standards, and good compliance with standards can fix the flawed foundations. Foundations are not sexy, but getting the structure out of the ground is always the biggest hurdle on a building project. To improve the situation we need a focus on good software engineering practices and in the world of complex systems that means testing and more testing. The reality is that HL7 V2 is going to be around for many years to come and rather that march on with grand plans the priority needs to be getting a compliance program for existing standards up and running now. Moving to something new is an expensive diversion that will make the problem worse, not better. Someone needs to stand up and stop claiming they will deliver the 10 story masterpiece “next year” and start work on a compliance program for what is already in use. We need some solid foundations or the Haiti style devastation of eHealth will surely descend upon us within a few years.

The Nehta plan, as it stands will deliver fragile single purpose interconnectivity with little or no interoperability. Its time we turned our existing interconnectivity into interoperability by a deliberate compliance agenda. Once thats done we will be out of the ground and ready to do some real work.  As it stands they are on a road to nowhere. We have been down that road and we know where it leads.

Posted in DECISION SUPPORT, EHR, HL7, MESSAGING, STANDARDS | Comments Off