CDA, or Clinical Document Architecture, is the document
standard defined by HL7 as part of its version 3, whichis used to exchange
information between healthcare providers’ electronic health records. It is
mandated by the new requirements to implement an Electronic Health Record (EHR)
aka MU or Meaningful Use.
CDA implementations are still in their infancy, even though
at the recent 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 EMR is
properly updated based on a discharge document from an ER visit.
A CDA document exchange is quite different than using a HL7
version 2 message which, for example, is used for the information exchange
between a CPOE system and a department scheduler to request an order. Another
example would be when a reporting system and a EMR exchange a diagnostic
report, or exchange a lab result message between an external lab and a 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 US government to exchange information in order to qualify
for Meaningful Use grants. 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, the CDA is going to be the main “payload” mechanism for
clinical information exchange 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 ER. Instead of
needing to fill in those long questionnaires, the patient might use a personal
health record or PHR, which has information about his medical history including
current medications and allergic reactions, with all of his 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 Electronic Health Record
used in the ER by using the Exchange of Personal Health Record
Content or 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 ED 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 in detail, what and how to exactly encode
the information that can be exchanged between providers and Health Information
Exchanges or HIE’s.
An important difference between a CDA and HL7 version 2
transactions 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 piece-meal 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
CDA’s and HL7 version 2 messaging will continue to co-exist. As a matter of
fact, if you would change the pragmatic and proven HL7 messaging to become CDA
“like” by using the HL7 version 3 XML based encoding, you 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 available that goes into a little
bit more detail about the CDA, its use, and the preferred way to learn about
the CDA. There is also a good resource page available.
