Consolidated CDA Release 2.2 - Local Development build (v2.2). See the Directory of published versions

Section Level Guidance

The C-CDA Companion Guide provides additional guidance aimed at increasing consistency in the way content in structured C-CDA documents is represented and used across all implementations. The goal is to raise awareness about why and how to use the section templates defined in C-CDA, and in other standards that supplement and complement C-CDA, to meet rising expectations and emerging regulations focused on expanding interoperability.

This chapter provides general guidance relevant when representing clinical information as structured C-CDA documents. It explains the purpose of structured sections and supplies background on how the section templates in C-CDA were originally developed. It summarizes the set of sections defined by Consolidate CDA and explains how each type of document template uses different section templates to represent —in human readable form– the information commonly contained in each specific type of clinical note. It introduces the section templates which require machine processable “discrete data” to accompany the human readable narrative. Finally, it summarizes several section templates that are new for Consolidated C-CDA or defined in implementation guides published elsewhere in the C-CDA implementer community and provides guidance on their use in C-CDA documents.

Understanding Content Sections in Structured Documents

The idea of improving the communication of information contained in clinical notes has been around for decades. Long before C-CDA, a documentation methodology called “SOAP (Subjective, Objective, Assessment, and Plan) notes” was invented. The birth of the problem-oriented medical record (POMR) and SOAP note marked an epoch in the history of health care. Dr. Lawrence Weed, developer of the SOAP note and professor of medicine and pharmacology at Yale University, challenged conventional medical documentation and advocated for a scientific structure to frame clinical reasoning in the 1950s. Today, the SOAP note is the most common method of documentation used by providers to input notes into patients’ medical records. They allow providers to record and share information in a universal, systematic and easy to read format.^82 Ineffective communication contributes to the top causes of sentinel events and continues to be an unremitting area for refinement.

After the development of the HL7 Clinical Document Architecture R2 standard in 2005, an alliance of healthcare vendors, providers and associations pooled resources in a rapid-development initiative. In a span of three years, the Health Story Project produced eight Health Level Seven (HL7) data standards for the flow of information using common types of healthcare documents. The alliance examined thousands of common clinical notes generated by a variety of medical transcription solutions and identified what structured sections were needed to represent the SOAP notes commonly generated by current-day clinicians. The “Health Story Guides,” as they were originally named, defined the initial set of section templates based on this analysis. Every section template includes a section.text element designed to hold the human readable narrative of that section of the structured document.

While no longer active today, the HIMSS Health Story Project provided education to the health IT community on tools and resources to aid in the creation of comprehensive electronic records that tell a patient’s complete health story. Some especially educational concepts from this initiative are summarized in the following chapters.

The Storytelling Power of C-CDA

This roundtable presentation explained the twelve common clinical document types that are defined in Consolidated CDA (C-CDA) and described how each can be leveraged for information exchange in different care settings and for different encounter types. When should each C-CDA clinical document type be leveraged? What sections are used in C-CDA clinical documents and how do they differ from a Continuity of Care Document (CCD)? The Roundtable showed how to apply the SOAP framework to reveal the storytelling power of C-CDA by thinking of the section templates in terms of the subjective, objective, assessment, and plan information each contains. In some cases, the information in one section may be classified in multiple SOAP categories. The categorization is an approximation designed to improve understanding of the full collection of C-CDA section templates.

Figure 5: Visualizing C-CDA section templates by applying the SOAP framework

A More Meaningful Patient Story Using C-CDA: Tell it. Use it. Share it.

This presentation explained how documentation-based exchange via Consolidated Clinical Document Architecture (C-CDA), when implemented correctly, has the power to capture and share a more comprehensive electronic record that can be used to improve care.

By 2011, when C-CDA R1.0 was first published, a larger industry effort brought together CDA templates for clinical SOAP notes that had been defined by several organizations including Integrating the Healthcare Enterprise (IHE), HITSP, and HL7. The harmonized work included not only definitions for section templates needed to structure common clinical note types, but also included entry templates that defined how to represent the human readable section information using machine processable “clinical statements”. Clinical statements were templated using the syntax and data structures supported by the HL7 CDA R2 standard which derived its data types and modeling from an early version of the HL7 Reference Information Model (RIM). The HL7 RIM is the cornerstone of all HL7 Version 3 standards. It is a shared model between all domains and, as such, forms a common basis from which all domains can create information exchange artifacts and messages.

