CDA Implementation Guides

Editing tips and notes

Return to master table of contents

1 CDA Overview

(content on separate page)

2 Introduction to CDA Technical Artifacts

(content on separate page)

3 CDA Document Exchange in HL7 Messages

(content on separate page)

4 CDA Implementation Guides

The Clinical Document Architecture defines a single logical schema, which may be used to instantiate any clinical document for exchange. CDA can be used, by itself, to create such documents, which then can be shared and read by recipients with no problem. However the true utility of CDA to improve interoperability, is only realized when the base CDA standard is further constrained to define specific types of documents and their associated processable clinical statements.

4.1 Benefits of Constraining CDA

There are a number of benefits which can be derived from constraining CDA documents.

1. Specific types of documents can be defined, instantiated, exchanged and used (E.g. Consult Note, Procedure Note, Continuity of Care Document, ...)
2. Required and optional sections of a clinical document can be identified (E.g. Reason for Visit, Family History, ...)
3. Realm specific constraints and conventions can be identified (E.g. US Realm Header, US Address and Patient Naming, ...)
4. Required and optional entries (machine processable content) can be identified (E.g. Medication Entries, Problem Entries, ...)

In addition to serving as a useful guides for implementers or creators of CDA documents, CDA Implementation Guides with their associated templates can:

1. Be used to improve consistentcy across documents, by reusing sections and clinical statement models from previously IGs.
2. Be used to create new document types, by using reusable sections and clinical statement models form previously defined IGs.
3. Be used to validate document instance conformance to constants and best practices (Machine Processable Conformance Testing)
4. Be used by receivers to aid in their processing of complex clinical content, there by improving semantic interoperability.

The Architecture of CDA is demonstrated in the system of reusable constraint models (templates) which have been created, used and reused in various CDA Implementation Guides. Implementation Guides define the constraints or expected additional conformance rules to be applied to document instances beyond those already defined within the CDA standard itself. As such every CDA document expressing conformance to a CDA Implementation Guides is still a CDA document, it simply asserts additional conformance to the constraints defined within an Implementation Guide.

4.2 Structure of CDA Implementation Guides

A CDA Implementation Guide is used package up the set of constraints defined for specific set of CDA document types. Some implementation Guides are for a single document types, while others are used to define sets of documents that share common features or use cases. Over time, an evolving structure has been established for CDA Implementation Guides.

CDA Implementation Guides generally contain:

1. Introduction
2. Additional background information
3. Shared Templates (Header)
4. Listing of Document Templates
5. Listing of Section Templates
6. Listing of Entry Templates
7. Shared Templates (Address, Name conventions, etc.)
8. Listing of all Templates
9. Listing of all Value Sets
10. Appendixes

As can be seen, there are many kinds of templates that might be created. Among them, the most common are:

•  Document-level templates: These templates constrain fields in the CDA header, and define containment relationships to CDA sections. For example, a History and Physical document-level template might require that the patient’s name be present, and that the document contain a Physical Exam section.
•  Section-level templates: These templates constrain fields in the CDA section, and define containment relationships to CDA entries. For example, a Physical Exam section-level template might require that the section/code be fixed to a particular LOINC code, and that the section contains a Systolic Blood Pressure observation.
• Entry-level templates: These templates constrain the CDA clinical statement model in accordance with real-world observations and acts. For example, a Systolic Blood Pressure entry-level template defines how the CDA Observation class is constrained (how to populate observation/code, how to populate observation/value, etc.) to represent the notion of a systolic blood pressure.
•  Other templates: Templates that exist to establish a set of constraints that are reused in the CDA document. These other templates are only used within another template, rather than on their own as a complete clinical statement. For example, US Realm Date and Time (DTM.US.FIELDED) includes a set of common constraints for recording time. This template is referenced several times with other templates used in the implementation guide. They reduce the need to repeat constraints in templates that use the common set.

A CDA implementation guide includes references to those template versions that are applicable.

5 CDA R-MIM

(content on separate page)

6 CDA Hierarchical Description

(content on separate page)

7 CDA XML Implementation

(content on separate page)

8 Appendix

(content on separate page)