CDA Background - Revision history

Gcangioli: /* Templated CDA */

2017-10-09T14:52:28Z

‎Templated CDA

Rhausam: /* Templated CDA */

2017-07-30T16:52:21Z

‎Templated CDA

Admin: /* Template versioning */

2017-07-24T14:51:04Z

‎Template versioning

Cchronaki: /* Template versioning */

2017-07-24T10:02:26Z

‎Template versioning

Admin: /* Template versioning */

2017-07-23T19:58:20Z

‎Template versioning

Admin: Created page with "==What is a CDA== CDA R2 is "… a document markup standard that specifies the structure and semantics of ''clinical documents'' for the purpose of exchange” [CDA R2, Sectio..."

2017-07-22T15:06:02Z

Created page with "==What is a CDA== CDA R2 is "… a document markup standard that specifies the structure and semantics of ''clinical documents'' for the purpose of exchange” [CDA R2, Sectio..."

New page

==What is a CDA==
CDA R2 is "… a document markup standard that specifies the structure and semantics of ''clinical documents'' for the purpose of exchange” [CDA R2, Section 1.1]. Clinical documents, according to CDA, have the following characteristics:
*Persistence
*Stewardship
*Potential for authentication
*Context
*Wholeness
*Human readability
CDA defines a header for classification and management and a document body that carries the clinical record. While the header metadata are prescriptive and designed for consistency across all instances, the body is highly generic, leaving the designation of semantic requirements to implementation.

==Templated CDA==
CDA R2 can be constrained by mechanisms defined in the “Refinement and Localization” section of the HL7 Version 3 Interoperability Standards. The mechanism most commonly used to constrain CDA is referred to as “templated CDA”. This specification created a set of artefacts containing modular CDA templates (and associated value sets) for the purpose of the International Patient Summary, and the templates can be reused across any number of CDA document types.

There are different kinds of templates that might be created. Among them, the most common are:
*CDA '''Document Level Templates''' constrain fields in the Clinical Document Architecture (CDA) header, and define containment relationships to CDA sections.<br/>''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.''
*CDA '''Header Level Templates''' constrain fields for parts of the CDA header, like the patient (record target), the author, participations or the service event.
*CDA '''Section Level Templates''' constrain fields in the CDA section, and define containment relationships to CDA entries.<br/>''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 contain a Systolic Blood Pressure observation.''
*CDA '''Entry Level Templates''' constrain the CDA clinical statement model in accordance with real world observations and acts.<br/>''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.''

==Open and Closed Templates==
Open templates permit anything to be done in the underlying standard that is not explicitly prohibited. This allows templates to be built up over time that extend and go beyond the original use cases for which they were originally designed.

Closed templates only permit what has been defined in the template, and do not permit anything beyond that. There are good reasons to use closed templates, sometimes having to do with local policy. For example, in communicating information from a healthcare provider to an insurance company, some information may need to be omitted to ensure patient privacy laws are followed.
Most templates developed for CDA are of the open sort.

==Template versioning==
Template versioning is needed to enable template designs to evolve over time.

Template versioning enables template designers to control and shape the conformances that make up a template’s design over time tailoring the design to fit the template’s intended purpose.

Each template version is associated with a particular template. The template – as a whole – has a mandatory globally unique, non-semantic, identifier. The identifier serves as the identifier of the original intent of the template and as the identifier of the set of versions that represent the template over time.

Template versions have a mandatory timestamp (date and optional time), called the “effective date”. The date can be seen as the point in time when the template version “came into being”, i.e. was recognized as existent by the governance group. Use of the template prior to this date would be considered an invalid use of the template.

For further information on Templates, Template Versions and related topics refer to the HL7 Templates Standard<ref>HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1</ref>.

← Older revision		Revision as of 14:51, 24 July 2017
Line 33:		Line 33:
	Template versions have a mandatory timestamp (date and optional time), called the “effective date”. The date can be seen as the point in time when the template version “came into being”, i.e. was recognized as existent by the governance group. Use of the template prior to this date would be considered an invalid use of the template.		Template versions have a mandatory timestamp (date and optional time), called the “effective date”. The date can be seen as the point in time when the template version “came into being”, i.e. was recognized as existent by the governance group. Use of the template prior to this date would be considered an invalid use of the template.

−	For further information on Templates, Template Versions and related topics refer to the HL7 Templates Standard<ref name="teits"~~>HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1<~~/~~ref~~>.	+	For further information on Templates, Template Versions and related topics refer to the HL7 Templates Standard<ref name="teits"/>.

← Older revision		Revision as of 19:58, 23 July 2017
Line 33:		Line 33:
	Template versions have a mandatory timestamp (date and optional time), called the “effective date”. The date can be seen as the point in time when the template version “came into being”, i.e. was recognized as existent by the governance group. Use of the template prior to this date would be considered an invalid use of the template.		Template versions have a mandatory timestamp (date and optional time), called the “effective date”. The date can be seen as the point in time when the template version “came into being”, i.e. was recognized as existent by the governance group. Use of the template prior to this date would be considered an invalid use of the template.

−	For further information on Templates, Template Versions and related topics refer to the HL7 Templates Standard<ref>HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1</ref>.	+	For further information on Templates, Template Versions and related topics refer to the HL7 Templates Standard<ref name="teits">HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1</ref>.

@@ Line 12: / Line 12: @@
 CDA R2 can be constrained by mechanisms defined in the “Refinement and Localization” section of the HL7 Version 3 Interoperability Standards. The mechanism most commonly used to constrain CDA is referred to as “templated CDA”. This specification created a set of artifacts containing modular CDA templates (and associated value sets) for the purpose of the International Patient Summary, and the templates can be reused across any number of CDA document types.
-There are different kinds of templates that might be created. Among them, the most common are:
+There are different kinds of templates that might be created. Among them, the most common ones are:
 *CDA '''Document Level Templates''' constrain fields in the Clinical Document Architecture (CDA) header, and define containment relationships to CDA sections.<br/>''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.''
 *CDA '''Header Level Templates''' constrain fields for parts of the CDA header, like the patient (record target), the author, participations or the service event.

@@ Line 10: / Line 10: @@
 ==Templated CDA==
-CDA R2 can be constrained by mechanisms defined in the “Refinement and Localization” section of the HL7 Version 3 Interoperability Standards. The mechanism most commonly used to constrain CDA is referred to as “templated CDA”. This specification created a set of artefacts containing modular CDA templates (and associated value sets) for the purpose of the International Patient Summary, and the templates can be reused across any number of CDA document types.
+CDA R2 can be constrained by mechanisms defined in the “Refinement and Localization” section of the HL7 Version 3 Interoperability Standards. The mechanism most commonly used to constrain CDA is referred to as “templated CDA”. This specification created a set of artifacts containing modular CDA templates (and associated value sets) for the purpose of the International Patient Summary, and the templates can be reused across any number of CDA document types.
 There are different kinds of templates that might be created. Among them, the most common are:

@@ Line 27: / Line 27: @@
 Template versioning is needed to enable template designs to evolve over time.
-Template versioning enables template designers to control and shape the conformances that make up a template’s design over time tailoring the design to fit the template’s intended purpose.
+Template versioning enables template designers to control and shape the conformance statements that make up a template’s design over time tailoring the design to fit the template’s intended purpose.
 Each template version is associated with a particular template. The template – as a whole – has a mandatory globally unique, non-semantic, identifier. The identifier serves as the identifier of the original intent of the template and as the identifier of the set of versions that represent the template over time.