Today in C-CDA and in the C-CDA Supplemental Implementation Guides, the C-CDA standards development community has defined and published a wide array of section templates to represent clinical information in the context of structured documents. It is important to note that the purpose of each section template is dependent on the context of its intended use within a larger document structure. While some templates have been defined generically and are suitable for reuse in multiple structured documents, others due to the nature of their definitions may not be appropriate for re-use across other documents. For this reason, is it important for the context of the overarching document to be considered when determining if it is appropriate to include a particular type of section template in a particular type of document template.

General Section-Level Guidance

The following guidance elements are not specific to any one C-CDA template but rather are overarching guidance elements that apply to an entire C-CDA document.

Data Provenance for a Section

The author role is key to understanding the provenance of the information.

The roles populated in the header of the document apply to each section of content as well, unless explicitly indicated otherwise. If the author information for a section is not explicitly declared, then the author of the information in that section can be assumed to be the author contained in the document header. This is behavior within a CDA document is called context conduction.

This assumption extends to entries contained in the section as well. If the author information for an entry is not explicitly declared, then the author of the information in that entry can be assumed to be the author contained in the encompassing section.

While it is generally preferred that provenance be conveyed either at the document level, or at the entry level, it is possible for provenance to be conveyed at the section level when the default context conduction does not apply.

When representing a clinical note using structured sections, each section of information receives its context from the document’s header. If author information for a section is not explicitly declared, then the author of that section of information can be assumed to be the same as the author information contained in the document header.

The recordTarget, author, and informant roles populated in the header of the document apply to each section of content as well, unless explicitly indicated otherwise. The author role is key to understanding the provenance of the information in the document. If the author information for a section is not explicitly declared, then the author of that section of information can be assumed to be the same as the author information contained in the header.

This assumption extends to entries contained in the section as well, unless the author information is explicitly declared at the entry level. While it is generally preferred that provenance be conveyed at the entry level, provenance information included at the document or section level conducts to the entry when provenance at the entry level is not stated explicitly.

Declaring Section Template Conformance

As explained in Chapter 2.3.1 Declaring Template Conformance, template conformance may be declared at any level of a C-CDA document—header, section, entry, or within an entry at a sub-structural level.

A template declaration in a C-CDA section asserts the constraints applicable for that section of XML. The template declaration tells validators and Content Consumers what to expect in terms of the information that, may, should, or shall be populated within this section of the document.

C- CDA templates are identified with a templateId. The templateId is a two-part identifier that consists of a root and an extension. The root identifies the named template and the extension identifies the version of that template. Initially C-CDA templates did not include versions. The templateId/@extension attribute was not used. Many of those original template versions are still used in C-CDA R2.1.

Chapter 3.1.2 of the Consolidated CDA Implementation Guide discusses the use of templateIds and what needs to be included in a C-CDA document:

• To assert conformance with C-CDA R2.1, declare the templateId of the version of the template defined in C-CDA R2.1.
• To assert conformance with C-CDA R1.1, declare the templateId of the version of the template defined in C-CDA R1.1.

Over time, many implementations have added template declarations without regard for the overhead they place on validation services or the confusion they may create for Content Consumers. The volume of templateId declarations adds to the size and complexity of C-CDA documents. This is beginning to have a negative impact for the C-CDA implementer community and has resulted in the realization that templateId declarations need regular maintenance and pruning over time.

A duplicate templateId declaration is a template declaration for the same structural part of a C-CDA document (i.e. document, section, entry, entry-part) with identical @root and @extension information. The order of the @root and @extension attributes does not matter when determining duplication.

To avoid confusion and minimize inclusion of unnecessary information in C-CDA documents, implementers should avoid including duplicate or irrelevant templateId declarations.

It is important to note that including the 2.1 templateid and the 1.1 template id is no duplication and is valid to describe the content as conformant to both the 1.1 and 2.1 versions of C-CDA.

