There's a phrase used in standards development that talks about backwards compatibility. A standard is said to be backwards compatible when it enables all features of the previous version to be represented in the new version. This ensured that there would be a smooth transition from one version of the standard to the next because it ensures that functionality is maintained across versions. But it is insufficient to allow for bilateral asynchronous cut-over. To do that, we need to design for foward compatibility.
Templated CDA goes a step further because there are ways to develop standards that ensure that:
- Systems expecting content formatted according to a new version of the standard can layer functionality to downgrade gracefully upon receipt of content formatted according to the old version.
- Systems expecting content formatted according to the old version of the standard can understand what to do upon receipt of content formatted according to the new version.
Each template identifier asserted by a component of a CDA document is immutable with respect to compatibility breaking changes, by agreement of HL7 Workgroups. I expect this principal will be formalized in the next version of the HL7 Templates standard. It is one that has been followed routinely for the past half-decade by HL7, IHE, HITSP, epSOS and other organizations developing templates for CDA and HL7 Version 3 messages.
This has some challenges, because if you make a compatibility breaking change in template X producing X.1, and template Y requires X, and template Z requires Y, then you must also change the identifiers of templates Y and Z to enforce the use of X.1 instead of X.
To give a concrete example, CCDA presently says that an Allergy template may contain a severity template. Let us suppose that healthcare has advanced to the point that we are ready to say that severity SHALL be provided with all allergies. At that point, we want to say that the Allergy section requires the new allergy template with the required severity, and so this becomes a "compatibility-breaking" requirement on the old section, and so must also be assigned a new identifier. And any document that wants to require that new section also breaks backward compatibilty, and so requires a new identifier.
But a system that understands the old allergy template should also be able to understand the new one. And it will also be able to understand the new section and the new document template. The problem is that it was never designed to know about these new templates. And so we must tell it that the content it receives also conforms to the older template structure. We would do that by asserting conformance to both the old and the new templates.
One would hope that we could take advantage of this notion of forward compatibility as much as possible in all future development of CDA templates, as it provides a mechanism to allow for bilateral asynchronous cutover that Wes and I would both find desirable. You'll note that these principles are already enabled via the incremental interoperability that HITSP and IHE used by layering new templates over existing HL7 templates providing varying degrees of interoperability.
I'll note that this mechanism does not address is the situation we are in today with regard to HITSP C32 Version 2.5 and its use of CCD 1.0, vs. the Consolidated CDA description of CCD 1.1. In that case, we can apply forwards compatibility in most, but not all cases. Due to limitations in existing care provision models at the time that CCD 1.0 was created, and their current state when CCD 1.1 was created, there are some templates that just aren't compatible between versions. There are transforms that can be applied to enable compatibility for many of the exception cases (I won't say all yet, because I haven't finished my analysis). I'll address how to do that when I get more time to focus on my Changing from HITSP C32 Version 2.5 to Consolidated CDA post.
In future versions of the Consolidated CDA guide, I expect similar situations to be quite rarely encountered, and so HL7 should be able to ensure forward compatibility in subsequent editions with little challenges.
On a final note, at the very least, when receiving a CDA, even one which an application doesn't know to interpret, every application should be able to display it. That provides at least a base level of interoperability between systems that should be present with just about every CDA implementation.
-- Keith
P.S. You'll note that I have yet to catch on to using the acronym CCDA for Consolidated CDA, but I recently noted that it does put the CCD back together with CDA, and so maybe I will adopt it. I just don't know how I feel about that yet. What do you think?
Thanks Keith,
ReplyDeleteI agree it's important to design for both forward and backward compatibility for CDA as well as for HL7 messages that Wes wrote about.
Re your P.S. on "CCDA" as an acronym, some have been using "C-CDA" which I prefer in writing, because "CCDA" initially looks a lot like "CCD" and might be interpreted to mean "CCD Advanced" or something like that. Adding the hyphen is a little clearer, IMHO. Nevertheless, "C-CDA" and "CCDA" would both be pronounced the same when spoken.