Difference between revisions of "CDA Implementation Guides"

From HL7 Publishing Wiki
Jump to navigation Jump to search
Line 12: Line 12:
 
=CDA Implementation Guides=
 
=CDA Implementation Guides=
  
==Benefits of Creating a CDA IG==
+
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. 
 +
 +
==Benefits of Constraining CDA==
 +
 
 +
There are a number of benefits which can be derived from constraining CDA documents.
 +
# Specific types of documents can be defined, instantiated, exchanged and used (E.g. Consult Note, Procedure Note, Continuity of Care Document, ...)
 +
# Required and optional sections of a clinical document can be identified  (E.g. Reason for Visit, Family History, ...)
 +
# Realm specific constraints and conventions can be identified  (E.g. US Realm Header, US Address and Patient Naming, ...)
 +
# 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:
 +
# Be used to establish reusable sections and clinical statement models for new document types.
 +
# Be used to validate conformance to specified constants and best practices (Machine Processable Conformance Testing)
 +
# Be used by receivers to aid in their processing of complex clinical content, there by improving semantic interoperability.
  
 
==Structure of CDA Implementation Guides==
 
==Structure of CDA Implementation Guides==

Revision as of 18:42, 22 January 2017

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 establish reusable sections and clinical statement models for new document types.
  2. Be used to validate conformance to specified constants and best practices (Machine Processable Conformance Testing)
  3. Be used by receivers to aid in their processing of complex clinical content, there by improving semantic interoperability.

4.2 Structure of CDA Implementation Guides

4.3 Templates on CDA

4.3.1 Template Identifiers

4.3.2 Template Versioning

4.3.3 Open and Closed Templates

4.4 Conformance Statements

4.4.1 Conformance Verbs (Keywords)

4.4.2 Cardinality Constraints

4.4.2.1 Optional and Required with Cardinality

4.4.3 Containment Relationships

4.4.4 Data Types

4.4.5 Vocabulary Binding

4.4.5.1 Code Binding

4.4.5.2 ValueSet Binding

4.4.5.3 Concept Domain Binding

4.4.6 Readable Conformance

4.4.6.1 Tabular Conformance Statements

4.4.6.2 Narrative Conformance Statements

4.5 Machine Processsable Conformance

4.5.1 Benefits of Processable Conformance

4.5.2 Machine Processable Strategies

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)