Common issues found in implementations of the HL7 Clinical Document Architecture (CDA)
The contents of this whitepaper are published under the Creative Commons Attribution-Non-commercial license.
A large number of XML instances of HL7's CDA R2 standard were examined in detail. Two different tools, based on the CDA R2 XML schema and the CDA R2 MIF, were used to identify issues and errors. The issues identified are mainly related to the intent of the CDA standard and to misinterpretations of the underlying data type standard. The paper contains recommendations as to how these issues could have been detected and avoided. The reader is assumed to be familiar with the CDA R2 standard.
1. IntroductionAs part of its work products the HL7 standard development organization created a standard for clinical documents: the Clinical Document Architecture R2 (referred to as "CDA" throughout this paper) . The CDA standard is based on the HL7 version 3 development framework, a framework that is also used to develop messages and services.
Because of the architectural nature of the CDA standard individual implementations are always associated with an implementation guide, i.e. a document that describes how the CDA standard should be implemented in a specific context. The context can mostly be identified by the tuple (document type, organization) where the organization may be a country, a region, a software vendor or a healthcare provider .
2. MethodThe examples as contained in the most inclusive archive of CDA documents  known to the authors were examined. The archive contains CDA examples created in the context of 26 different projects from over 14 different countries. Most of the examples were created as illustrative examples by the authors of the implementation guides. The implementation guides in this archive weren't reviewed given the multitude of languages they were written in.
Three projects were excluded from the review: one (the Canadian eMS) is based on a draft version of CDA R2, and not on CDA R2 itself. For two Italian projects the archive didn't contain any CDA XML instances.
CDA documents may be validated against the W3C XML schema for CDA published by HL7, optionally with the use of a stylesheet to test for document content rules that cannot be expressed using W3C schema.
In addition, conformance to the CDA standard can be tested against the Model Interchange Format (MIF) definition of the CDA model as well as against a derivation thereof: the XML schema. The MIF is an HL7 defined format that describes the full abstract CDA RIM-based object model as created by means of the HDF.
While the MIF can be transformed into XML schema, the XML schema can't fully express the abstract model in the way the MIF can as the XML schema language is too weak to express all of the abstract model requirements as present in the abstract CDA RIM-based model definition. An XML document which validates against the CDA XML-schema is not necessarily a valid CDA document.
Conformance to the CDA specification is best tested using a MIF based validation tool given that the MIF is a full expression of the abstract CDA model. Such a tool also needs to have additional knowledge of the CDA specification, and also other HL7 specifications including the RIM, data type, and structural vocabulary to provide full validation. The examples were examined using a XML schema validator , a MIF based validator  and review of the XML document by means of a generic CDA XML stylesheet.
3. Issues foundThe testing process was limited to the requirements as stated in the CDA specification. Requirements as defined in project specific implementation guides weren't tested.
Implementation guides may specify additional requirements or constraints when it comes to the static model (e.g. expressed as templates, or in the form of constrained coding value sets). They may also specify extensions to the original CDA specification (e.g. when the use of a Realm- or project specific terminology is required).
The requirements specified in a project implementation guide are quite often expressed in the form of XML Schematron rules. These Schematron rules are generally made available in conjunction with the implementation guide. Schematron files, if present in the archive of CDA documents weren't used to validate project specific constraints.
The issues found can be categorized as follows:
3.A Human readabilityThis category of issues is related to the requirement that all relevant clinical content of a CDA document shall be present in human readable form. The issues in this category have an impact on clinical safety and the integrity of the attested content of the document. The following issues were observed:
3.B Text formattingThis category of issues is related to the structure and markup of the textual part of a CDA document. The CDA standard explicitly leaves the rendering of the document up to the receiving application. The standard allows one to structure the text (e.g. using lists and tables) but doesn't contain a real markup language. The following issues were observed:
<b xmlns="http://www.w3.org/1999/xhtml"> <font face="Arial-BoldMT" color="#442422"> <div align="left">Patient N</div> </font> </b>
<content>Three values: Red 100 Blue 130 Green 170 </content>
3.C Textual parts and corresponding entriesThis category of issues is related to the relationship between the textual narrative and the related coded entries. The following issues were observed:
<text>January 24th: The patient ...long text snippet...</text> <entry> <observation classCode="OBS" moodCode="EVN"> <code nullFlavor="UNK"/> <text>The patient ...long text snippet...</text> <effectiveTime value="20080124"/> </observation> </entry>
<text mediaType="text/xml"> Asthme lors de l'enfance<reference value="antmed-2"/> </text>.
3.D Data typesThis category of issues is related to the use of data types in the XML instances. The following issues were observed:
<birthTime value="19730220" xsi:type="IVL_TS"> <width value="33" unit="a"/> </birthTime>
3.E Coding IssuesThis category of issues is related to the use of coded concepts in general, inclusive of the nullFlavor exceptions. The following issues were observed:
<consent> <code nullFlavor="NAV" codeSystem="1.2.7188.8.131.52.1.1.2"> <originalText> Muendliche Einwilligung waehrend Konsultation vom 03.10.2007 </originalText> </code> <statusCode code="completed"/> </consent>
<qualifier> <name codeSystemName="Radiologian toimenpiteen tarkenteet"> <originalText>puolisuus</originalText> </name>
3.F ExtensionsThis category of issues is related to the use of models that extend the CDA instances beyond that which is specified by the CDA standard. HL7 version 3 specifies an informal extension mechanism to extend models. The use of this mechanism implies the use of a different XML namespace for the extensions.
Informal extensions were used by 5 projects/21% of all projects. These were related to the use of Digital Signatures, extensions to the current clinical statement model (e.g. by a financial activity) and the identification of the sending and receiving application.
Two projects used the same XML namespace for the extension model - this is not allowed by the CDA standard.
3.G Element sequencingsThis category of issues is related to the sequencing of XML elements in instances. The HL7 version 3 standard specifies the exact order in which attributes of a RIM class should be present as XML elements in an instance.
The following issues, probably due to serialization issues of an object structure, were observed:
3.H Post publication infrastructural extensionsThis category of issues is related to the versioning issues introduced by the addition of new infrastructural elements after the original publication of the CDA standard. For example: after the publication of the CDA standard the PUB use code was added to the TEL data type.
This leads to versioning issues:
4. FindingsThe required level of validation is related to the level of coding as present in a CDA document. The use of entries adds a level of complexity above and beyond that of the CDA document header and textual sections. With regards to the level of coding: of the examples created as part of one the 23 selected projects:
The most commonly encountered errors are: the use of empty XML elements were nullFlavors should be used, and ill-formed II and coded data types.
5. RecommendationsThe issues identified in this paper could have been avoided:
It seems safe to assume that the more widely available the validation tool, and the better its ability to detect issues, the more it will be used, and the more compliant the CDA instances will be to the standard. This is supported by the fact that 74% of all projects pass XML schema validation, a technology which is readily available. Compare this with the MIF based validator which hasn't been made widely available yet - with a 19% pass-rate.
When it comes to the creation or validation of CDA instances we'd like to recommend the following:
AcknowledgementWe'd like to thank those that contributed examples to the CDA archive  as well as Diego Kaminker and Alexander Henket for their review of this paper.
References R.J.Spronk (Ed.), CDA around the world: archive of CDA instance examples, http://www.ringholm.com/download/CDA_R2_examples.zip, accessed on July 14th, 2008.  HL7 Inc., HL7 version 3 standard, 2008, http://www.hl7.org  Open Health Tooling, Instance Editor v0.9, see http://hl7book.net/index.php?title=Eclipse_Instance_Editor.  Oxygen 8.1, SyncRO Soft Ltd., http://www.oxygenxml.com.
About Ringholm bvRingholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training courses and consulting on healthcare information exchange standards.
See http://www.ringholm.com or call +31 33 7 630 636 for additional information.