Difference between revisions of "CDA Overview"
Calvin Beebe (talk | contribs) |
Astechishin (talk | contribs) |
||
(88 intermediate revisions by 2 users not shown) | |||
Line 5: | Line 5: | ||
= CDA Overview = | = CDA Overview = | ||
== What is the CDA == | == What is the CDA == | ||
− | The HL7 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange. A clinical document is | + | The HL7 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange. A clinical document is documentation of clinical observations and services, with the following characteristics: |
− | * Persistence – A clinical document continues to exist in an unaltered state, for a time period defined by local and regulatory requirements ('''NOTE:''' There is a distinct scope of persistence for a clinical document, independent of the persistence of any XML-encoded CDA document | + | * Persistence – A clinical document continues to exist in an unaltered state, for a time period defined by local and regulatory requirements ('''NOTE:''' There is a distinct scope of persistence for a clinical document, independent of the persistence of any XML-encoded CDA document exchange expression). |
* Stewardship – A clinical document is maintained by an organization entrusted with its care. | * Stewardship – A clinical document is maintained by an organization entrusted with its care. | ||
* Potential for authentication - A clinical document is an assemblage of information that is intended to be legally authenticated. | * Potential for authentication - A clinical document is an assemblage of information that is intended to be legally authenticated. | ||
− | * Context | + | * Context – A clinical document establishes the default context for its contents. |
− | * Wholeness | + | * Wholeness – Authentication of a clinical document applies to the whole and does not apply to portions of the document without the full context of the document. |
* Human readability – A clinical document is human readable. | * Human readability – A clinical document is human readable. | ||
Line 19: | Line 19: | ||
* CDA documents are encoded in Extensible Markup Language (XML). ('''NOTE:''' When alternate implementations are feasible, suitable conformance requirements will be issued so that in future the syntax may not be limited to XML.) | * CDA documents are encoded in Extensible Markup Language (XML). ('''NOTE:''' When alternate implementations are feasible, suitable conformance requirements will be issued so that in future the syntax may not be limited to XML.) | ||
* CDA documents derive their machine processable meaning from the HL7 Reference Information Model (RIM) and use the HL7 Version 3 Data Types Release 1.0. | * CDA documents derive their machine processable meaning from the HL7 Reference Information Model (RIM) and use the HL7 Version 3 Data Types Release 1.0. | ||
− | * The CDA specification is richly expressive and flexible. Document-level, section-level and entry-level templates can be used to constrain the generic CDA specification (see [[#The_.22A.22_in_.22CDA.22|The "A" in "CDA"]] and | + | * The CDA specification is richly expressive and flexible. Document-level, section-level and entry-level templates can be used to constrain the generic CDA specification (see [[#The_.22A.22_in_.22CDA.22|The "A" in "CDA"]] (§ 1.2.2) and [[#CDA_Implementation_Guides| CDA Implementation Guides]] (§ 4)). |
=== Scope of the CDA === | === Scope of the CDA === | ||
− | The scope of the CDA is the standardization of clinical documents for exchange. | + | The scope of the CDA is the standardization of clinical documents for exchange. The concept of "Clinical Document" in the context of CDA is evolving as the use of CDA continues to expand. Clinical documents is meant broadly to cover documents generated not only by clinicians, but also documents generated by patients and caregivers as well as documents generated by payers and other stakeholders who are sharing health-related content. |
The data format of clinical documents outside of the exchange context (e.g., the data format used to store clinical documents) is not addressed in this specification. | The data format of clinical documents outside of the exchange context (e.g., the data format used to store clinical documents) is not addressed in this specification. | ||
− | CDA documents can be transmitted using a variety of techniques, E.g. HL7 2.x messages, V3.0 messages, FHIR messages, Direct and Exchange solutions, etc. While the detailed specification for such messages and solutions are outside of the scope of the CDA, this specification does impose requirements upon the packaging of CDA documents in all of these and other contexts (see [[#CDA_Document_Exchange | CDA Document Exchange]]). | + | CDA documents can be transmitted using a variety of techniques, E.g. HL7 2.x messages, V3.0 messages, FHIR messages, Direct and Exchange solutions, etc. While the detailed specification for such messages and solutions are outside of the scope of the CDA, this specification does impose requirements upon the packaging of CDA documents in all of these and other contexts (see [[#CDA_Document_Exchange| CDA Document Exchange]] (§ 3)). |
− | The CDA does not specify the creation or management of documents, only their exchange markup. While it may be possible to directly use the CDA | + | The CDA does not specify the creation or management of documents, only their exchange markup. While it may be possible to directly use the CDA Model in a document authoring environment, such use is not the primary purpose of the CDA specification. |
− | Document management is critically interdependent with the CDA specifications, but the specification of document management messages is outside the scope of the CDA. ( | + | Document management is critically interdependent with the CDA specifications, but the specification of document management messages is outside the scope of the CDA. (see [[#Relationship_of_the_CDA_to_HL7_Messaging_Standards|Relationship of the CDA to HL7 Messaging Standards]] (§ 1.2.6)). |
'''NOTE:''' Several committees are developing structured document specifications that overlap in part with the CDA specification. The Structured Documents Technical Committee, in collaboration with Publishing and these other committees, is developing a Structured Documents Infrastructure chapter to clarify these relationships which should be available in upcoming editions. | '''NOTE:''' Several committees are developing structured document specifications that overlap in part with the CDA specification. The Structured Documents Technical Committee, in collaboration with Publishing and these other committees, is developing a Structured Documents Infrastructure chapter to clarify these relationships which should be available in upcoming editions. | ||
Line 38: | Line 38: | ||
The goals of the CDA are: | The goals of the CDA are: | ||
− | |||
* Give priority to delivery of patient care. | * Give priority to delivery of patient care. | ||
*Allow cost effective implementation across as wide a spectrum of systems as possible. | *Allow cost effective implementation across as wide a spectrum of systems as possible. | ||
Line 50: | Line 49: | ||
A number of design principles follow from consideration of the above goals: | A number of design principles follow from consideration of the above goals: | ||
− | |||
*This architecture must be compatible with XML and the HL7 RIM. | *This architecture must be compatible with XML and the HL7 RIM. | ||
*This architecture must be compatible with representations of clinical information arising from other HL7 committees. | *This architecture must be compatible with representations of clinical information arising from other HL7 committees. | ||
Line 59: | Line 57: | ||
*Document specifications based on this architecture should accommodate such constraints and requirements as supplied by appropriate professional, commercial, and regulatory agencies. | *Document specifications based on this architecture should accommodate such constraints and requirements as supplied by appropriate professional, commercial, and regulatory agencies. | ||
*Document specifications for document creation and processing, if intended for exchange, should map to this exchange architecture. | *Document specifications for document creation and processing, if intended for exchange, should map to this exchange architecture. | ||
− | *CDA documents must be human readable using widely-available and commonly-deployed XML-aware browsers and print drivers and a generic CDA style sheet written in a standard | + | *CDA documents must be human readable using widely-available and commonly-deployed XML-aware browsers and print drivers and a generic CDA style sheet written in a standard stylesheet language, such as XSLT. |
*Use open standards. | *Use open standards. | ||
Line 67: | Line 65: | ||
This section serves as a high-level introduction to the major components of a CDA document, all of which are described again and in greater detail later on. The intent here is to familiarize the reader with the high-level concepts to facilitate an understanding of the sections that follow. | This section serves as a high-level introduction to the major components of a CDA document, all of which are described again and in greater detail later on. The intent here is to familiarize the reader with the high-level concepts to facilitate an understanding of the sections that follow. | ||
− | Major components of a prototypic CDA document are shown in the following skeletal example. (Note that many required components are missing to simplify the example. See [[#Appendix_A._Samples|Samples]] for a detailed conformant example). | + | Major components of a prototypic CDA document are shown in the following skeletal example. (Note that many required components are missing to simplify the example. See [[#Appendix_A._Samples|Samples]] (§ 8.1) for a detailed conformant example). |
− | A CDA document is wrapped by the | + | A CDA document is wrapped by the <ClinicalDocument> element, and contains a header (see [[#Header|Header]] (§ 5.2)) and a body (see [[#Body|Body]] (§ 5.3)). The header lies between the <ClinicalDocument> and the <structuredBody> elements, and identifies and classifies the document and provides information on authentication, the encounter, the patient, and the involved providers. Information provided in the header establishes context for the content contained in the document body. |
− | The body contains the clinical report, and can be either an unstructured blob, or can be comprised of structured markup. The example shows a structured body, which is wrapped by the | + | The body contains the clinical report, and can be either an unstructured blob (e.g., a base-64 encoded PDF), or can be comprised of structured markup. The example shows a structured body, which is wrapped by the <structuredBody> element, and which is divided up into recursively nestable <section> elements. |
− | A CDA document section is wrapped by the | + | A CDA document section is wrapped by the <section> element. Each section can contain a single <text> element representing the section's narrative (see [[#Section_Narrative_Block|Section Narrative Block]] (§ 5.3.5)). Sections can nest within other sections to logically group and organize the information in the document. Sections may contain any number of CDA entries (see [[#Entry_Acts|Entry Acts]] (§ 5.3.6)) and external references. |
− | The CDA narrative block is wrapped by the | + | The CDA narrative block is wrapped by the <text> element within the <section> element, and must contain the human readable content to be rendered. The relationship between human readable content and machine readable entries is enabled via a text linking mechanism. See also [[#Human_Readability_and_Rendering_CDA_Documents|Human Readability and Rendering CDA Documents]] (§ 1.2.3) and [[#CDA_Conformance|CDA Conformance]] (§ 1.3) for principles governing the representation of the narrative block, and conformance requirements on the part of originators when populating the block, and recipients when rendering it. |
− | Within a document section, the narrative block represents content to be rendered, whereas CDA entries represent structured content provided for further computer processing (e.g. decision support applications). CDA entries typically encode content present in the narrative block of the same section. The example shows two | + | Within a document section, the narrative block represents content to be rendered, whereas CDA entries represent structured content provided for further computer processing (e.g. decision support applications). CDA entries typically encode content present in the narrative block of the same section. The example shows two <observation> CDA entries, and a <substanceAdministration> entry containing a nested <supply> entry, although several other CDA entries are defined. |
− | CDA entries can nest and | + | CDA entries can nest and optionally reference external objects. External references refer to content that exists outside this CDA document - such as some other image, some other procedure, or some other observation (which is wrapped by the <externalObservation> element). Externally referenced material is not covered by the authentication of the document referencing it. |
+ | Example 1 - highlights the elements that might appear in CDA document, it does not include all required elements. | ||
<div align="center">Example {{AUTOEXAMPLENUM}}</div> | <div align="center">Example {{AUTOEXAMPLENUM}}</div> | ||
− | <nowiki> | + | <nowiki><ClinicalDocument> |
− | <ClinicalDocument> | ||
... CDA Header ... | ... CDA Header ... | ||
<structuredBody> | <structuredBody> | ||
Line 104: | Line 102: | ||
===The "A" in "CDA"=== | ===The "A" in "CDA"=== | ||
− | The notion of CDA "levels" in CDA, Release One anticipated a hierarchical set of XML DTDs or XML Schemas to achieve the goals enumerated above (see [[#Goals_and_Design_Principles|Goals and Design Principles]]). This hierarchy formed an "architecture", hence the "A" in "CDA". | + | The notion of CDA "levels" in CDA, Release One anticipated a hierarchical set of XML DTDs or XML Schemas to achieve the goals enumerated above (see [[#Goals_and_Design_Principles|Goals and Design Principles]] (§ 1.1.3)). This hierarchy formed an "architecture", hence the "A" in "CDA". |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
{| class="wikitable" | {| class="wikitable" | ||
Line 120: | Line 110: | ||
|CDA Level One||The unconstrained CDA. | |CDA Level One||The unconstrained CDA. | ||
|- | |- | ||
− | |CDA Level Two||The CDA specification with section-level templates applied. | + | |CDA Level Two||The CDA specification with section-level templates applied, with no expectation of entry-level templates being present. |
|- | |- | ||
− | |CDA Level Three||The CDA specification with entry-level | + | |CDA Level Three||The CDA specification with at least one section containing one or more entry-level templates. |
|} | |} | ||
+ | |||
+ | While the notion of levels in CDA, Release Two remains constant, the approach to representing the hierarchies has changed. The current specification consists of a single CDA XML Schema, and the architecture arises from the ability to apply one or more of a hierarchical set of HL7 Templates, which serve to constrain the richness and flexibility of CDA. | ||
+ | :The RIM's [http://cda/infrastructure/rim/rim.htm#InfrastructureRoot-cls| InfrastructureRoot class] (§ 6.2.6) contains an attribute, templateId, which is available for use in CDA. <span class="change-highlight">Where templateId(s) have been asserted within a CDA document instance, the constraints contained within the template are assumed to be imposed. See [[#CDA Implementation Guides|CDA Implementation Guides]] (§ 4) for more details.</span> | ||
+ | |||
+ | :There is no requirement that CDA must be constrained, <span class="change-highlight"> however implementations that use structured data elements to drive automated processes will typically reference templates found in CDA Implementation Guide(s). The use of entry-level templates enables the semantic interoperability of any structured content found in documents exchanged.</span> | ||
+ | |||
+ | There are many kinds of HL7 Templates that might be created. Among them, three are particularly relevant for clinical documents: (1) those that constrain the document content or document-level templates, (2) those that constrain content expected in sections or section-level templates and (3) those that constrain the entries within document sections or entry-level templates. Other kinds of templates can be used, for example to enable consistency in demographic data and the representation of names, addresses and telecom references, or phone numbers. | ||
An illustration of one possible hierarchy of CDA plus HL7 Templates is shown here: | An illustration of one possible hierarchy of CDA plus HL7 Templates is shown here: | ||
− | |||
<div align="center">Example {{AUTOEXAMPLENUM}}</div> | <div align="center">Example {{AUTOEXAMPLENUM}}</div> | ||
− | *CDA | + | *CDA Base Standard |
− | ** | + | **Progress Note section-level template applied. |
− | *** | + | ***Progress Note section-level and Vital Signs entry-level template applied. |
− | **** | + | ****Endocrinology Progress Note section-level and Vital Signs entry-level template applied. |
− | **** | + | ****Progress Note section-level and ICU Vital Signs entry-level template applied. |
− | ** | + | **Cardiology Progress Note section-level template applied |
− | ** | + | **Cardiology Progress Note section-level and Cardiac Exam entry-level template applied. |
− | ** | + | **Endocrinology Progress Note section-level template applied. |
− | ** | + | **Endocrinology Progress Note section-level and Vital Signs entry-level template applied. |
===Human Readability and Rendering CDA Documents=== | ===Human Readability and Rendering CDA Documents=== | ||
− | The CDA requirement for human readability guarantees that a receiver of a CDA document can algorithmically display the clinical content of the note on a standard Web browser. CDA, Release 2.1, with its blend of narrative and CDA entries, presents | + | The CDA requirement for human readability guarantees that a receiver of a CDA document can algorithmically display the clinical content of the note on a standard Web browser. CDA, Release 2.1, with its blend of narrative and CDA entries, presents challenges to this requirement. |
− | Among the requirements affecting the design of CDA Release 2 are the following: | + | Among the requirements affecting the design of CDA Release 2.1 are the following: |
− | |||
− | |||
*There must be a deterministic way for a recipient of an arbitrary CDA document to render the attested content. | *There must be a deterministic way for a recipient of an arbitrary CDA document to render the attested content. | ||
+ | **<span class="change-highlight">Authenticated documents, need to convey with fidelity the clinical content reviewed by the legal and other authenticator(s)</span>. | ||
+ | **<span class="change-highlight"> Documents which are not authenticated, (e.g. machine generated documents) should convey the clinical content implied by the ClinicalDocument.code and the other header metadata in the document's section.text elements.</span> | ||
*Human readability shall not require a sender to transmit a special style sheet along with a CDA document. It must be possible to render all CDA documents with a single style sheet and general-market display tools. | *Human readability shall not require a sender to transmit a special style sheet along with a CDA document. It must be possible to render all CDA documents with a single style sheet and general-market display tools. | ||
− | *Human readability applies to the authenticated narrative content. There may be additional information conveyed in the | + | *Human readability applies to the authenticated narrative content. There may be additional information conveyed in the entries that is not required for human interpretation, but at no time shall the information provided in the entries conflict with the narrative content. |
*When structured content is derived from narrative, there must be a mechanism to describe the process (e.g. by author, by human coder, by natural language processing algorithm, by specific software) by which machine-processable portions were derived from a block of narrative. | *When structured content is derived from narrative, there must be a mechanism to describe the process (e.g. by author, by human coder, by natural language processing algorithm, by specific software) by which machine-processable portions were derived from a block of narrative. | ||
*When narrative is derived from structured content, there must be a mechanism to identify the process by which narrative was generated from structured data. | *When narrative is derived from structured content, there must be a mechanism to identify the process by which narrative was generated from structured data. | ||
− | These principles and requirements have led to the current approach, where the material to be rendered is placed into the Section.text field (see [[#Section_Narrative_Block|Section Narrative Block]]). The content model of this field is specially hand crafted to meet the above requirements, and corresponds closely to the content model of sections in CDA, Release One. Structured observations can reference narrative content in the Section.text field. Multimedia observations are encoded outside the Section.text field, and the | + | These principles and requirements have led to the current approach, where the material to be rendered is placed into the Section.text field (see [[#Section_Narrative_Block|Section Narrative Block]] (§ 5.3.5)). The content model of this field is specially hand crafted to meet the above requirements, and corresponds closely to the content model of sections in CDA, Release One. Structured observations can reference narrative content in the Section.text field. Multimedia observations are encoded outside the Section.text field, and the <renderMultiMedia> tag within the Section.text field provides an outgoing pointer that indicates where the referenced multimedia should be rendered. |
===XML Markup of CDA Documents=== | ===XML Markup of CDA Documents=== | ||
− | XML markup of CDA documents is prescribed in this specification. CDA instances are valid against the CDA Schema and may be subject to additional validation (see [[#CDA_Conformance|CDA Conformance]]). There is no prohibition against multiple schema languages (e.g., W3C, DTD, RELAXNG), as long as conforming instances are compatible. | + | XML markup of CDA documents is prescribed in this specification. CDA instances are valid against the CDA Schema and may be subject to additional validation (see [[#CDA_Conformance|CDA Conformance]] (§ 1.3)). There is no prohibition against multiple schema languages (e.g., W3C, DTD, RELAXNG), as long as conforming instances are compatible. |
Design Principles of the CDA Schema include: | Design Principles of the CDA Schema include: | ||
− | *'''General Requirements:''' The design of the CDA Schema follows the more general requirements for CDA (see [[#Goals_and_Design_Principles|Goals and Design Principles]]). | + | *'''General Requirements:''' The design of the CDA Schema follows the more general requirements for CDA (see [[#Goals_and_Design_Principles|Goals and Design Principles]] (§ 1.1.3)). |
*'''CDA Schema and V3 Implementation Technology Specification (ITS) :''' The CDA Schema will follow the general V3 XML ITS. | *'''CDA Schema and V3 Implementation Technology Specification (ITS) :''' The CDA Schema will follow the general V3 XML ITS. | ||
*'''RIM Mapping:''' The CDA Schema describes the style of XML markup of CDA instances for the purpose of exchange. It cannot be understood outside the context of this defining specification. At the same time, the CDA Schema is useful on its own for implementation purposes even though it is not intended to replicate or take the place of the R-MIM and HD. The CDA Schema, then, is not, in and of itself, an adequate map between conforming instance and the HL7 RIM. Semantic interoperability of CDA instances requires use and knowledge of the CDA Schema, R-MIM and HD as well as the corresponding RIM. | *'''RIM Mapping:''' The CDA Schema describes the style of XML markup of CDA instances for the purpose of exchange. It cannot be understood outside the context of this defining specification. At the same time, the CDA Schema is useful on its own for implementation purposes even though it is not intended to replicate or take the place of the R-MIM and HD. The CDA Schema, then, is not, in and of itself, an adequate map between conforming instance and the HL7 RIM. Semantic interoperability of CDA instances requires use and knowledge of the CDA Schema, R-MIM and HD as well as the corresponding RIM. | ||
Line 162: | Line 158: | ||
*:'''NOTE:''' Document analysis is a process that might be thought of as the document equivalent of a use case. Document analysis looks at a single instance or class of documents and analyzes their structure and content, often representing this as a tree structure "elm" notation. Document analysis also looks at the business rules for the lifecycle of that document or document class. Traditionally, document analysis determines the content model and overall structure and style of XML. | *:'''NOTE:''' Document analysis is a process that might be thought of as the document equivalent of a use case. Document analysis looks at a single instance or class of documents and analyzes their structure and content, often representing this as a tree structure "elm" notation. Document analysis also looks at the business rules for the lifecycle of that document or document class. Traditionally, document analysis determines the content model and overall structure and style of XML. | ||
*:Document analysis is an iterative step in content model derivation -- the "bottom up" approach to complement the "top down" derivation from the RIM. This will ensure that schemas and instances are not only RIM-derived, but represent recognizable artifacts in a simple manner. | *:Document analysis is an iterative step in content model derivation -- the "bottom up" approach to complement the "top down" derivation from the RIM. This will ensure that schemas and instances are not only RIM-derived, but represent recognizable artifacts in a simple manner. | ||
− | *'''Forward and Backward Compatibility:''' The CDA Schema should adhere to the requirements for forward and backward compatibility. (See [[#Backwards_and_Forwards_Compatibility|Backwards and Forwards Compatibility]]) | + | *'''Forward and Backward Compatibility:''' The CDA Schema should adhere to the requirements for forward and backward compatibility. (See [[#Backwards_and_Forwards_Compatibility|Backwards and Forwards Compatibility]] (§ 2.7)) |
*'''Naming:''' While XML markup, by definition, is for machine processing, it should be optimized for human review, debug, and design. The CDA Schema is not "self-documenting", but meaning should be clear from tag name and documentation (e.g., mapping to RIM). The human-language sense of a tag name should not be counterintuitive. | *'''Naming:''' While XML markup, by definition, is for machine processing, it should be optimized for human review, debug, and design. The CDA Schema is not "self-documenting", but meaning should be clear from tag name and documentation (e.g., mapping to RIM). The human-language sense of a tag name should not be counterintuitive. | ||
*'''Vocabulary:''' Vocabulary can be enumerated within the CDA Schema or in an external, referenced source. It is preferable to enumerate it when the vocabulary terms are both limited (not too large in number) and stable (not subject to change between ballot cycles). Where vocabulary is either too large or is subject to change, it is preferable to maintain it external to the CDA Schema and incorporate it by reference. In these cases, XML schema validation will not suffice for conformance. | *'''Vocabulary:''' Vocabulary can be enumerated within the CDA Schema or in an external, referenced source. It is preferable to enumerate it when the vocabulary terms are both limited (not too large in number) and stable (not subject to change between ballot cycles). Where vocabulary is either too large or is subject to change, it is preferable to maintain it external to the CDA Schema and incorporate it by reference. In these cases, XML schema validation will not suffice for conformance. | ||
Line 172: | Line 168: | ||
===Relationship of the CDA to HL7 Messaging Standards=== | ===Relationship of the CDA to HL7 Messaging Standards=== | ||
− | A CDA document is a defined and complete information object that can exist outside of a messaging context and/or can be a payload within an HL7 message (see [[# | + | A CDA document is a defined and complete information object that can exist outside of a messaging context and/or can be a payload within an HL7 message (see [[#CDA_Document_Exchange|CDA Document Exchange]] (§ 3)). Thus, the CDA complements HL7 messaging specifications. |
− | Clinical documents can be revised, and they can be appended to existing documents. | + | Clinical documents can be revised, and they can be appended to existing documents. CDA does not support an explicit forward pointer from an outdated version to the newer version. Without a process that tracks the chain of custody of clinical documents and all of their copies, there can be no way to guarantee that a clinical document being viewed has not been subsequently revised. |
− | |||
− | |||
To minimize the risk of viewing superseded information, there is a critical interdependence between clinical documents and document management systems. If CDA documents are viewed outside the context of a document management system, it cannot be known with certainty whether or not the viewed document has been revised. HL7 messages that carry CDA documents (such as the MDM messages in HL7 V2.x and the HL7 V3 Medical Records messages) convey critical contextual information that ensures accurate viewing of clinical data. | To minimize the risk of viewing superseded information, there is a critical interdependence between clinical documents and document management systems. If CDA documents are viewed outside the context of a document management system, it cannot be known with certainty whether or not the viewed document has been revised. HL7 messages that carry CDA documents (such as the MDM messages in HL7 V2.x and the HL7 V3 Medical Records messages) convey critical contextual information that ensures accurate viewing of clinical data. | ||
Line 189: | Line 183: | ||
A document recipient is an application role that receives status updates and documents from a document originator or document management system. The document recipient is responsible for ensuring that received CDA documents are rendered in accordance to this specification. | A document recipient is an application role that receives status updates and documents from a document originator or document management system. The document recipient is responsible for ensuring that received CDA documents are rendered in accordance to this specification. | ||
− | Because CDA is an exchange standard and may not represent the original form of a document, there are no persistent storage requirements for CDA documents defined in this standard. However, as noted above (see [[#Relationship_of_the_CDA_to_HL7_Messaging_Standards|Relationship of the CDA to HL7 Messaging Standards]]), document management is critically interdependent with the CDA specification. The custodian identified in the CDA header (see [[#custodian|custodian]]) is the participant charged with maintaining the original document, which may be in some form other than CDA. | + | Because CDA is an exchange standard and may not represent the original form of a document, there are no persistent storage requirements for CDA documents defined in this standard. However, as noted above (see [[#Relationship_of_the_CDA_to_HL7_Messaging_Standards|Relationship of the CDA to HL7 Messaging Standards]] (§ 1.2.6)), document management is critically interdependent with the CDA specification. The custodian identified in the CDA header (see [[#custodian|custodian]] (§ 5.2.2.3)) is the participant charged with maintaining the original document, which may be in some form other than CDA. |
===Recipient Responsibilities=== | ===Recipient Responsibilities=== | ||
− | *'''Assume default values where they are defined in this specification, and where the instance does not contain a value''' : Where CDA defines default values, the recipient must assume these values in the event that no value is contained in a CDA instance. ('''NOTE:''' | + | *'''Assume default values where they are defined in this specification, and where the instance does not contain a value''' : Where CDA defines default values, the recipient must assume these values in the event that no value is contained in a CDA instance. ('''NOTE:''' These values have been identified as having Minimum Cardinality = 0 and code binding = "Fixed" or "Closed w/ Default".) |
− | *'''Parse and interpret the complete CDA header''' : A recipient of a CDA document must be able to parse and interpret the complete CDA header. Because applications may choose to display demographic and other CDA header data drawn from a central master directory, the rendering of the CDA document header is at the discretion of the recipient. In addition, rendering of the CDA document header can be dependent on local business practice and context of use (e.g. electronic health record, de-identified scenario). Where a document originator wants to suggest a rendering, they can include one or more XML style sheets with an exchanged CDA document. Use of these style sheets is at the discretion of the recipient. | + | *'''Parse and interpret the complete CDA header''' : A recipient of a CDA document must be able to parse and interpret the complete CDA header. Because applications may choose to display demographic and other CDA header data drawn from a central master directory, the rendering of the CDA document header is at the discretion of the recipient. In addition, rendering of the CDA document header can be dependent on local business practice and context of use (e.g. electronic health record, de-identified scenario). However, extreme caution must be exercised if patient-identifying header information (e.g., name, address, data of birth, gender...) from the CDA document are not rendered. Those elements, if different, may indicate a patient mismatch or may indicate data discrepancies that should be analyzed and reconciled. Where a document originator wants to suggest a rendering, they can include one or more XML style sheets with an exchanged CDA document. Use of these style sheets is at the discretion of the recipient. |
*'''Parse and interpret the CDA body sufficiently to be able to render it''' : A recipient of a CDA document must be able to parse and interpret the body of a CDA document sufficiently to be able to render it, using the following rendering rules: | *'''Parse and interpret the CDA body sufficiently to be able to render it''' : A recipient of a CDA document must be able to parse and interpret the body of a CDA document sufficiently to be able to render it, using the following rendering rules: | ||
**If the CDA Body is non-XML, it will need to be rendered with a software tool that recognizes its particular MIME media type. | **If the CDA Body is non-XML, it will need to be rendered with a software tool that recognizes its particular MIME media type. | ||
**If the CDA Body is structured, the label of a section, as conveyed in the Section.title component, must be rendered. The absence of the Section.title component signifies an unlabeled section. | **If the CDA Body is structured, the label of a section, as conveyed in the Section.title component, must be rendered. The absence of the Section.title component signifies an unlabeled section. | ||
− | **If the CDA Body is structured, the contents of the Section.text field must rendered per the rules defined in [[#Section_Narrative_Block|Section Narrative Block]]. | + | **If the CDA Body is structured, the contents of the Section.text field must rendered per the rules defined in [[#Section_Narrative_Block|Section Narrative Block]] (§ 5.3.5). |
*A recipient of a CDA document is not required to parse and interpret the complete set of CDA entries contained within the CDA body. Within a local implementation, trading partners may ascribe additional recipient responsibilities to parse and interpret various entries. | *A recipient of a CDA document is not required to parse and interpret the complete set of CDA entries contained within the CDA body. Within a local implementation, trading partners may ascribe additional recipient responsibilities to parse and interpret various entries. | ||
*A recipient of a CDA document is not required to validate a CDA document against referenced templates. Within a local implementation, trading partners may ascribe additional recipient responsibilities for template validation. | *A recipient of a CDA document is not required to validate a CDA document against referenced templates. Within a local implementation, trading partners may ascribe additional recipient responsibilities for template validation. | ||
Line 205: | Line 199: | ||
**If the CDA Body is structured, the label of a section must be conveyed in the Section.title component. The absence of the Section.title component signifies an unlabeled section. | **If the CDA Body is structured, the label of a section must be conveyed in the Section.title component. The absence of the Section.title component signifies an unlabeled section. | ||
**If the CDA Body is structured, the attested narrative contents of a section must be placed in the Section.text field, regardless of whether information is also conveyed in CDA entries. Attested multimedia referenced in the narrative must be added as ObservationMedia and/or RegionOfInterest CDA entries. | **If the CDA Body is structured, the attested narrative contents of a section must be placed in the Section.text field, regardless of whether information is also conveyed in CDA entries. Attested multimedia referenced in the narrative must be added as ObservationMedia and/or RegionOfInterest CDA entries. | ||
− | **If the CDA Body is structured, the contents of the Section.text field must be created per the rules defined in [[#Section_Narrative_Block|Section Narrative Block]]. | + | **If the CDA Body is structured, the contents of the Section.text field must be created per the rules defined in [[#Section_Narrative_Block|Section Narrative Block]] (§ 5.3.5). |
*An originator of a CDA document is not required to fully encode all narrative into CDA entries within the CDA body. Within a local implementation, trading partners may ascribe additional originator responsibilities to create various entries. | *An originator of a CDA document is not required to fully encode all narrative into CDA entries within the CDA body. Within a local implementation, trading partners may ascribe additional originator responsibilities to create various entries. | ||
==CDA Extensibility== | ==CDA Extensibility== | ||
− | :'''NOTE:''' See | + | :'''NOTE:''' See [http://cda/infrastructure/itsxml/messaging-its-xml.htm#informalExtensions| XML ITS - Informal Extensions] (§2.5) for a complete discussion of V3 XML Extensibility rules. |
− | Locally-defined markup may be used when local semantics have no corresponding representation in the CDA specification. CDA seeks to standardize the highest level of shared meaning while providing a clean and standard mechanism for tagging | + | Locally-defined markup may be used when local semantics have no corresponding representation in the CDA specification. CDA seeks to standardize the highest level of shared meaning while providing a clean and standard mechanism for tagging content for local requirements. In order to support local extensibility requirements, it is permitted to include additional XML elements and attributes that are not included in the CDA schema. These extensions should not change the meaning of any of the standard data items, and receivers must be able to safely ignore these elements. Document recipients must be able to faithfully render the CDA document while ignoring extensions. |
− | Extensions may be included in the instance in a namespace other than the HL7v3 namespace, but must not be included within an element of type ED (e.g., | + | Extensions may be included in the instance in a namespace other than the HL7v3 namespace, but must not be included within an element of type ED (e.g., <text> within <procedure>) since the contents of an ED datatype within the conformant document may be in a different namespace. Since all conformant content (outside of elements of type ED) is in the HL7 namespace, the sender can put any extension content into a foreign namespace (any namespace other than the HL7 namespace). Receiving systems must not report an error if such extensions are present. |
When these extension mechanisms mark up content of general relevance, HL7 encourages users to get their requirements formalized in a subsequent version of the standard so as to maximize the use of shared semantics. | When these extension mechanisms mark up content of general relevance, HL7 encourages users to get their requirements formalized in a subsequent version of the standard so as to maximize the use of shared semantics. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
=[[Introduction to CDA Technical Artifacts]]= | =[[Introduction to CDA Technical Artifacts]]= |
Latest revision as of 16:46, 18 December 2018
Return to master table of contents
Contents
1 CDA Overview
1.1 What is the CDA
The HL7 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange. A clinical document is documentation of clinical observations and services, with the following characteristics:
- Persistence – A clinical document continues to exist in an unaltered state, for a time period defined by local and regulatory requirements (NOTE: There is a distinct scope of persistence for a clinical document, independent of the persistence of any XML-encoded CDA document exchange expression).
- Stewardship – A clinical document is maintained by an organization entrusted with its care.
- Potential for authentication - A clinical document is an assemblage of information that is intended to be legally authenticated.
- Context – A clinical document establishes the default context for its contents.
- Wholeness – Authentication of a clinical document applies to the whole and does not apply to portions of the document without the full context of the document.
- Human readability – A clinical document is human readable.
A CDA document is a defined and complete information object that can include text, images, sounds, and other multimedia content.
1.1.1 Key aspects of the CDA
Key aspects of the CDA include:
- CDA documents are encoded in Extensible Markup Language (XML). (NOTE: When alternate implementations are feasible, suitable conformance requirements will be issued so that in future the syntax may not be limited to XML.)
- CDA documents derive their machine processable meaning from the HL7 Reference Information Model (RIM) and use the HL7 Version 3 Data Types Release 1.0.
- The CDA specification is richly expressive and flexible. Document-level, section-level and entry-level templates can be used to constrain the generic CDA specification (see The "A" in "CDA" (§ 1.2.2) and CDA Implementation Guides (§ 4)).
1.1.2 Scope of the CDA
The scope of the CDA is the standardization of clinical documents for exchange. The concept of "Clinical Document" in the context of CDA is evolving as the use of CDA continues to expand. Clinical documents is meant broadly to cover documents generated not only by clinicians, but also documents generated by patients and caregivers as well as documents generated by payers and other stakeholders who are sharing health-related content.
The data format of clinical documents outside of the exchange context (e.g., the data format used to store clinical documents) is not addressed in this specification.
CDA documents can be transmitted using a variety of techniques, E.g. HL7 2.x messages, V3.0 messages, FHIR messages, Direct and Exchange solutions, etc. While the detailed specification for such messages and solutions are outside of the scope of the CDA, this specification does impose requirements upon the packaging of CDA documents in all of these and other contexts (see CDA Document Exchange (§ 3)).
The CDA does not specify the creation or management of documents, only their exchange markup. While it may be possible to directly use the CDA Model in a document authoring environment, such use is not the primary purpose of the CDA specification.
Document management is critically interdependent with the CDA specifications, but the specification of document management messages is outside the scope of the CDA. (see Relationship of the CDA to HL7 Messaging Standards (§ 1.2.6)).
NOTE: Several committees are developing structured document specifications that overlap in part with the CDA specification. The Structured Documents Technical Committee, in collaboration with Publishing and these other committees, is developing a Structured Documents Infrastructure chapter to clarify these relationships which should be available in upcoming editions.
1.1.3 Goals and Design Principles
The goals of the CDA are:
- Give priority to delivery of patient care.
- Allow cost effective implementation across as wide a spectrum of systems as possible.
- Support exchange of human-readable documents between users, including those with different levels of technical sophistication.
- Promote longevity of all information encoded according to this architecture.
- Enable a wide range of post-exchange processing applications.
- Be compatible with a wide range of document creation applications.
- Promote exchange that is independent of the underlying transfer or storage mechanism.
- Prepare the design reasonably quickly.
- Enable policy-makers to control their own information requirements without extension to this specification.
A number of design principles follow from consideration of the above goals:
- This architecture must be compatible with XML and the HL7 RIM.
- This architecture must be compatible with representations of clinical information arising from other HL7 committees.
- Technical barriers to use of the architecture should be minimized.
- The architecture specifies the representation of instances required for exchange.
- The architecture should impose minimal constraints or requirements on document structure and content required for exchange.
- The architecture must be scalable to accommodate fine-grained markup such as highly structured text and coded data.
- Document specifications based on this architecture should accommodate such constraints and requirements as supplied by appropriate professional, commercial, and regulatory agencies.
- Document specifications for document creation and processing, if intended for exchange, should map to this exchange architecture.
- CDA documents must be human readable using widely-available and commonly-deployed XML-aware browsers and print drivers and a generic CDA style sheet written in a standard stylesheet language, such as XSLT.
- Use open standards.
1.2 General CDA Concepts
1.2.1 Major Components of a CDA Document
This section serves as a high-level introduction to the major components of a CDA document, all of which are described again and in greater detail later on. The intent here is to familiarize the reader with the high-level concepts to facilitate an understanding of the sections that follow.
Major components of a prototypic CDA document are shown in the following skeletal example. (Note that many required components are missing to simplify the example. See Samples (§ 8.1) for a detailed conformant example).
A CDA document is wrapped by the <ClinicalDocument> element, and contains a header (see Header (§ 5.2)) and a body (see Body (§ 5.3)). The header lies between the <ClinicalDocument> and the <structuredBody> elements, and identifies and classifies the document and provides information on authentication, the encounter, the patient, and the involved providers. Information provided in the header establishes context for the content contained in the document body.
The body contains the clinical report, and can be either an unstructured blob (e.g., a base-64 encoded PDF), or can be comprised of structured markup. The example shows a structured body, which is wrapped by the <structuredBody> element, and which is divided up into recursively nestable <section> elements.
A CDA document section is wrapped by the <section> element. Each section can contain a single <text> element representing the section's narrative (see Section Narrative Block (§ 5.3.5)). Sections can nest within other sections to logically group and organize the information in the document. Sections may contain any number of CDA entries (see Entry Acts (§ 5.3.6)) and external references.
The CDA narrative block is wrapped by the <text> element within the <section> element, and must contain the human readable content to be rendered. The relationship between human readable content and machine readable entries is enabled via a text linking mechanism. See also Human Readability and Rendering CDA Documents (§ 1.2.3) and CDA Conformance (§ 1.3) for principles governing the representation of the narrative block, and conformance requirements on the part of originators when populating the block, and recipients when rendering it.
Within a document section, the narrative block represents content to be rendered, whereas CDA entries represent structured content provided for further computer processing (e.g. decision support applications). CDA entries typically encode content present in the narrative block of the same section. The example shows two <observation> CDA entries, and a <substanceAdministration> entry containing a nested <supply> entry, although several other CDA entries are defined.
CDA entries can nest and optionally reference external objects. External references refer to content that exists outside this CDA document - such as some other image, some other procedure, or some other observation (which is wrapped by the <externalObservation> element). Externally referenced material is not covered by the authentication of the document referencing it.
Example 1 - highlights the elements that might appear in CDA document, it does not include all required elements.
<ClinicalDocument> ... CDA Header ... <structuredBody> <section> <text>...</text> <observation>...</observation> <substanceAdministration> <supply>...</supply> </substanceAdministration> <observation> <externalObservation>... </externalObservation> </observation> </section> <section> <section>...</section> </section> </structuredBody> </ClinicalDocument>
1.2.2 The "A" in "CDA"
The notion of CDA "levels" in CDA, Release One anticipated a hierarchical set of XML DTDs or XML Schemas to achieve the goals enumerated above (see Goals and Design Principles (§ 1.1.3)). This hierarchy formed an "architecture", hence the "A" in "CDA".
CDA, Release One | CDA, Release Two |
---|---|
CDA Level One | The unconstrained CDA. |
CDA Level Two | The CDA specification with section-level templates applied, with no expectation of entry-level templates being present. |
CDA Level Three | The CDA specification with at least one section containing one or more entry-level templates. |
While the notion of levels in CDA, Release Two remains constant, the approach to representing the hierarchies has changed. The current specification consists of a single CDA XML Schema, and the architecture arises from the ability to apply one or more of a hierarchical set of HL7 Templates, which serve to constrain the richness and flexibility of CDA.
- The RIM's InfrastructureRoot class (§ 6.2.6) contains an attribute, templateId, which is available for use in CDA. Where templateId(s) have been asserted within a CDA document instance, the constraints contained within the template are assumed to be imposed. See CDA Implementation Guides (§ 4) for more details.
- There is no requirement that CDA must be constrained, however implementations that use structured data elements to drive automated processes will typically reference templates found in CDA Implementation Guide(s). The use of entry-level templates enables the semantic interoperability of any structured content found in documents exchanged.
There are many kinds of HL7 Templates that might be created. Among them, three are particularly relevant for clinical documents: (1) those that constrain the document content or document-level templates, (2) those that constrain content expected in sections or section-level templates and (3) those that constrain the entries within document sections or entry-level templates. Other kinds of templates can be used, for example to enable consistency in demographic data and the representation of names, addresses and telecom references, or phone numbers.
An illustration of one possible hierarchy of CDA plus HL7 Templates is shown here:
- CDA Base Standard
- Progress Note section-level template applied.
- Progress Note section-level and Vital Signs entry-level template applied.
- Endocrinology Progress Note section-level and Vital Signs entry-level template applied.
- Progress Note section-level and ICU Vital Signs entry-level template applied.
- Progress Note section-level and Vital Signs entry-level template applied.
- Cardiology Progress Note section-level template applied
- Cardiology Progress Note section-level and Cardiac Exam entry-level template applied.
- Endocrinology Progress Note section-level template applied.
- Endocrinology Progress Note section-level and Vital Signs entry-level template applied.
- Progress Note section-level template applied.
1.2.3 Human Readability and Rendering CDA Documents
The CDA requirement for human readability guarantees that a receiver of a CDA document can algorithmically display the clinical content of the note on a standard Web browser. CDA, Release 2.1, with its blend of narrative and CDA entries, presents challenges to this requirement. Among the requirements affecting the design of CDA Release 2.1 are the following:
- There must be a deterministic way for a recipient of an arbitrary CDA document to render the attested content.
- Authenticated documents, need to convey with fidelity the clinical content reviewed by the legal and other authenticator(s).
- Documents which are not authenticated, (e.g. machine generated documents) should convey the clinical content implied by the ClinicalDocument.code and the other header metadata in the document's section.text elements.
- Human readability shall not require a sender to transmit a special style sheet along with a CDA document. It must be possible to render all CDA documents with a single style sheet and general-market display tools.
- Human readability applies to the authenticated narrative content. There may be additional information conveyed in the entries that is not required for human interpretation, but at no time shall the information provided in the entries conflict with the narrative content.
- When structured content is derived from narrative, there must be a mechanism to describe the process (e.g. by author, by human coder, by natural language processing algorithm, by specific software) by which machine-processable portions were derived from a block of narrative.
- When narrative is derived from structured content, there must be a mechanism to identify the process by which narrative was generated from structured data.
These principles and requirements have led to the current approach, where the material to be rendered is placed into the Section.text field (see Section Narrative Block (§ 5.3.5)). The content model of this field is specially hand crafted to meet the above requirements, and corresponds closely to the content model of sections in CDA, Release One. Structured observations can reference narrative content in the Section.text field. Multimedia observations are encoded outside the Section.text field, and the <renderMultiMedia> tag within the Section.text field provides an outgoing pointer that indicates where the referenced multimedia should be rendered.
1.2.4 XML Markup of CDA Documents
XML markup of CDA documents is prescribed in this specification. CDA instances are valid against the CDA Schema and may be subject to additional validation (see CDA Conformance (§ 1.3)). There is no prohibition against multiple schema languages (e.g., W3C, DTD, RELAXNG), as long as conforming instances are compatible.
Design Principles of the CDA Schema include:
- General Requirements: The design of the CDA Schema follows the more general requirements for CDA (see Goals and Design Principles (§ 1.1.3)).
- CDA Schema and V3 Implementation Technology Specification (ITS) : The CDA Schema will follow the general V3 XML ITS.
- RIM Mapping: The CDA Schema describes the style of XML markup of CDA instances for the purpose of exchange. It cannot be understood outside the context of this defining specification. At the same time, the CDA Schema is useful on its own for implementation purposes even though it is not intended to replicate or take the place of the R-MIM and HD. The CDA Schema, then, is not, in and of itself, an adequate map between conforming instance and the HL7 RIM. Semantic interoperability of CDA instances requires use and knowledge of the CDA Schema, R-MIM and HD as well as the corresponding RIM.
- Document Analysis: The CDA Schema and conformant instances should adhere to the requirements of document analysis in derivation of the content model.
- NOTE: Document analysis is a process that might be thought of as the document equivalent of a use case. Document analysis looks at a single instance or class of documents and analyzes their structure and content, often representing this as a tree structure "elm" notation. Document analysis also looks at the business rules for the lifecycle of that document or document class. Traditionally, document analysis determines the content model and overall structure and style of XML.
- Document analysis is an iterative step in content model derivation -- the "bottom up" approach to complement the "top down" derivation from the RIM. This will ensure that schemas and instances are not only RIM-derived, but represent recognizable artifacts in a simple manner.
- Forward and Backward Compatibility: The CDA Schema should adhere to the requirements for forward and backward compatibility. (See Backwards and Forwards Compatibility (§ 2.7))
- Naming: While XML markup, by definition, is for machine processing, it should be optimized for human review, debug, and design. The CDA Schema is not "self-documenting", but meaning should be clear from tag name and documentation (e.g., mapping to RIM). The human-language sense of a tag name should not be counterintuitive.
- Vocabulary: Vocabulary can be enumerated within the CDA Schema or in an external, referenced source. It is preferable to enumerate it when the vocabulary terms are both limited (not too large in number) and stable (not subject to change between ballot cycles). Where vocabulary is either too large or is subject to change, it is preferable to maintain it external to the CDA Schema and incorporate it by reference. In these cases, XML schema validation will not suffice for conformance.
1.2.5 Security, Confidentiality, and Data Integrity
Application systems sending and receiving CDA documents are responsible for meeting all legal requirements for document authentication, confidentiality, and retention. For communications over public media, cryptographic techniques for source/recipient authentication and secure transport of encapsulated documents may be required, and should be addressed with commercially available tools outside the scope of this standard.
The CDA does provide confidentiality status information to aid application systems in managing access to sensitive data. Confidentiality status may apply to the entire document or to specified segments of the document.
1.2.6 Relationship of the CDA to HL7 Messaging Standards
A CDA document is a defined and complete information object that can exist outside of a messaging context and/or can be a payload within an HL7 message (see CDA Document Exchange (§ 3)). Thus, the CDA complements HL7 messaging specifications.
Clinical documents can be revised, and they can be appended to existing documents. CDA does not support an explicit forward pointer from an outdated version to the newer version. Without a process that tracks the chain of custody of clinical documents and all of their copies, there can be no way to guarantee that a clinical document being viewed has not been subsequently revised.
To minimize the risk of viewing superseded information, there is a critical interdependence between clinical documents and document management systems. If CDA documents are viewed outside the context of a document management system, it cannot be known with certainty whether or not the viewed document has been revised. HL7 messages that carry CDA documents (such as the MDM messages in HL7 V2.x and the HL7 V3 Medical Records messages) convey critical contextual information that ensures accurate viewing of clinical data.
1.3 CDA Conformance
- NOTE: See HL7 V3 Refinement and Localization for a complete discussion of V3 conformance.
A conformant CDA document is one that at a minimum validates against the CDA Schema, and that restricts its use of coded vocabulary to values allowable within the specified vocabulary domains. However a computer cannot validate every aspect of conformance. The focus of this section is to highlight these aspects of CDA that cannot be machine validated - particularly those aspects related to the CDA human readability requirements.
A document originator is an application role that creates a CDA document. CDA documents can be created via transformation from some other format, as a direct output of an authoring application, etc. The document originator often is responsible for communicating with a persistent storage location, often using HL7 V2 MDM or HL7 V3 Medical Records messages. The document originator is responsible for ensuring that generated CDA documents are fully conformant to this specification.
A document recipient is an application role that receives status updates and documents from a document originator or document management system. The document recipient is responsible for ensuring that received CDA documents are rendered in accordance to this specification.
Because CDA is an exchange standard and may not represent the original form of a document, there are no persistent storage requirements for CDA documents defined in this standard. However, as noted above (see Relationship of the CDA to HL7 Messaging Standards (§ 1.2.6)), document management is critically interdependent with the CDA specification. The custodian identified in the CDA header (see custodian (§ 5.2.2.3)) is the participant charged with maintaining the original document, which may be in some form other than CDA.
1.3.1 Recipient Responsibilities
- Assume default values where they are defined in this specification, and where the instance does not contain a value : Where CDA defines default values, the recipient must assume these values in the event that no value is contained in a CDA instance. (NOTE: These values have been identified as having Minimum Cardinality = 0 and code binding = "Fixed" or "Closed w/ Default".)
- Parse and interpret the complete CDA header : A recipient of a CDA document must be able to parse and interpret the complete CDA header. Because applications may choose to display demographic and other CDA header data drawn from a central master directory, the rendering of the CDA document header is at the discretion of the recipient. In addition, rendering of the CDA document header can be dependent on local business practice and context of use (e.g. electronic health record, de-identified scenario). However, extreme caution must be exercised if patient-identifying header information (e.g., name, address, data of birth, gender...) from the CDA document are not rendered. Those elements, if different, may indicate a patient mismatch or may indicate data discrepancies that should be analyzed and reconciled. Where a document originator wants to suggest a rendering, they can include one or more XML style sheets with an exchanged CDA document. Use of these style sheets is at the discretion of the recipient.
- Parse and interpret the CDA body sufficiently to be able to render it : A recipient of a CDA document must be able to parse and interpret the body of a CDA document sufficiently to be able to render it, using the following rendering rules:
- If the CDA Body is non-XML, it will need to be rendered with a software tool that recognizes its particular MIME media type.
- If the CDA Body is structured, the label of a section, as conveyed in the Section.title component, must be rendered. The absence of the Section.title component signifies an unlabeled section.
- If the CDA Body is structured, the contents of the Section.text field must rendered per the rules defined in Section Narrative Block (§ 5.3.5).
- A recipient of a CDA document is not required to parse and interpret the complete set of CDA entries contained within the CDA body. Within a local implementation, trading partners may ascribe additional recipient responsibilities to parse and interpret various entries.
- A recipient of a CDA document is not required to validate a CDA document against referenced templates. Within a local implementation, trading partners may ascribe additional recipient responsibilities for template validation.
1.3.2 Originator Responsibilities
- Properly construct CDA Narrative Blocks : An originator of a CDA document must ensure that the attested portion of the document body is structured such that a recipient, adhering to the recipient responsibilities above, will correctly render the document. This includes:
- If the CDA Body is structured, the label of a section must be conveyed in the Section.title component. The absence of the Section.title component signifies an unlabeled section.
- If the CDA Body is structured, the attested narrative contents of a section must be placed in the Section.text field, regardless of whether information is also conveyed in CDA entries. Attested multimedia referenced in the narrative must be added as ObservationMedia and/or RegionOfInterest CDA entries.
- If the CDA Body is structured, the contents of the Section.text field must be created per the rules defined in Section Narrative Block (§ 5.3.5).
- An originator of a CDA document is not required to fully encode all narrative into CDA entries within the CDA body. Within a local implementation, trading partners may ascribe additional originator responsibilities to create various entries.
1.4 CDA Extensibility
- NOTE: See XML ITS - Informal Extensions (§2.5) for a complete discussion of V3 XML Extensibility rules.
Locally-defined markup may be used when local semantics have no corresponding representation in the CDA specification. CDA seeks to standardize the highest level of shared meaning while providing a clean and standard mechanism for tagging content for local requirements. In order to support local extensibility requirements, it is permitted to include additional XML elements and attributes that are not included in the CDA schema. These extensions should not change the meaning of any of the standard data items, and receivers must be able to safely ignore these elements. Document recipients must be able to faithfully render the CDA document while ignoring extensions.
Extensions may be included in the instance in a namespace other than the HL7v3 namespace, but must not be included within an element of type ED (e.g., <text> within <procedure>) since the contents of an ED datatype within the conformant document may be in a different namespace. Since all conformant content (outside of elements of type ED) is in the HL7 namespace, the sender can put any extension content into a foreign namespace (any namespace other than the HL7 namespace). Receiving systems must not report an error if such extensions are present.
When these extension mechanisms mark up content of general relevance, HL7 encourages users to get their requirements formalized in a subsequent version of the standard so as to maximize the use of shared semantics.
2 Introduction to CDA Technical Artifacts
(content on separate page)
3 CDA Document Exchange
(content on separate page)
4 CDA Implementation Guides
(content on separate page)
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)