Supporting CDA in Clinical Applications, Part 1: Introduction

March 1st, 2011 by Mike Stockemer Print Friendly

If you are a software vendor in the healthcare space, it is likely you have interfaces in your systems that are capable of receiving HL7 2.x messages and processing that data into your application.  Application vendors get to pick and choose which message types and triggers they support, as well as how much of the information in the message they want to pull out.

So, just because they may be receiving AL1 segments which contain allergy information, doesn’t mean they will be pulling out those discrete field values and updating their data repository with the information.  Does this still mean they ‘support’ ADT messages?  The answer is typically yes, however there is no requirement to support and process all of the data in a particular message type to claim support for that message type.

This brings us to the Clinical Document Architecture, or CDA.  What does it mean for a clinical application to claim, “Our application supports CDA?”  If we focus on an applications ability to receive and process CDA there are varying levels of support, and each level of support will depend on the CDA document itself.  CDA documents have different levels associated with the level of detail or software process ability which is contained in the document instance.  In general those levels are described as follows:

Level 1: Has required header metadata, and has a human readable body.

Level2: The body is in XML and contains coded sections.

Level 3: Contains the same expectations as Levels One and Two, plus it contains some coded information within the sections.

To claim support for Level 1 CDA, it is logical to expect that an application should be able to parse the metadata in the header.  The metadata can contain information such as the patient’s name, DOB, address and other information such as that created the document and what type of document it is.  An application should be able to extract this information, just like it would an HL7 v2 message, and in some way associate the document with a user in the application.

Additionally, a user should be able to understand the meaning or context in which the document was created.  If the document is a Discharge Summary, this should be clear to the user when they are reviewing the document.  Since CDA documents are encoded as XML, they are easily displayed using style sheets which will extract the pieces of the CDA that are ‘interesting’ and display them as html in a readable format.

Support for a Level 2 instance gets a little trickier.  In Level 2 documents the body of the instance is not just a blob of text, it’s XML.  Within the XML there are individual sections which contain the structured data elements.  The type of data that is contained within a section is defined by a code.

For example, if you are looking at a section in the xml with the following code definition, then you know the data within this section is related to the patient’s immunization history:

This type of coded data allows developers to write applications that can process these sections, and make use of the coded elements.  For example, a user may want to only review documents that contain allergy information for a patient.  Therefore, instead of simply showing all documents for a patient and making the user sift through the list to find what they are looking for, the application can use these coded sections to show the user only documents that contain the needed allergy information.

The real meat of the data in each section is contained in the mandatory element.  This element can contain plain text, or it can be formatted text using a subset of XHTML to create human readable tables, lists, paragraphs, etc.