As standards evolve an implementer community may decide to deprecate a version of a template or a collection of templates published in a version of an implementation guide. It should be anticipated that implementer communities may determine that certain version of a template should not be used going forward.

Example 16: Declaring template conformance at the section level.

<!-- Allergies and Intolerances Section-->
<component>
    <section>
        <!-- Conformant to C-CDA R2.1 Allergies and Intolerances Section (entries optional)-->
        <templateId root="2.16.840.1.113883.10.20.22.2.6" extension="2015-08- 01"/>
        <!-- Conformant to C-CDA R1.1 Allergies and Intolerances Section (entries optional) -->
        <templateId root="2.16.840.1.113883.10.20.22.2.6"/>
        <id root="0937FF9A-00CE-11E6-B4C5-0050568B000B"/>
        <code code="48765-2" displayName="Allergies &amp;or adverse reactions Doc"
            codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
        <title>Allergies</title>
        <text>
        </text>
    </section>
</component>

Example 17: Declaring conformance to multiple templates.

<!—Substance or Device Allergy -->
<templateId root="2.16.840.1.113883.10.20.24.3.90" extension="2014-06- 09" />
<templateId root="2.16.840.1.113883.10.20.24.3.90"/>
<!— Allergy – Intolerance Observation -->
<templateId root="2.16.840.1.113883.10.20.22.4.7" extension="2014-06- 09" />
<templateId root="2.16.840.1.113883.10.20.22.4.7"/>

Example 18: (Wrong) Duplicate template declarations at the section level.

<!-- Allergies and Intolerances Section-->
<component>
    <section>
        <templateId root="2.16.840.1.113883.10.20.22.2.6"/>
        <templateId root="2.16.840.1.113883.10.20.22.2.6" extension="2015-08- 01"/>
        <templateId root="2.16.840.1.113883.10.20.22.2.6"/>
        <templateId extension="2015-08- 01" root="2.16.840.1.113883.10.20.22.2.6.1" />
        <id root="0937FF9A-00CE-11E6-B4C5-0050568B000B"/>
        <code code="48765-2" displayName="Allergies &amp;or adverse reactions Doc"
            codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
        <title>Allergies</title>
        <text>
        </text>
    </section>
</component>

Best Practices for Implementing Templates revised to support USCDI v2 and v3

To support backwards compatibility, and in alignment with best practices documented in C-CDA 2.1 Volume 1 Section 3.1.2 Assertion of Compatibility, when utilizing templates defined in Appendix A of the Companion Guide that are newer versions of templates previously published in C-CDA 2.1, implementers should include both the templateId for the new version of the template, as well as the templateId for prior version of the template published in C-CDA 2.1.

Figure 6: Example of how to include templateIds for Companion Guide templates

<observation classCode="OBS" moodCode="EVN">
    <!-- ** Problem Observation ** -->
    <!-- Problem Observation (C-CDA 1.1) -->
    <templateId root="2.16.840.1.113883.10.20.22.4.4" />
    <!-- Problem Observation (C-CDA 2.1) -->
    <templateId root="2.16.840.1.113883.10.20.22.4.4" extension="2015-08- 01" />
    <!-- Problem Observation (C-CDA Companion Guide R3) -->
    <templateId root="2.16.840.1.113883.10.20.22.4.4" extension="2022- 06 - 01" />
    <id root="ab1791b0-5c71-11db-b0de-0800200c9a66" />
    ...
</observation>

Narrative Block Formatting

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.^85 This requirement impacts C-CDA in the following ways:

• There must be a deterministic way for a recipient of an arbitrary CDA document to render the attested content.
• 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 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. In some cases, the data design of the entry templates required in the section heavily influence what clinical information can be expected to be present in the Narrative Block. In other cases, where entry templates are optional or not defined at all, the content in the Narrative Block may reflect information gathered in source systems as text and human crafted notes.

If the CDA Body is structured, the Content Creator includes the attested narrative content in the appropriate section.text field, regardless of whether information is also conveyed in CDA entries. An originator of a CDA document is not required to fully encode all narrative into CDA entries within the CDA body. Within specific implementations, trading partners may ascribe additional originator responsibilities to create various entries that meet certain conformance requirements or meet the conformance requirements described by defined templates.

