A (really) brief History of CDA
For more detail, see Chapter 3 of my book.
What is CDA?
The CDA standard describes how clinical documents can be exchanged in XML. Unlike other standards that I've mentioned thus far, CDA just addresses content, it doesn't say anything about how that content is communicated between systems. Essentially, CDA is a file format, and says nothing about how you can exchange those files between systems. You could use CDs or USB sticks, e-mail, FTP, HTTP, or even more complex methods of exchange with CDA. The CDA standard doesn't require anything about transport. It does include some suggestions for how to use existing HL7 Version 2 messages to exchange CDA. However, those are only suggestions, not what we call normative text in the standard.
How is a CDA Document Organized?
There are three "levels" of information that can be captured in a CDA Document. These are the header, sections, and entries.
The header (level 1) provides information about the the document, including the identify of the document, the kind of document and type of service it documents, who wrote it, what organization maintains it, what patient it was for, what encounter, where the service was provided, by who, and what other documents might be related to it.
The body (also known as the human readable portion) of the document can be some sort of file (we call it multimedia, but you'd simply think of it as a file produced by a word processing application, a scanner, or similar tool). Level 1 CDA documents just include the file (encoded so that it fits into XML) or a pointer to it in addition to the CDA header.
The body of the document can also be structured into sections and subsections, and those sections can be coded (using a vocabulary like LOINC or SNOMED CT). When the body is structured using sections, and those sections are coded, HL7 would call that a Level 2 CDA document.
Finally, machine readable representations of the clinical content in the body can be included in the CDA document in entries found in each section. This is what appears in a Level 3 CDA document.
Implementation Guides on CDA
There are dozens of implementation guides on CDA, some having been written (and completed) before the standard itself was approved. I put together a list two years ago of more than three dozen, and there have been a couple dozen or more written since then.
There are several sources for implementation guides, including HL7, IHE, national and regional programs, multi-national programs such as epSOS.
The three most influential guides in the US are the HL7 Continuity of Care Document (CCD), the HITSP C32 Summary Documents using CCD version 2.5 (C32), and the CDA Consolidation Guide (CCDA). Internationally, the IHE PCC Technical Framework (based on the HL7 CCD also used in the HITSP C32) probably has the broadest adoption, being used in projects like epSOS, France's national program, a China Ministry of Health program, and many others.
The CCD and C32 guides are of great impact now in the US because they are required to be supported under the Meaningful Use 2011 Certification Criteria (also known as Stage 1). Under the 2014 Criteria, the CCDA has been proposed. The CCDA consolidates work across IHE, HITSP and HL7 into a single guide, and is the go forward strategy for HL7, IHE and US programs.
What is a Template?
Templates are a way to express a set of business rules on a document, section or entry found in a CDA document. Templates are used in the previously mentioned implementation guides to describe the rules that each component of the document needs to follow. Templates make it easy to ensure that content in a CDA document can be understood by different systems, and thus ensure that they can understand each other (this is what is meant by the phrase "Semantic Interoperability").
The Continuity of Care Document and HITSP C32
The Continuity of Care Document is an implementation of the ASTM Continuity of Care Record data set using the HL7 CDA format. It consists of 17 different kinds of sections and related entries that can appear within a CDA document, listed below. It is intended to be a snapshot in time of a patients relevant clinical and administrative data. The HITSP C32 is an implementation guide that is built upon the CCD, and is required to be supported for Meaningful Use Stage 1, and must include the sections in bold.
- Advance Directives
- Alerts, Allergies and Adverse Reaction
- Family History
- Functional Status
- Healthcare Providers
- Medical Equipment
- Plan of Care
- Social History
- Vital Signs
The CDA Consolidation Guide
Because there were so many guides from so many different organizations, and these guides were layered over top each other, it became more complicated to implement CDA. The CDA Consolidation Guide addresses that, by combining rules from the various guides in one place. This guide includes rules for creating nine different kinds of documents, and is now being proposed for the next stage of Meaningful Use:
- Continuity of Care Document 1.1
- History and Physical
- Consult Note
- Discharge Summary
- Diagnostic Imaging Report
- Procedure Note
- Operative Note
- Progress Note
- Unstructured Document
The Continuity of Care Document 1.1 is intended to replace the previous version 1.0, and includes several improvements in the content structure. The remaining documents support other kinds of documentation required in clinical care, and include sections similar or the same as those found in the CCD. Any of the first eight documents can be used to summarize the care provided to a patient in a given encounter, depending on the type of care provided and the scope of practice of the provider, so providers are no longer limited to the CCD to exchange clinical information.
The Unstructured Document at the very end of the list explains how to capture any kind of document as a CDA Level 1 document (see How is a CDA Document Organized above). All of the other documents can be recorded at any of the three levels of detail (but Meaningful Use requirements for Stage 2 imply level 3).
The CDA Consolidation Guide is undergoing a minor update right now in HL7 to make a few clarifications and to support recording of functional status. That ballot closes June 4th.