Wes Rishel

A member of the Gartner Blog Network

Wes Rishel
VP Distinguished Analyst
12 years at Gartner
45 years IT industry

Wes Rishel is a vice president and distinguished analyst in Gartner's healthcare provider research practice. He covers electronic medical records, interoperability, health information exchanges and the underlying technologies of healthcare IT, including application integration and standards. Read Full Bio

Coverage Areas:

A New Approach to Clinical Interop in Stage 2 Meaningful Use

by Wes Rishel  |  March 19, 2012  |  4 Comments

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.

Figure 2 is a screen shot of a partial page of the specification that describes the required and optional sections of the CCD. What do you do about the required section if there are no allergies? That’s easy; the templates that support the section allow you to say why you are not sending any. Perhaps the patient wasn’t asked, perhaps they said no allergies, perhaps they declined to answer. The so-called “flavors of null” represent different reasons for not sending data.
Figure 2. Required and optional sections of the CCD within the CCDA.
The specific document types in this version of the CCDA are:
  • 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.

Each document template is specified in a manner responsive to its individual use cases so they will need different data in the header, different sections and specific entry-level templates. When a consensus group is compiling the templates that compose a document their job is easier if they re-use existing templates rather than creating new ones. To make re-use easier the lines in Figure 1 represent “constraints.” So, for example a Consultation note “SHALL contain exactly one [1..1] componentOf [template which] “SHALL contain exactly one [1..1] encompassingEncounter [template]“.
The CCDA enables consistency without arbitrarily requiring it. This is a critical advantage for developers. When they develop code to relate the contents of specific templates to their database they can reuse the entry-level templates in multiple sections and multiple documents. The section templates help the programmer establish the context of a simple data item in order to know how to represent the data in the developer’s database. The incremental work to program a second document type should be much less than the first. I will come back to this advantage of re-use in the blog that discusses the NPRM.
In addition to enabling consistency the CCDA has several other benefits. The fist is that it includes all the specifications necessary to describe a document type in a single specification. Previously working with the C32 required simultaneously using material from several different documents.
Another major benefit is that it brings the business names for sections and data elements much closer to the surface.

I am very enthusiastic about the CCDA. This is not to say that there may not be reasons to be critical of specific issues, or that we don’t find important issues as this draft goes into trial use. That is the cost of progress. Nonetheless, this is such an improvement over the C32 it is worth celebrating.

4 Comments »

Category: Healthcare Providers Interoperability Uncategorized Vertical Industries     Tags: , , , , , , , , , , , , ,

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.