Example 19: Sample Narrative Block in a Section

<section>
    ...
    <text>
        <table>
            <colgroup>
                <col width="25%"/>
                <col width="25%"/>
                <col width="25%"/>
                <col width="25%"/>
            </colgroup>
            <thead>
                <tr>
                    <th>Information Type</th>
                    <th>Date</th>
                    <th>Relevant Information</th>
                    <th>Documented By</th>
                </tr>
            </thead>
            <tbody>
                <tr ID="SocialHistory_1">
                    <td>Tobacco smoking status:</td>
                    <td><content>(04/12/2016)</content></td>
                    <td><content>Never smoked</content></td>
                    <td><content>M.Smith</content> <content>(04/12/2016)</content></td>
                </tr>
            </tbody>
        </table>
    </text>
    ...
    <entry typeCode="DRIV">
        <observation classCode="OBS" moodCode="EVN">
            <templateId root="2.16.840.1.113883.10.20.22.4.78"/>
            <templateId root="2.16.840.1.113883.10.20.22.4.78"
                extension="2014-06- 09"/>
            <id extension="64020-Z9301" root="1.2.840.114350.1.13.6289.1.7.1.1040.1"/>
            <code code="72166-2" codeSystem="2.16.840.1.113883.6.1"
                codeSystemName="LOINC" displayName="Tobacco smoking status"/>
            <text><reference value="#SocialHistory_1"></reference></text>
            <statusCode code="completed"/>
            <effectiveTime value="20160412"/>
            <value xsi:type="CD" code="266919005" codeSystem="2.16.840.1.113883.6.96"
                displayName="Never smoked tobacco" />
            <author>
                <time value="20160412"/>
                <assignedAuthor>
                    <id extension="10.1" root="1.2.840.114350.1.1"/>
                </assignedAuthor>
            </author>
        </observation>
    </entry>
    ...
</section>

CDA permits additional information conveyed in the document that is there primarily for machine processing that is not authenticated and need not be rendered. However, the requirement that all attested content be present in the section.text field, suggests best practice is for all clinical content to be rendered through section.text.

Reference: Representation of Discrete Data

Tags for formatting Narrative Text

The content model of the CDA Narrative Block schema is specially hand crafted to meet the requirements outlined above. Chapter 4.3.5 of the HL7 CDA standard provides a detailed explanation of the section Narrative Block and its representation to support ubiquitous rendering. The table below provides information on some of the formatting tags commonly used to organize and render the human readable information in the Narrative Block.

Table 27: Tags for formatting Narrative Text

Multiple Views and styleCode

Experience sharing documents has proven that different users expect, even demand, different views. Patients and providers have different needs; specialists and general practice providers have different needs. The HL7 Relevant and Pertinent Survey identified the need to improve rendering capabilities for the information contained in CDA documents.

CDA documents support a technique for using multiple XML stylesheet processing instructions and a controlled vocabulary for the @styleCode attribute has been established by IHE.^87 For more information on the use of styleCodes, reference the IHE Multiple Content Views (MCV) Profile - Published 2014- 08 -28. The profile includes examples to show how these styleCodes can be used to improve rendering options.

To promote a more consistent user experience for the viewing of the human readable content, implementers are encouraged to use the set of @styleCode values established by the MCV Profile. These @styleCode values establish a common way to tag text as a code, a date, a dateTime, an alert, and many other generally useful concepts.

These styleCode values can be used to facilitate multiple clinical content rendering features. Systems that create CDA documents can use values from this table to improve the processing and rendering options for the information. Systems that render CDA document content with these styleCodes shall not omit or hide or otherwise obstructed from view information that uses these styleCodes unless they are using a specific rendering view that calls for such behavior.

Date/Time Guidance

Temporal information is often included as relevant and pertinent information to be exchanged. However, implementers need to be diligent when representing date/time information to make sure irrelevant or inaccurate levels of precision are not introduced when representing this type of information.

Reference: 5.1.10 Detailed Date/Time Guidance

