Another contribution to the ongoing debate - posted with permission.
The original is here:
http://blog.medical-objects.com.au/?p=81
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 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 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.
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.
Andrew also provides some further useful insights here:
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.
More at the site here:
http://blog.medical-objects.com.au/?p=78
I provide this link since NEHTA has just released a new standards package which some considerable and quite inappropriate pressure is being applied to get approval from Standards Australia volunteers! More evidence of the dysfunctional governance we have in e-Health in OZ.
I don't think NEHTA or DoHA even vaguely understand just how out of their depth they are and how low are their chances of success with their present plans!
Enjoy the holiday reading!
David.
1 comment:
I agree with pretty much everything Andrew says here. In my experience, far too much emphasis is put into HOW to move information around, and not enough attention is paid to WHAT the information is, and WHAT we want to do with it.
In reality, as a clinician I really don't care HOW information gets to my screen, and my experience in implementing systems means that I know it really doesn't matter. Similarly, it really doesn't matter (that much) HOW the data is coded/encoded/represented within a terminology. What matters is that the systems who may be involved in creating and consuming data are aware of how that data is structured and how it is coded, and that I know who created the data that I can see in front of me. There will be some change in (probably) my clinical practice and (definitely) my colleagues', and this is to be expected and must be consistently structured.
Yes, there is an argument that when there is a large scale, integrated system in place, it should use a standardised (canonical) form of messaging. It makes sense to do data transformations once after all. However, this incessant focus upon HOW to do what are fairly trivial things is mindblowing. As we enter (another) new year why can we not have an open forum between DoHA, NEHTA, the various health provider groups, and commercial sector people who actually have some experience in doing this kind of large scale integration?
Just before the New Year I was passed a copy of the "Output Based Specification" for the UK's National Programme for Information Technology. Yes, we know that there were some costly mistakes there. We also know that there are some examples of extremely efficient systems put in place. Having read it all the way through I can readily suggest that this would be a good starting point for our discussions. The scope of the UK work seems to match our aspirations, and there is a reasonable alignment between the work that NEHTA appears to be doing, and portions of the UK specifications (although certainly not all). Along with the UK documents, I was also passed an email which indicates that NEHTA are deliberately steering a path away from the UK work. For what reason I do not know, but this feels like folly.
My New Year's plea - PLEASE can we sit down as a team, not as a "them and us" and talk this out, building on top of previous work and learning from the lessons that have been taken.
David?
Post a Comment