The certification regulations associated with Meaningful Use Stage 1 (§ 170.205) called for using the HITSP C32 as the specification for the Continuity of Care Document (CCD). The NPRM for Stage 2 points to a different source for specifications, the HL7 Consolidated Clinical Document Architecture (CCDA — officially known as HL7 document CDAR2_IG_IHE_CONSOL_R1_DSTU_2011DEC). HL7 members can download the document from www.hl7.org. This might be interpreted as little but an updated CCD specification. However, the fine print in the regulation belies a very different approach to certification and interoperability in Stage 2.
Both the CCDA and the new regulatory approach have a lot of pluses. In this blog I hope to give a “Sunday supplement” (highly simplified) overview of the CCDA. A future blog will build on this blog to discuss the new regulatory approach.
For those who wan’t an intensive discussion on the technological applicability of the CCDA a highly recommend the classes offered by HL7 and a series of posts by Keith Boone in his Motorcycle Guy blogs.
The Consolidated CDA is one of the finest examples I have seen of of organizing a slew of separate specifications into a coherent and consistent set of specifications. It represents a prodigious amount of work in the HL7 Structured Documents Work Group, many others in HL7, the S&I framework, IHE and the Health Story Project. I suspect that ONC was actively working in the background to push the various organizations to solve intellectual propert and cultural issues that made prior collaboration more difficult.
Previously documents based on the HL7 Clinical Document Architecture were individual specifications developed by different consensus groups. Although the CDA did impose some consistency on all such documents the individual groups often approached the representation of clinical data differently, in terms of the sections of a document and in terms of how individual data items such as vital signs or lab orders were represented.
As illustrated in Figure 1 the CCDA represents revised specifications of 9 major types of documents based on a consistent framework of document sections and representation of different types of structured clinical data. The templates in the box are just what you would expect templates to be, a skeleton for positioning a group of data items inside an XML document. There are big templates (such as the CCD or a discharge summary), “middle-sized” templates (such the header or as one that shows how to organize allergy information) and little templates that represent how specific data elements are represented (such as an allergen or the severity of an allergic reaction).
Figure 1. Conceptual View of CCDA.
- Continuity of Care Document (CCD)/HITSP C32
- Consultation Note
- Diagnostic Imaging Report
- Discharge Summary
- History and Physical (H&P) Note
- Operative Note
- Procedure Note
- Progress Note
- Unstructured Document
However many of these document types describe a variety of different notes based on the specific procedure being described. As these document types were incorporated in the CCDA HL7 uncovered and dealt with potential inconsistencies in their definition, and real-world experience using older definitions. You should regard each document type as the “new and improved” version of prior specifications. A document conformant to the CCDA CCD template will have some differences when compared to one conformant to the HITSP C32 specification.
Category: Healthcare Providers Interoperability Uncategorized Vertical Industries Tags: C32, CCD, CCDA, Consolidated Clinical Document Architecture, Continuity of Care Document, EHR, Health Information Exchange, Health IT, Healthcare Interoperability, Healthcare Providers, HIE, HL7, IHE, Meaningful Use

Wes Rishel







































































































4 responses so far ↓
1 Walter Sujansky March 19, 2012 at 4:02 pm
Wes, great description of a complex and subtle topic. These are the kinds of differences among standards that are often overlooked as unimportant (or inscrutable), but can determine whether a standard is actually useful and usable in practice.
One question: Has the CCDA been pilot tested by distinct enterprises for purposes of
eal world interoperabilty? What have been the experiences of these pilots?
Thanks!
2 Wes Rishel March 19, 2012 at 7:55 pm
Thanks, Walter. To the best of my knowledge there has been no production testing of the CCDA so far; it was only released as a draft standard for trial use in February. However others who are closer to HL7 may say differently.
One of the bugs in maintaining a schedule with deadlines set by law is that there is always a trade-off between using the standard that has been most wrung out or the newer standard that reflects lessons learned in the wringing out.
ONC will have to evaluate the benefits of the new approach vs. the HITSP/C32 for which many developers have heavy investments. I think that the NPRM comments of these developers will be critical to ONC’s decision. The good news is that many of the same developers have been participating in the CCDA development and are in a good position to judge how radical the changes are versus the benefits.
3 Arien Malec March 20, 2012 at 6:18 pm
I’m obviously biased here, but the intent of CCDA was to “fix” many of the Cxx specifications (C83, C32, etc.) by consolidating the documentation across IHE, HITSP, HL7, Health Story, etc.
A few OIDs were harmed in the process, and there are some minor variations here are there (there’s a nice change section in the spec) but the work is mostly a clean up incorporating lessons learned implementing Cxx, not a brand new specifications.
4 Keith Boone March 30, 2012 at 9:37 am
Most of the templates, as Arien observes have already gone through a great deal of testing in their original state. CCDA does make some changes.
There were two demonstrations at HIMSS (I wouldn’t call them pilots) that did involve quite a bit of testing, one involving SEMHIE and another with three other vendors.