CDA, or Clinical Document Architecture, is the document standard defined by HL7 as part of its version 3, which is used to exchange information between healthcare providers' electronic health records (EHRs). The new requirements mandate EHR implementation as part of qualifying for federal meaningful use payments.
CDA implementations are still in their infancy, even though at the recent Integrating the Healthcare Enterprise (IHE) Connectathon, there were literally hundreds of those documents exchanged and properly "consumed." Consuming a document means that the information is presented properly and added to the appropriate record in the database. For example, a list of medications in the physician electronic medical record (EMR) is properly updated based on a discharge document from an emergency room visit.
A CDA document exchange is quite different than using an HL7 version 2 message, which, for example, is used for the information exchange between a computerized physician order-entry (CPOE) system and a department scheduler to request an order. Another example would be when a reporting system and an EMR exchange a diagnostic report or exchange a lab result message between an external lab and an EHR. Before going into more details about the differences, let's explain a little bit more about CDA.
There are many CDA "flavors," depending on their use. Each type of CDA is identified by a well-defined and constrained template, which defines what information is required in a particular application. A good example of such a constrained template is the CCD, or continuity of care document, which is required by the U.S. government to exchange information in order to qualify for meaningful use payments. This document contains sections about allergies, medications, problems, and laboratory results, in addition to patient demographic information.
Why do healthcare imaging and information professionals need to know about CDA? Well, CDA is going to be the main "transport" mechanism for clinical information between different systems, especially when these are from different vendors and belong to different healthcare providers or parties. These CDA documents provide a snapshot of a particular event, treatment, or episode of care.
For example, a patient might be admitted to an emergency department. Instead of needing to fill in those long questionnaires, the patient might use a personal health record, or PHR, which has information about his or her medical history, including current medications and allergic reactions, with all of the current demographic information.
It takes a simple authorization for access by the patient, and all of the information can be exchanged between the PHR and EHR used in the emergency room by using the Exchange of Personal Health Record Content (XPHR) CDA document. Lab tests from an external lab can be exchanged with a CDA lab report, and the discharge information can be exchanged with the physician EMR using the CDA emergency department report.
This is only a small snapshot; there are many more CDA templates defined, and there is a lot of work being done right now to develop implementation guides that specify exactly how to encode the information that can be exchanged between providers and health information exchanges (HIEs).
An important difference between a CDA and HL7 version 2 transaction is CDA encoding. A CDA document has to contain human-readable information and is encoded using XML, while a version 2 transaction has the conventional delimited encoding, which is very compact but lacks interoperability features.
The main difference is the scope of application. HL7 version 2 transactions are "snippets" that exchange information piecemeal for a certain purpose, such as a report, mainly between systems that are tightly coupled. The CDA is mainly used for external communication between disparate systems and contains an episode of care.
It is therefore obvious that both CDAs and HL7 version 2 messaging will continue to coexist. As a matter of fact, changing the pragmatic and proven HL7 messaging to become CDA-like by using the HL7 version 3 XML-based encoding would choke the infrastructure, as some early implementers have learned to their chagrin.
In conclusion, CDA is here to stay; it is quite different from HL7 version 2, with its own field of application; and as healthcare information professionals, it is important to learn about its structure. There is a short video that goes into a little bit more detail about the CDA, its use, and the preferred way to learn about the CDA.