PCC HowToWriteCDALevel3Templates

Overview

In order to represent machine processable (or Level 3) data in CDA Release 2.0, an implementation generates entry elements that appear within various section elements of the ClinicalDocument. These entries use the observation, regionOfInterest, observationMedia, substanceAdministration, supply, procedure, encounter, organizer, and act elements found in the CDA Schema.

While CDA implementers can easily create implementations that use (schema) valid CDA representations of the clinical information, these implementations will not easily interoperate with other HL7 Version 3 specifications unless some care is taken in the specification of the CDA XML that results. The main reason for this is that the CDA model is very broad, encompassing, as it must, a wide variety of information requirements covering a large set of domains. Furthermore, the CDA model includes an early version of the Clinical Statement pattern upon which many HL7 Version 3 specifications are based (e.g., Patient Care Structures, Pharmacy, Laboratory). There are some variances between the CDA model and the current Clinical Statement pattern. In addition, each domain is permitted to extend and modify the Clinical Statement pattern to suite the requirements of the domain. This introduces variances between the domain specifications and the CDA. While many of these can be overcome by transformation, the ultimate goal of any implementer is to reduce the amount of work they have to do when transferring information from one source to another.

The purpose of this document is to describe the process has been used within the IHE Patient Care Coordination Technical Committee to produce Level 3 XML representations of structured information that is compatible with the CDA Release 2.0 schema, and which also meets many of the requirements of specific domain models.

This process was developed mostly ad-hoc, over a three day face-to-face IHE PCC Technical Committee meeting. Using it, I and others have been able to successfully produce CDA representations of level 3 information for a variety of data sets, including problems, allergies, and medications.

I would like to thank some Version 3 experts, including Dan Russler and Vassil Peychev, who greatly assisted in this work, and Lawrence McKnight, a soon to be Version 3 expert who provided many of the initial examples that were used in the initial development of the IHE PCC Medications level 3 encoding.

Prerequisites

Obtain a copy of the CDA Normative Edition Web Site. This is essential, as it contains the normative schemas, the CDA Hierarchical Descriptor, and the CDA R-MIM.

Learn how to read an R-MIM. Unfortunately, very few XML examples exist within any given domain for the different messages that need to be transmitted. If this were otherwise, you could start there, but since you cannot, you will need to start with the R-MIM or D-MIM diagrams for the domain.

Understand the HL7 data structures, and the XML Implementation Technology Specification. Without this knowledge, you will not be able to read an R-MIM (see above).

Next, obtain a clinically complete set of examples of the thing that you wish to encode (e.g., various labs, or different kinds of prescriptions, et cetera). Ensure that you have covered common cases (e.g., normal prescriptions), and as many as possible edge cases (e.g., split dosing, tapered dosing, compound medications, et cetera).

If you are a software engineer, have a physician handy, and if a physician, have a software engineer handy. I've found very few people with sufficient skills to do this by themselves.

Next, print out, or have otherwise available, the relevant R-MIM or D-MIM from the HL7 Version 3 domain specification that you wish to use. Do the same for the CDA and Clinical Statement pattern.