Dr Andrew McIntyre Tell It As It is Again! Great Read But Pretty Sad.

The following was posted late yesterday.

NASH, Lies and Ideologically Driven Architecture

September 25th, 2010 andrew

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.

----- End Post.

The post is found here:

http://blog.medical-objects.com.au/?p=73

For those who have even a basic understanding of the issues raised it is clear that NEHTA’s intransigence has become a major barrier to progress. Again, as I said in a blog yesterday, sorting this out will require a fundamental change to the way e-Health in Australia is governed, led, planned and delivered!

Thanks Andrew!

David.