Irrelevant Data (Not Pertinent)

Sharing irrelevant data, or omitting relevant data, can have an undesirable impact on clinician satisfaction and/or patient care. Developers of software to create, render, or incorporate C-CDA documents are encouraged to review recommendations in the HL7 CDA® R2 IG: Clinical Summary Relevant and Pertinent Data, Release 1 (PI ID: 1183) that underwent ballot during the HL7 January 2017 ballot cycle.

Use of Open Templates

Again, it is important to emphasize the reusability and flexibility of templates so that implementations support the ability to tailor the content in CDA sections specific to the patient’s care, provider, or setting needs. Within C-CDA, nearly all templates allow additional content and are described as open templates.

While section templates define the content to be included in that structural component of the document, additional content may augment each document as needed for a particular circumstance, so long as the content is relevant to the defined purpose of the section.

For example, the Social History Section is defined as, “ This section contains social history data that influence a patient’s physical, psychological, or emotional health (e.g., smoking status, pregnancy). Demographic data, such as marital status, race, ethnicity, and religious affiliation, is captured in the header.”^88

Therefore, information about the person’s level of education, housing instability, food insecurity or transportation access challenges could be included in this section, provided the document did not contain another section defined to include this information more appropriately.

Existing templates defined in C-CDA can be used to represent additional data elements defined in the Vocabulary section of the Interoperability Standards Advisory (ISA).^ When using available templates to represent a data element defined in the ISA, it is important to represent the concept with coded values from the associated value set included for that data element in the ISA. Additionally, as use cases warrant it, implementers can consider including CDA templates from outside the C-CDA standard itself, such as those from the Supplemental Implementation Guides which define new template versions and templates for additional use cases, These Supplemental Implementation Guides are published alongside the main C-CDA specification: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=492.

Caution: Implementers should be aware that recipients may not understand templates included at an unexpected location within a document.

Declaring Business Rules that Limit Section Content

In order to communicate that business rules have been applied to constrain the amount of information represented in the section of a document C-CDA Content Creators should explicitly clarify the time range of the included information in the human readable text for the section.

For example, the Vital Signs Section is defined as, ”The Vital Signs Section contains relevant vital signs for the context and use case of the document type, such as blood pressure, heart rate, respiratory rate, height, weight, body mass index, head circumference, pulse oximetry, temperature, and body surface area. The section should include notable vital signs such as the most recent, maximum and/or minimum, baseline, or relevant trends. Vital signs are represented in the same way as other results but are aggregated into their own section to follow clinical conventions.”^89

A C-CDA Content Creator may have a business rule that limits the amount of vital sign information included in a Patient Summary to only the most recent vital signs for the patient in the requested period of time. This may be determined based on the effectiveTime/high for the time interval of the request. Business rules that further constrain the standard purpose of the defined section template should be explicitly documented in the section content.

Reference : 5.1.8 Specifying Time Intervals for Sections with Limits on the Included Discrete Data

The Section Time Range Observation is a newly defined template to describe the business rule used to limit the information contained in the section. It is an optional entry and may be used in any section.

Table 38: Section Time Range Observation Template

useful when a query for a C-CDA document may request a large amount of data–potentially years—and the system that creates the document supplied in a response, limits the data they return to a specific range of time. This template enables the system creating the document to state the business logic used to constrain the amount of data provided in a section.

The Section Time Range template is used to communicate the ‘business logic’ used to limit the information contained in the section to a specific range of time. For example, if a CCD document is requested for the last 5 years and the Content Creator system has business rules that creates documents on demand but only returns one- year of past laboratory results, the Section Time Range template can be used to indicate the laboratory section only contains 12 months of data from the requested effectiveTime/low or at most 12 months of data prior to the effectiveTime/high in the request. The business logic used to limit the data is stated in the value element of the Section Time Range template using a datatype of IVL_TS. The template does not include an effectiveTime element.

Example 20: Example of Section Time Range Observation

