GreenCDA is a general approach for using an intermediate use-case specific representation to make it easier to produce fully conformant CDA documents. As well as defining this general concept, the greenCDA specification lays down a general examplar of this approach using an intermediate modular XML form with accompanying schemas loosely based on the existing CDA implementation guide.
GreenCDA is a useful way to go about implementing CDA – it makes it easier than writing a straight CDA for an implementer who is not familiar with CDA, and who has one specific use case for producing CDA. There are many variant strategies already in production using a variety of XML or object based technologies that could be described as greenCDA using this technique, since it just makes obvious sense.
However the amount of effort it saves is roughly proportional to the degree to which the use case is fully defined. Let’s take, as an example, the CCD specification. It says (picking a random example):
CONF-145: A problem act (templateId 2.16.840.1.113818.104.22.168.27) SHALL be represented with Act.
CONF-146: The value for “Act / @classCode” in a problem act SHALL be “ACT” 2.16.840.1.113883.5.6 ActClass STATIC.
CONF-147: The value for “Act / @moodCode” in a problem act SHALL be “EVN” 2.16.840.1.113883.5.1001 ActMood STATIC.
CONF-148: A problem act SHALL contain at least one Act / id.
CONF-149: The value for “Act / code / @NullFlavor” in a problem act SHALL be “NA” “Not applicable” 2.16.840.1.113883.5.1008 NullFlavor STATIC.
CONF-150: A problem act MAY contain exactly one Act / effectiveTime, to indicate the timing of the concern (e.g. the interval of time for which the problem is a concern).
Given this information, we can start simplifying the CDA model – dropping the reviled classCode, moodCode, and nullFlavor attributes, since their values are fixed, and renaming the act to “problemAct” – which is much more recognizable. And so forth. Maybe we restrict effective time to TimingConcern : IVL_TS. Maybe. But this is much simpler for implementers. But when the CCD specification says this:
CONF-153: The target of a problem act with Act / entryRelationship / @typeCode=”SUBJ” SHOULD be a problem observation (in the Problem section) or alert observation (in the Alert section, see section 3.8 Alerts), but MAY be some other clinical statement.
well, that’s not so useful. There’s nothing you can do to simplify that, unless you make some new rules about what the clinical statement referred to can say, but this would become more specific than the CCD specification – could only be used in fewer circumstances.
In general, greenCDA allows you to trade between usability and re-usability. The more different kinds of CDA you produce (i.e. the more use cases you support), the less useful greenCDA will be, as it will start fractionating your code. For this reason, greenCDA is not a long term solution to making CDA easy to use (and we are starting to consider other strategies for CDA R3).
The next question that arises is when it would be a good idea to actually exchange greenCDA between trading partners instead of exchanging real CDA documents. This is a hotly debated topic in the community at the moment. At present, the official statement is that we are awaiting more implementation experience before making a formal decision, and the debate in the Structured Documents Committee this week only confirmed that we need to await more practical experience between making a decision.
The problem is that ONC might make its own decision – in fact, probably will – before HL7 is in a position to make one based on experience. So what factors are inputs into the question of whether to use greenCDA forms on the wire?
- GreenCDA is a mechanism to produce CDA documents. Although the transforms are potentially applicable in reverse, there’s no way to be sure that clinically important information isn’t lost in the transform. The greenCDA specification itself comments about this. If you exchange the greenCDA form, you can be sure that nothing is being lost in the transform. I think this is the strongest reason to exchange greenCDAs – to make it clinically safe to use the simplified form for reading too
- You need substantial control over the community to make this work (and a narrow use case, as discussed above). Since the wire form is use case specific, the document cannot be shared with users that don’t implement that particular use case. But there are communities where the infrastructure to do this is already in place. (in a variation to this, the community may provide a perimeter agent that transforms the greenCDA to full CDA for sharing with the wider community, such as a national EHR system)
- It’s evident that the interest in using greenCDA formats is associated directly with use of CDA as a message alternative. CDA is first a document, with author and receiver responsibilities around attesting the *narrative* and displaying it properly. It’s evident that greenCDA exchange is data-centric, not narrative centric. Yet greenCDA is logically considered “CDA exchange” – just a different form. So a community should only agree to exchange CDA if the *document*ish nature of the exchange is well understood and described as part of the agreement. This is important because the nominated author of the document is on the hook for the attested narrative, but this may *never* be built, or built much later. implementation convenience cannot trump clinical safety.
- There’s a portion of the HL7 community who believe that is important for HL7 to protect users from themselves. These stakeholders naturally hold that user communities cannot be trusted to make appropriate judgements concerning the risks and benefits of greenCDA, so we (HL7) should not allow them to use it at all. Supporting this is the fact that in the few cases I’ve seen, the document aspects of greenCDA trading agreements have been left unsaid. This is where the hotly contested part of the debate arises – to what degree is HL7 responsible for protecting users from misusing its standards (and to what degree can we). It’s not a subject for me to resolve here, but my personal opinion is there’s no reason to make a ruling in this case.
- You have to real sure of your use case to be sure about making the right trade-off between use and re-use. of course, as Doug Fridsma says often, the only way to find out whether you’ve got it right is to try it out and see what happens.
Here’s to trying things out 😉