Monday, July 8, 2013

Will CDA replace HL7 version 2 messaging?

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.

1 comment: