Return to FAQ Home Page
About CDA & CCR (pdf)

CDA FAQ

What is it?
Who is using it?
What type of tools are available?
Is it complicated?
What are CDA "levels"?
What’s the difference between Release 1 & Release 2?
How does it relate to the RIM?
Is it part of V3?
Can I see a sample?
Are there Implementation Guides available?
Where did it come from?
How do I get more information?
How can I get involved?

What is it?

CDA is the Clinical Document Architecture, an ANSI-certified standard from Health Level Seven (HL7.org). Release 1.0 was published in November, 2000 and Release 2.0 will be published with the HL7 2005 Normative Edition.
CDA is specifies the syntax and supplies a framework for specifying the full semantics of a clinical document. It defines a clinical document as having the following six characteristics:
A CDA can contain any type of clinical content. Typical CDA documents would be a Discharge Summary, Imaging Report, Admission & Physical, Pathology Report and so on. CDA is uses XML, although it allows for a non-XML body (pdf, Word, jpg and so on) for simple implementations.

Return to the Top

Who is using it?

CDA is in use world-wide. The most popular use is for inter-enterprise information exchange, such as is envisioned for the US Regional Health Information Organizations (RHIOs). Thus most users are in countries where RHIO-type exchange is well established such as Finland, Greece and Germany and in pilot RHIOs in Canada, Japan, Korea, Mexico, Argentina and elsewhere. CDA is firmly in the plans for many of the nascent US RHIOs and the US Military Health System.

In addition to RHIO usage, CDA is the basis of a good variety of experimental work within academic medical centers and research institutions. Examples of this are the project on CDA note generation with knowledge management and controlled vocabulary at Columbia-Presbyterian in New York, the work on CDA for decision support at Queen Elizabeth II Hospital/Dalhousie University and the Single Source Proof of Concept at Duke Clinical Research Institute.

The largest single producer of CDA documents, however, is the Mayo Clinic, which is producing thousands of CDAs every week and when in full production will reach 50,000 notes/week. Mayo sees CDA as a strategic investment in information that will increase in value over time and which can be reused in multiple applications.

Return to the Top

What type of tools are available?

Many vendors have developed CDA-compliant applications for document generation, management and viewing. Since CDA is implemented in XML (Extensible Markup Language, see w3.org), any XML-capable application can work with CDA. So, for example, any web browser, such as MS Internet Explorer or Firefox can parse a CDA document and using an XSL stylesheet, convert it to HTML for display.  Similarly, any XML-capable repository can manage CDA.

For document generation, implementers have a variety of choices. Several dictation/transcription vendors offer CDA as an output format. Many EHR vendors can produce CDA, typically as a conversion from a native format. In addition, eForms applications have been developed for CDA using readily-available desktop technology. Some implementations use dynamic forms population from distributed sources to pre-populate CDA with existing data.

The only barrier to CDA generation with existing technology is where insufficient information is available at the source for conversion, but to-date, this has not been a problem from either voice-interface or keyboard-entry applications.

Return to the Top

Is it complicated?

CDA introduces the concept of “incremental” semantic interoperability. What this means is that there is a range of complexity allowed within the specification and users must set their own level of compliance. The minimal CDA is a small number of XML-encoded metadata fields (such as provider name, document type, document identifier, and so on) and a body which can be any commonly-used MIME type such as pdf or .doc (Microsoft Word) or even a scanned image file.

While the body of such a document would not be interpretable for applications like decision support, the minimal, standard metadata set and display characteristics mean that such a document could be filed, searched, categorized and retrieved along with more richly-encoded documents. They would all be equally readable at the point of care.

At the high end, CDA documents can be encoded with the full power of the HL7 Reference Information Model (RIM, see below) and controlled vocabulary such as LOINC, SNOMED, ICD, CPT and so on.

Return to the Top

What are CDA "levels"?

CDA "levels" are ways of describing the degree of semantic interoperability of a CDA document.
Digression on "Semantic Interoperability": Full semantic interoperability is when a document can drive an arbitrary process, for example, decision support, even if it wasn’t designed for that application. So a document with full semantic interoperability can be created for one purpose, like a public health report or for transfer of care, but can be interpreted by other applications with the same degree of confidence that a human would use the information.
So, the concept of "levels" applied to CDA means the degree to which a receiver can expect to drive automated processes. A Level One CDA sets no expectations beyond the standard header metadata and human-readability for the body. A Level Two CDA means that the body is in XML and that the sections and sub-sections are coded. A Level Three CDA contains the same expectations as Levels One and Two, plus it contains some coded information within the sections.

