Difference between revisions of "CDA Implementation Guides"
Calvin Beebe (talk | contribs) |
Calvin Beebe (talk | contribs) |
||
Line 12: | Line 12: | ||
=CDA Implementation Guides= | =CDA Implementation Guides= | ||
− | ==Benefits of | + | 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
Return to master table of contents
Contents
- 1 CDA Overview
- 2 Introduction to CDA Technical Artifacts
- 3 CDA Document Exchange in HL7 Messages
- 4 CDA Implementation Guides
- 4.1 Benefits of Constraining CDA
- 4.2 Structure of CDA Implementation Guides
- 4.3 Templates on CDA
- 4.4 Conformance Statements
- 4.5 Machine Processsable Conformance
- 5 CDA R-MIM
- 6 CDA Hierarchical Description
- 7 CDA XML Implementation
- 8 Appendix
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.
- 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.
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)