I regularly write about the need to converge CCR and CCD into a common, simple to use, XML construct that incorporates structured and unstructured clinical summary information.
CCD itself would be a good endpoint if the XML were more readable and the overhead of the CDA was reduced. The other option is for CCR to be expanded to include more metadata and support unstructured documents such as discharge summaries and operative notes. The CCR folks have been working on PDF for healthcare to support document capability.
Simpler but full featured is exactly what Green CDA tries to do.
It's a streamlined, human readable and computable lighter version of CDA that includes just the data and metadata necessary to do the job of representing a clinical summary.
Here's an example of the Problems section and Patient data section in Green CDA.
There are tools available to convert green CDA into a full CDA document
There are also tools available to convert CDA into Green CDA
Additional tools are are being developed to enable easy creation of Green CDA constructs by navigating the RIM, selecting attributes, and selecting associations to consolidate to make the XML flatter.
When I first saw the Green CDA XML, I was so impressed that I asked the question - why not use Green CDA as CDA, getting rid of MoodCode, many of the OIDs and other overhead in the CDA?
In the past, the idea was that the CDA was capable of representing any aspect of the medical record for any purpose. That sounds like a noble idea but in practice it creates a fixed overhead for even the simplest data exchange.
Folks at HL7 are working hard on CDA templates, tools for creating CDA documents and simplifying the CDA (and the XML used in CDA).
The Green CDA initiative is a great start. I look forward to watching its development and the industry reaction.
The Interim Final Rule supports both CCR and CCD for 2011, but recommends convergence by 2013. Over the next 24 months, we'll see what convergence of XML standards for structured and unstructured data is technically and politically possible.
Subscribe to:
Post Comments (Atom)
10 comments:
Thanks for the post. I'll add this to my study list with CCD CDA and CCR.
John, is there a working group or collection of documents pertaining to Green CDA? Perusing the HL7 Structures Documents section is yielding nothing.
This is great! It would be nice if all of the coding and conformance information could placed in a separate conformance specification. The use case for encodings changing between elements is small.
It would be good to clarify what "why not use Green CDA as CDA, getting rid of MoodCode, many of the OIDs" etc means to ordinary people.
Eliminating the codes for "Order," "Result," "Plan," or "Recommendation" would seem to be counterproductive to most physicians. These words are needed in order to understand what the data represents.
Eliminating the OIDs that protect the data provenance of a result also seems to be counter-intuitive to physician demands for data reliability.
It is good to make things simple, but throwing out good medical practice in order to make things simple is no service to physicians!
Take this little quiz to see if eliminating OIDS and Mood Code is a good idea:
1. 128 is the code for? A. H1N1 Vaccine B. Tuberculosis of Bones
2. 11237 is the identifier for which patient?
3. What are the differences between:
a. Something that has happened?
b. Something that was requested to happen?
c. Something that should happen?
d. Something that should not happen?
4. What are the similarities between the above?
In an exchange of clinical information, the answers to the first two questions cannot be given without knowledge of at least one other piece of information. In the first case, you need to know the coding system that is being used. In the second case, you need to know who assigned the identifier. You can come up with any number of different solutions to these first two problems, but they will always result in transmitting some sort of identifier between the exchange partners; either before or during the exchange of the clinical information. HL7 prefers OIDs to accomplish this task in part because the OID standard enforces a governance model that not only ensures uniqueness, but also supports publication of these unique identifiers so that others can compute with them.
The second two questions are about depiciting similarities and differences between an occurence that did, should, may or should not occur. In linguistics, these variations are described as the mood or tense of a verb. HL7 uses mood in its modelling to enable the depiction of similar things where the distiction is in whether this is something that should, may, was requested to, did not, or should not occur. The information modeling that presents these things showing their similarities, yet distinguishing between occurence and desirability is an important component of clinical decision support.
I have been teaching CDA for more than 6 years. I have to agree that:
A. OIDs aren't [human] user friendly (that wasn't a key requirement in the implementation of the standard).
B. Mood is a complex concept that needs better explanation for implementers.
That doesn't mean these concepts need to be done away with. They do need to be made easier to understand. Green CDA is a research project intended to explore how to make CDA easier to implement, but it is not at all intended to remove these necessary concepts from the exchange of clinical information, nor is it a "full solution", yet.
For more on Green CDA read: Birthing of a New Standard
My favorite quote when talking about simplifying the CDA:
"Everything should be made as simple as possible, but not simpler." --Albert Einstein
A simpler API for generating, consuming & validating CCD instances is great, but I hope we avoid inventing yet another markup language on the wire. I see value for things like GreenCDA as a layer that sits atop CDA, but doesn't replace it as the underlaying representation.
Yet another markup language wont make my life simpler, but better tools for dealing with CDAs in a 'simpler' way definitely will.
The OHT MDHT CDA Tools project, for instance, is headed in that direction https://mdht.projects.openhealthtools.org/cda/index.html
It is far more important to "meaningful use" that we leverage all of that existing work than it is to force it into any one XML standard.
It is surely a very good idea to have a simplified version of CDA.
The enormous complexity of CDA and of HL7-v3 in general is one of the reasons that their implementation is still very limited: over 95% of the HL7 messages exchanged between hospitals are still in v2.
But more needs to be done.
Although HL7-v3 uses XML, it still refuses to use the basic datatypes of XML. Just as one example, for a birthdate it uses the format yyyymmdd, whereas the base type "date" in XML uses yyyy-mm-dd (ISO8601).
One may think "so what". So let us take the simple example of the birthdate 19410229. Is it a correct date? As CDA (and CCD) have both an XML-Schema and a Schematron, one should be able to validate this date. Although there has not been a February 29th in 1941, the error however remains undetected.
If the basic XML datatype xsd:date however would have been chosen for birthdate, the error would have been detected immediately when validating against the XML-Schema.
The refusal to use basic XML datatypes has further consequences. For example, when comparing two dates (e.g. for determining the duration of a medication), one currently needs to write software. If base type xsd:date was used, calculating the duration can be done using XML itself (e.g. in a stylesheet) as a one-liner.
Also ontologists criticize HL7-v3 for not being sound in its principles (see e.g. http://hl7-watch.blogspot.com). Therefore, more and more voices come up to rethink HL7-v3 and even to skip it and start working on a fully new concipated v4, using sound principles and using existing XML basic principles and datatypes wherever possible. This could also be the right moment to unify CCD, CCR, OpenEHR and other „standards“ for use in electring health records.
A very late comment on the GreenCDA approach.
Simplifying CDA is a great idea, but in my mind green CDA is missing a very important ingredient for sharing semantics and that is a set of logical information models at the core. What this means in effect is that there is a need to create a schema by hand for every CDA that comes along, and then after that, hand code a transform for each green CDA instance as well.
If you have a core set of logical computable, reuseable clinical models then the green CDA schema can be automatically generated. XSL transforms can be built for each reuseable model so that when the next green CDA schema is generated from the models a set of transforms is also already available to turn the XML instance into a full CDA (or any other artefact required!)
This approach was pioneered about 5 years ago in the openEHR environment and there is current tooling to generate XML schemas from document specifications (openEHR templates) based on the models themselves (archetypes). The transformation process to CDA has been used at a number of IHE connectathons in Australia and is in use for integration purposes in many projects around the world.
Post a Comment