<section>
    ...
    <title>Procedures</title>
    <text>
        <content ID="Proc_STR">Procedures performed between 08/15/2012 and 08/15/2015.</content>
        ...
    </text>
    <entry>
        <observation classCode="OBS" moodCode="EVN">
            <templateId root="2.16.840.1.113883.10.20.22.4.201" extension="2016-06- 01"/>
            <code code="82607-3" codeSystem="2.16.840.1.113883.6.1"
                displayName="Section Date and Time Range"/>
            <text>
                <reference value="#Proc_STR"/>
            </text>
            <statusCode code="completed"/>
            <value xsi:type="IVL_TS">
                <low value="20120815"/>
                <high value="20150815"/>
            </value>
        </observation>
    </entry>
</section>

Reference: Appendix A.2

Sections Defined in C-CDA (ordered using SOAP framework)

As explained in the Health Story Roundtable presentation titled “The Storytelling Power of C-CDA”, understanding the purpose of the C-CDA section templates is not facilitated by considering them in alphabetical order.^90 The C- CDA Implementation Guide presents them in alphabetical order to speed access for readers. Considering the C- CDA section templates using the SOAP framework makes it easier to see how these sections can be used in a structured document to express the content of a clinical SOAP note.

The application of the SOAP framework does not produce a perfect classification result. Some sections don’t fit well into the SOAP framework. They have been classified as “other types of sections”. Some sections are defined to contain “heterogeneous” information, meaning the section’s content spans the boundaries of the SOAP framework. For example, the Assessment and Plan Section contains both assessment (A) and plan (P) information. Section structures that contain “homogeneous” information, all of the same type with the same purpose, improves information processing.

Subjective Information

Table 28: Subjective Information

Objective Information

Table 29: Objective Information

Assessment Information

Table 30: Assessment Information

Plan/Planning Information

Table 31: Plan/Planning Information

Other Information

Table 32: Other Information

Supplemental C-CDA Section Templates

Several section templates have been developed specifically to supplement C-CDA. They are defined within the context of C-CDA Supplemental Guides that have been balloted and reconciled separately from C-CDA, and are published alongside the main C-CDA Specification
https://www.hl7.org/implement/standards/product_brief.cfm?product_id=492. These guides are developed with the intention of eventually replacing earlier version of the templates in C-CDA or eventually being added to be set of templates considered a part of the C-CDA set of templates.

At the time of this publication, the following Supplemental Implementation Guides are published alongside the C- CDA specification:

• C- CDA R2.1; Advance Directives Templates, Release 1 – US Realm
• HL7 CDA® R2 Implementation Guide: C-CDA R2.1 Supplemental Templates for Nutrition, Release 1 - US Realm
• HL7 CDA® R2 Implementation Guide: C-CDA R2.1 Supplemental Templates for Pregnancy Status, Release 1 - US Realm
• HL7 CDA® R2 Implementation Guide: C-CDA R2.1 Supplemental Templates for Occupational Data for Health Release 1, STU Release 1.1 – US Realm
• HL7 CDA® R2 Implementation Guide: C-CDA R2.1 Supplemental Templates for Infectious Disease, Release 1 – US Realm

New and Additional C-CDA Section Templates (Defined in this Companion Guide)

The following table defines new section templates defined within the context of this Companion Guide.

Table 33: New and Additional C-CDA Sections

Sections Defined in Other Implementation Guides

The table below summaries other section templates available by reference from C-CDA Supplemental IGs and CDA R2 IGs developed by other stakeholders in the C-CDA implementer community.

NOTE: The HL7 CDA Release 2 Implementation Guide: Additional CDA R2 Templates – Clinical Documents for Payers Set 1, Release 1 – US Realm specification indicates which document types SHALL include the more tightly constrained or additional templates required for exchanging information with payers using C-CDA documents.

The table also summarizes any tighter expectations for requiring other C-CDA sections to be included in the structured documents.^93 Implementation guides developed within the Payer C-CDA implementer community tighten the constrains on four existing sections and defines three new sections.

Implementers with the Payer and broader HIT C-CDA implementer community have started utilizing section templates defined by the Quality C-CDA implementer community to express and exchange information about care gaps that exist for individual patients. The templates used for this use case are re-used from the QRDA Cat I implementation guide.

Table 34: Sections defined in other Implantation Guides