While Levels 1-2-3 provide convenient ways to set rough levels of coding compliance, in practice many gradations and refinements are possible and are in use.

Return to the Top

What's the difference between Release 1 & Release 2?

CDA Release 1 (R1) was published in late 2000 and Release 2 (R2) will be published in mid-2005 and will provide an exhaustive list of changes. Most significantly, R2 is updated to the most recent RIM (see below) and adds significant functionality to the CDA body.

The major addition to the CDA body is the clinical statement model which uses RIM structures and controlled vocabulary to permit a much higher level of semantic interoperability. In contrast, R1 was restricted to single coded entries which were not fully expressive.

R1 allowed Levels 1 & 2 (with coded entries); R2 allows Levels 1, 2 and 3 (with clinical statements). While R2 allows greater complexity, it still allows the same low level of encoding as R1 and need not be any more complicated to implement.

Return to the Top

How does it relate to the RIM?

XML tags on their own do not have the precision required for clinical system interoperability. For example, does <provider> mean a person or an organization? Is it the person who created the document, signed it or performed some service?

The XML tags in a CDA document are defined by the HL7 Reference Information Model (RIM) which is based on a variant of Unified Modeling Language (UML) and has been developed by literally hundreds of thousands of hours of collaborative work by practitioners, informaticists, vendors and implementers over the past decade. Each release of CDA is based on the version of the RIM current at the time of the ballot. The CDA specification details the relationship of the documents to the model and contains a refined model (RMIM) which takes RIM classes and further constrains them to define the precise parameters of a clinical document.

Return to the Top

Is it part of V3?

Yes. CDA is based on the RIM (see above), uses the V3 datatypes and methodology. The core of the CDA R2 body for machine processing (semantic interoperability) is the "clinical statement" model which is used across V3.

Return to the Top

Can I see a sample?

Sample documents are published with each ballot and implementation guide. See the "Documents and Presentations" portion of the Structured Documents Technical Committee web page on HL7.org for links to individual sample documents for both R1 and R2 (from HL7.org, go to Technical Committees, select Structured Documents and you'll see the link).

Return to the Top

Are there Implementation Guides available?

Structured Documents TC, in conjunction with Patient Care TC, has introduced two Implementation Guides that have been balloted in the Spring of 2005 as information documents. These are CDA Care Record Summary, Level 1 and CDA Care Record Summary, Level 2. The most recent drafts are available on the SDTC web page. As of May, 2005, they are undergoing revision and will be re-balloted in August.

In addition, many sites have created implementation guides for their own use. See an excellent example from British Columbia, the eMS system in support of transfer of care.

Return to the Top

Where did it come from?

CDA grew out of work that originated outside of HL7 in early 1996 when a group of physicians including Tom Lincoln, John Spinosa, Dan Essin, John Mattison and Bob Dolin began to meet to discuss the potential for structured markup in clinical documents. The earliest draft was called the Kona Architecture and was developed in 1997 after the group had joined HL7. Since that time, many people have worked on it and the basic ideas have been refined and developed along with the HL7 Version 3 framework and the RIM. The original group morphed into the HL7 Structured Documents Technical Committee which is responsible for CDA and other HL7 document types.

Return to the Top

How do I get more information?

The best source is the Structured Documents TC web page on HL7.org: from HL7.org, go to Technical Committees, select Structured Documents. From there, you can download drafts, meeting minutes, documents and presentations and you can also sign up for the SDTC listserv.

Return to the Top

How can I get involved?

Anyone can join the SDTC listserv and use the information on the SDTC web page, and can join SDTC listserv, conference calls and meetings. There are no membership requirements for participation and all are welcome.

Real influence on the shape of CDA comes from participation in the ballot process which is available to HL7 members (and to non-members who pay an administrative fee).

To ask additional questions, add to or correct this FAQ, contact Liora Alschuler or the HL7 Director of Technical Services.

Return to the Top