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

Contain:

1. Introduction
2. Additional background information
3. Shared Constraints (Header, Address, Naming conventions, etc.)
4. Listing of Document Type(s)
   1. Document Template Identifier
   2. Context of Use
   3. Document Description
   4. Constraint Overview
   5. Conformance Statements
   6. Value Set(s) referenced
   7. Sample(s)
5. Listing of Sections
   1. Section Template Identifier
   2. Context of use
   3. Section Description
   4. Constrain Overview
   5. Conformance Statements
   6. Value Set(s) referenced
   7. Sample(s)
6. Listing of Entries
   1. Entry Template Identifier
   2. Context of use
   3. Entry Description
   4. Constrain Overview
   5. Conformance Statements
   6. Value Set(s) referenced
   7. Sample(s)

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)