Concise Consolidated CDA: Deploying Encounter Summary and Patient Summary Documents with Clinical Notes - March 2022
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Concise Consolidated CDA: Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
Executive Summary
In the Fall of 2017, the independent Carequality and CommonWell Content Work Groups were each
attempting to solve a set of similar issues: unacceptably large Consolidated Clinical Document
Architecture (C-CDA) documents, an absence of clinical notes in exchanged documents, support for
encounter summary documents, and the need for document version management. The initiatives
agreed to launch a Joint Document Content Work Group (JDCWG) in January 2018 with participants that
included clinicians, vendor representatives, and standards development representatives.
Since its inception, the group has reconvened periodically to address additional scope and revise this
document with additional guidance.
This white paper defines a path to improve the content in C-CDA exchange, while acknowledging the
realities of present day documentation and exchange practices. The intended audience of this guidance
is C-CDA implementers, product development teams, and software developers.
The recommendations resulting from this joint effort are summarized below, with links to the pertinent
section.
Generation and sharing of Patient and Encounter Summary Documents:
• 2.1.1: Implementers SHALL support the ability to generate and send Encounter Summary
Documents in addition to current Patient Summary Documents.
• 3: Encounter Summary Documents SHOULD be based upon the C-CDA template for Progress
Note (Outpatient/Ambulatory) or Discharge Summary (Inpatient/Hospital).
• 3.2, 3.3, 3.4: Implementers SHOULD incorporate Clinical Notes in C-CDA implementations.
• 3.1: Content in Encounter Summary Documents SHALL only reflect information at the time of
the encounter and reflect active: problems, allergies, medications, and immunizations as of the
end of the specified encounter.
• 3.1, 2.2.4: Implementers SHALL include a subset of the ONC Common Clinical Data Set / USCDI
V1 by default in an Encounter Summary Document, and only if that data was validated during
the encounter.
• 4.2: Implementers SHALL include a Section Time Range Observation for each section in Patient
Summaries and 3.1: SHOULD in Encounter Summaries.
• 2.6.3.2, 3: Implementers SHALL respond with all applicable encounter summary C-CDA
documents when they receive requests that specify a time range that spans multiple
encounters.
• 3.5.4: Implementers SHALL support sharing updates to Encounter Summary documents, to
include making known that updates are available when queried.
• 4.2: Content in current Patient Summary Documents SHALL reflect active: problems, allergies,
medications, and immunizations.
Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
• 4.2.3: Implementers MAY support the ability to populate entries in Patient Summary Documents
based on the date range requested.
• Throughout: Additional guidance is provided for implementers to receive and ingest these
documents, although it is less prescriptive.
Use of IHE Document Sharing mechanisms:
• 2.3.1, 2.3.2: The foundational IHE Document Sharing concepts are explained clearly: document
vs. document entry, metadata, and associations.
• 2.3.2.1, 2.3.4, 2.3.5: Guidance is provided for IHE mechanisms that support dynamic generation
of documents such as On-Demand, Delayed Document Assembly, and Deferred Response.
• 2.4: Mappings between the IHE XDS document metadata (which is returned on query) and the
content of the CDA document are fully specified.
Interoperable laboratory orders and results:
• 2.5.1: Guidance is provided for sharing laboratory orders and results through their lifecycle,
from order to completion, in Encounter and Patient Summary documents.
• 2.5.2: The group captured and analyzed pain points and challenges impacting lab result
interoperability, and devised a strategy for identifying actionable work items and working with
outside groups to move the bar.
• 2.5.2.6: Guidance is provided for including translations to harmonized codes.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD","SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in IETF
BCP 14.6.1
The next steps related to these recommendations are for Carequality and CommonWell representatives
to present them to their respective Steering Divisions to determine how to encourage implementation.
Additionally, these recommendations have been and will be shared with HL7 for possible inclusion in a
future version of C-CDA and/or the C-CDA Companion Guide. The Companion Guide has already
incorporated material from a prior version of this guide.
1 Best Current Practice 14 - available at: https://www.rfc-editor.org/info/bcp14
Page 1
Table of Contents
1 Introduction 6
1.1 Purpose and Scope 6
1.2 Audience 6
1.3 Background and Development Approach 7
1.3.1 Sources and Process 8
1.4 How to read this guide 9
1.4.1 Smart Senders and Resilient Receivers 10
2 General Guidance 11
2.1 Moving from just CCDs to a well-factored clinical view of a patient 11
2.1.1 Providing Patient and Encounter Summary Documents 11
2.1.2 Requesting Patient and Encounter Summary Documents 12
2.2 CDA Document Content Guidance 13
2.2.1 Smart Senders: Maintain proper references between coded values and narrative 13
2.2.2 Smart Senders: Maintain act/observation IDs across documents 15
2.2.3 Smart Senders: Reconciliation flag 15
2.2.4 Support for USCDI 16
2.2.5 No Information 16
2.2.6 Section Time Range Observation 16
2.3 Dynamic Generation of Documents (aka On Demand) 18
2.3.1 Basic IHE document sharing 19
2.3.2 Capability: Document Update Sharing 20
2.3.2.1 Capability: Stable Document Update Detection 22
2.3.3 Capability: Delayed Document Assembly Option 23
2.3.3.1 Capability: Delayed Document Assembly with Update Detection 24
2.3.4 Capability: On-Demand Option 25
2.3.4.1 Persistence of Retrieved Documents Option 26
2.3.4.2 Capability: On-Demand with Update Detection 27
2.3.4.3 Capability: On-Demand and Delayed Document Assembly with Update Detection 28
2.3.5 Capability: XCA Deferred Response Option 28
2.4 Mapping between XDS metadata and CDA header 29
2.4.1 Mapping date values to support service date range queries 30
2.4.2 Special Mappings for On-Demand Entries 31
2.5 Laboratory orders and results 31Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
2.5.1 Laboratory Test Lifecycle 31
2.5.1.1 Initial Lab Order 32
2.5.1.2 Lab Performed 32
2.5.1.3 Lab Cancelled 33
2.5.1.4 Lab Aborted 33
2.5.1.5 Tracking Labs from Order to Results 33
2.5.1.6 Tracking Labs Between Results 34
2.5.1.7 Tracking Lab Result Corrections 34
2.5.2 Interoperable Laboratory Results 34
2.5.2.1 Detailed Problems with Lab Interoperability 34
2.5.2.1.1 Lab values are vendor- or facility- specific codes or free text 34
2.5.2.1.2 Standardized translation available but at different level of abstraction; loss of
specificity 35
2.5.2.1.3 Requesting systems have different needs from codes (coarse-grained vs fine-
grained) 35
2.5.2.1.4 Reference range received from lab is non-standard 35
2.5.2.1.5 Range/Interpretation received from lab is specific to location of test 35
2.5.2.1.6 Codes, even if standard, can’t always be trended together 35
2.5.2.2 Groups Working on Lab Interoperability 35
2.5.2.3 Case Study: Epic / Sutter Health on Types of Code Mappings and Challenges 36
2.5.2.4 Workgroup Strategy 37
2.5.2.5 Creating Mappings 38
2.5.2.6 Performing Translations 39
2.6 Resilient Receivers: Querying, Retrieving and Displaying 40
2.6.1 Document Exchange Workflow Guidance 40
2.6.2 Receive and display any valid CDA document 43
2.6.3 Additional XDS Query Filtering Guidance 43
2.6.3.1 Filtering by coded values 43
2.6.3.2 Filtering by date/time range 45
2.6.3.2.1 Date range search, overlapping 46
2.6.3.2.2 All documents after a set date, overlapping 47
2.6.3.2.3 All documents before a set date, overlapping 47
Page 1Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
2.6.3.2.4 Date range search, non-overlapping – missing boundary documents 48
2.6.3.2.5 All documents after a set date, non-overlapping – missing boundary document 48
2.6.3.2.6 All documents before a set date, non-overlapping – missing boundary document 49
3 Encounter Summary Documents 50
3.1 Document Body Guidance 52
3.2 Outpatient/Ambulatory Summary (Progress Note Document) 53
3.3 Inpatient/Hospital Summary (Discharge Summary Document) 54
3.4 Clinical Notes 55
3.4.1 Common Clinical Note Types 56
3.4.2 Sending Clinical Notes in C-CDA 56
3.4.2.1 Note directly attached to the associated act 56
3.4.2.2 Note is in an appropriate section 58
3.4.2.3 Note in stand-alone Notes Section 59
3.4.3 Encounter Linking for Clinical Notes 60
3.4.4 Clinical Note Best Practices 62
3.5 When to Share Encounter Documents Through the Lifecycle 62
3.5.1 Sharing an Encounter that is in Progress 63
3.5.2 Sharing an Encounter that has Ended 63
3.5.3 Sharing Throughout the Encounter Lifecycle 64
3.5.4 Sharing Updates to an Encounter Summary 66
4 Patient Summary Documents 69
4.1 C-CDA Continuity of Care (CCD) Document Type 69
4.2 Generating the Current Patient Summary 70
4.2.1 Service dates for patient summaries in CDA and XDS 71
4.2.2 Populating sections based on default date ranges 72
4.2.3 Populating sections based on query date ranges 73
4.3 Smart Senders: Reducing the clutter of too many generated patient summary documents 75
77
A.1 Additional education material 77
A.2 Future Work 77
Page 2Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
Table of Figures
Figure 1 – A simple IHE XCA Query request, annotated ............................................................................. 13
Figure 2 – Example id root only .................................................................................................................. 15
Figure 3 – Example id root + extension....................................................................................................... 15
Figure 4 – Sample display of Section Time Range....................................................................................... 17
Figure 5 – Example of Section Time Range Observation ............................................................................ 18
Figure 6 IHE XDS Document entry and CDA document .............................................................................. 20
Figure 7 Document Replacement in XDS and CDA ..................................................................................... 21
Figure 8 Delayed Document Assembly in Practice ..................................................................................... 24
Figure 9 On-Demand Basic Functionality .................................................................................................... 25
Figure 10 On-Demand with Persistence of Retrieved Documents ............................................................. 26
Figure 11 On-Demand with Persistence and Association Support ............................................................. 27
Figure 12 – Translating to a preferred code ............................................................................................... 39
Figure 13 – Document Query ...................................................................................................................... 40
Figure 14 – Document Retrieval ................................................................................................................. 41
Figure 15 - Document Information Available during the IHE Query and in the stored C-CDA ................... 42
Figure 16 - Sample Document List Display .................................................................................................. 43
Figure 17 – Filtering on coded values in the IHE XDS Query request ......................................................... 43
Figure 18 – Filtering on Timespan Elements in the IHE XDS Query request ............................................... 45
Figure 19 – Progress Note Document Section Requirements .................................................................... 54
Figure 20 – Discharge Summary Document Section Requirements ........................................................... 55
Figure 21 Example of Note Directly Added to Associated Act .................................................................... 57
Figure 22 – Example of Note Attached to an Act ........................................................................................ 58
Figure 23 – Example of Note Added to an Appropriate Section................................................................. 59
Figure 24 – Example of Stand-alone Notes Section .................................................................................... 60
Figure 25 – Example of Encounter Linking with entryRelationship reference ........................................... 61
Figure 26 – Example of Encounter Linking with encounter nested ............................................................ 61
Figure 27 Sharing Throughout the Encounter Lifecycle .............................................................................. 64
Figure 28 Versioning from Requester's Perspective ................................................................................... 66
Figure 29 – VA Section Default Timespan Filters ........................................................................................ 73
Figure 30 – VA Section Query-influenced Timespan Filters........................................................................ 75
Page 3Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
Version History
Version Description
2.0 (current) Added document sharing details, dynamic generation, versioning, labs, pain points,
reorganized content. Renamed document from “Concise Consolidated CDA: Deploying
Encounter Summary CDA Documents with Clinical Notes” to reflect broader scope.
1.1 Clarified use of IHE query parameters, added conformance verbs, moved content to
appendix
1.0 Initial release
Acknowledgements
This guide was developed through a joint effort of Carequality and CommonWell.
Primary Editor Organization
Brett Marquard Federal Electronic Health Record Modernization (FEHRM) / WaveOne
Ed Donaldson OneRecord / Ready Computing
Joseph Lamy SSA / AEGIS.Net
The editors appreciate the collaborative efforts and commitment from all participants to improve the
quality of C-CDA documents. Original Work Group participants included those listed below. Many others
have added to the body of work since Version 1, and we thank you all for your time and contributions.
Contributor Organization
Alan Swenson Kno2
Anand Prabhu Mediportal
Ava Spetalnick Athenahealth
Becky Shoemaker Dignity Health
Benjamin Flessner Redox
Christopher Dickerson Carequality
Christopher J. Hills DoD / VA Interagency Program Office (IPO)
Corey Parker Greenway Health
Dana Grove Cerner
Dave Cassel Carequality
David Camitta MD, MS Dignity Health
David Parker MD DoD / VA Interagency Program Office (IPO) / Defined IT
Didi Davis The Sequoia Project
Elizabeth R. Ames Sutter Health
Eric Heflin eHealth Exchange
Farah Saeed eClinicalWorks
Holly Miller MD, MBA MedAllies
Page 4Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
Jason Goldwater Cedar Bridge Group
Jitin Asnaani CommonWell Health Alliance
Joe Wall MEDITECH
Justin Ware Epic
Kelly Bundy Surescripts
Leanna Evans Cerner
Lisa R. Nelson MaxMD
Lizz Restat Athenahealth
Luke Doles NY eHealth Collaborative
Madhav Darji eClinicalWorks
Margaret Donahue, MD US Department of Veterans Affairs
Marie Swall US Department of Veterans Affairs / JP Systems
Marty Prahl Social Security Administration
Mike Warner Cerner
Moti Mitteldorf Womba
Nick Knowlton Brightree
Rene Cabral-Daniels Community Care Network of Virginia
Robert “Bo” Fried, MD Eagle Physicians
Russ Ott DoD / VA Interagency Program Office (IPO) / Deloitte
Sandi Mitchell US Department of Veterans Affairs / JP Systems
Steven Lane, MD MPH Sutter Health
Therasa Bell Kno2
Virginia Yost US Department of Veterans Affairs / JP Systems
Page 5Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
1 Introduction
Carequality and the CommonWell Health Alliance are two industry initiatives committed to the seamless
exchange of healthcare information. This guide is the result of a joint development effort of the Content
Workgroups within each initiative to improve the content of Consolidated CDA exchange.
1.1 Purpose and Scope
This document provides guidance for generating and sharing Encounter Summary and Patient Summary
C-CDA Documents, including Clinical Notes. Because this document targets production exchanges and
implementers, it complements existing content and exchange standards by covering the intersection
of CDA content, document sharing mechanisms, and the underlying clinical data used to generate
documents. This guidance describes existing best practices as well as new solutions to “pain points”
brought forward by providers, vendors and other implementers.
A Clinical Note is narrative text a clinician wrote, dictated, or copied from other portions of the
patient’s chart. An Encounter Summary CDA document will include this Clinical Note (required)
plus other relevant sections with discrete data as generated by the system and/or included per
clinician instructions.
For guidance pertaining to document content, this document complements the Health Level Seven
(HL7) CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes STU Release 2.1, and the HL7
CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes R1 Companion Guide Release 2,
which primarily supports the requirements of the ONC 2015 Edition Certification Criteria (2015 Edition)
Certified Electronic Health Record Technology requirements. The guidance provided here will be
considered in future updates to C-CDA and the Companion Guide.
For guidance pertaining to document sharing, this document complements the Integrating the
Healthcare Enterprise (IHE) IT Infrastructure Technical Framework, specifically the XCA Query [ITI-38]
and XCA Retrieve [ITI-39] transactions that implement the “Pull” mechanism. Although there are other
ways of sharing C-CDA content besides Pull (Push, Subscriptions, Direct, FHIR), these sharing
mechanisms are out of scope in this version.
See section 1.3.1 for detailed references and links.
1.2 Audience
The primary audience of this guide is C-CDA implementers, product development teams, and software
developers. This guide provides detailed guidance for placement of clinical information in C-CDA, proper
exchange using IHE Document Sharing mechanisms, and best practices for system generators and
receivers. Software architects, business analysts, and policy managers can also benefit from
Page 6Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
understanding the preferred approach of supporting Encounter Summary documents in addition to
Patient Summary documents.
A note on technical detail: we provide best-practice guidance on HL7 C-CDA and IHE XDS/XCA that
presumes full knowledge of these technologies. Readers should not expect this guide to provide an
introduction to C-CDA or XDS/XCA, although it does try to explain some difficult concepts beyond the
source material.
1.3 Background and Development Approach
In the fall of 2017, the independent Carequality and CommonWell Content Work Groups were each
attempting to solve a set of similar issues: unacceptably large Consolidated Clinical Document
Architecture (C-CDA) documents, an absence of clinical notes in exchanged documents, support for
encounter summary documents, and the need for document version management. Participants from
both content work groups approached the Directors of Carequality and CommonWell to consider a
single joint effort to tackle these common issues. The Joint Document Content Work Group launched in
January 2018. Participants in the Joint Document Content Work Group included clinicians, vendor
representatives and participants involved in standards development.
The principles of the Joint Document Content Work Group were as follows:
1. Maintain an initiative agnostic perspective
2. The product of the work group should be a best practices document
1. Exact format to be determined
2. Carequality and CommonWell may reference document or incorporate into their
material
3. All final material will have joint branding or none
3. Development will occur in a single content work group
4. Initiatives will independently review and approve guidance
5. Any guidance developed may be transitioned over to HL7 for balloting and maintenance
The Joint Document Content Work Group set clinical and technical priorities in the first call as follows:
Clinical
1. Require Encounter-specific document support
1. Outpatient/Ambulatory Summary (Progress Note Document) with defined sections
2. Inpatient/Hospital Summary (Discharge Summary Document) with defined sections
2. Determine most frequently used Clinical Note types2 - develop examples for each to include in
encounter-specific documents
3. Develop guidance on Note placement within documents for generator and consumer
4. Require Patient Summary
1. Define patient-level (not encounter-specific) sections to always include
2 With support from our Argonaut colleagues!
Page 7Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
2. Future – Define default time ranges for each section
Technical
1. Develop guidance for document versioning
Prior to the launch of the Joint Document Content Work Group, each individual content work group
discussed tackling the size of exchanged CCDs by discussing appropriate content restriction by section. It
became clear that even improved filtering of a single patient CCD wouldn’t solve the information
overload for clinicians reviewing documents that could sometimes be over 1,000 pages in length.
The group focused on the importance of providing focused information to the clinician at the time they
need it. The group identified encounter-specific document support, including clinical notes, as the top
priority. Members felt that the information provided by clinical notes would provide critical
supplemental context to the discrete data they were currently getting in Patient Summary CCD
documents. They also felt that these notes should not be added to the already long Patient Summary
CCD documents they were receiving.
After the Joint Document Content Work Group finalized priorities, weekly calls were scheduled to
develop and review design approaches. Decisions were made through discussion and consensus without
the implementation of formal voting.
In its second iteration (for the 2.0 version of the document), the Work Group established and
prioritized a backlog of new work items, and continued with the same process as before. As items were
explored, some were combined and new issues came to light. Key items targeted for this version were:
1. Provide guidance for dynamic generation of documents
2. Provide guidance for sharing laboratory tests throughout the lab order-to-result lifecycle
3. Provide guidance for sharing interoperable laboratory codes, starting with COVID-19
4. Provide guidance for sharing encounters throughout the encounter lifecycle
5. Provide guidance for document versioning
6. Provide guidance for populating Patient Summaries with and without requested date ranges
7. Provide guidance for data provenance3
8. Address various pain points
1.3.1 Sources and Process
The Joint Document Content Work Group considered the C-CDA R2.1, C-CDA Companion Guide, and
relevant IHE profiles as the baseline for all discussions. As a guiding principle, the Joint Document
Content Work Group focused on providing complementary, not conflicting guidance.
3 The HL7 Basic Provenance guide had not been balloted in time to incorporate into this guide. Readers may access
it here. In addition, the Sequoia Data Usability Workgroup is addressing provenance.
Page 8Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
Referenced standards or guides pertaining to document content:
● Health Level Seven (HL7) CDA® R2 IG: C-CDA Templates for Clinical Notes STU Release 2.1
● HL7 CDA R2 IG: C-CDA Templates for Clinical Notes R1 Companion Guide, Release 1, Release 2
and Release 3 (ballot version only)
● ONC U.S. Core Data for Interoperability USCDI V1 and USCDI V2
Referenced standards or guides pertaining to document sharing:
Note that these references (and links in this guide) go to the latest versions, as they incorporate errata.
However, production exchanges typically depend on fixed versions. Consult the production exchange for
the exact versions required.
• Integrating the Healthcare Enterprise (IHE) IHE IT Infrastructure (ITI) Technical Framework,
Revision 18.0, July 30, 2021 – Final Text
o IHE XCA Query: ITI-38
o IHE XCA Retrieve: ITI-39
o Including the following IHE ITI options:
o IHE XDS.b Delayed Document Assembly Option. This guide extends it for use by IHE XCA
as well.
o IHE XCA On-Demand Documents Option, as defined in IHE XDS.b and XCA.
o IHE XCA Deferred Response Option, as defined in IHE XDS.b and XCA.
While this guide is complementary to these external guides and standards, it does not actually require
them. Organizations or exchanges adopting this guide will need to require them explicitly.
Release 2 of the C-CDA Companion Guide began to incorporate material from earlier versions of this
guide. In this version, we have factored out that common content and added references.
Starting in January 2018, the Joint Document Content Work Group met weekly to develop solutions to
the identified priorities. The presentations from each week reside in a shared Google drive folder,
resulting in the 1.0 and 1.1 versions of this guide. In February 2020, the group reconvened to create the
2.0 version of the guide. Its materials are available in a different shared Google drive folder.
1.4 How to read this guide
This guide is organized into the following sections:
• 1 Introduction (this section)
• 2 General Guidance This section explains the major concepts in this guide, including the overall
view of a patient consisting of a Patient Summary and a set of Encounter Summaries, IHE
document sharing, dynamic generation, and interoperable lab results.
• 3 Encounter Summary Documents This section provides details on how and when to generate
encounter summaries.
• 4 Patient Summary Documents This section provides details on how and when to generate
patient summaries.
Page 9Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
• Appendices Additional education material, future work.
1.4.1 Smart Senders and Resilient Receivers
Successful document exchange relies on layers of rules from CDA document specifications, C-CDA 2.1
specification, and the C-CDA 2.1 Companion Guide. Despite every effort by implementers, and the HL7
community, to document all the important topics for successful exchange, the Joint Document Content
Work Group discussed many other areas that would benefit from additional guidance.
Occasionally you will see a callout like this:
Resilient Receivers: Of the above attributes, class code is usually the most stable – in other words, a
system may have CCDs available that all have the CCD class code but are from different C-CDA
versions, i.e. format codes. To avoid missing documents, Requesting Systems SHOULD limit query
filtering of this type to class code or none at all, unless the responding system’s use of codes is well
understood. Client-side filtering can still be performed of the returned document entries.
The Smart Senders and Resilient Receivers sections and callouts are not an exhaustive list of best
practices, but instead are a list of the best practices that captured the group’s attention. Other topics
that would benefit from additional guidance are listed in the future work appendix.
Note that we are using the term “Sender” to mean the sender of CDA documents, and “Receiver” as the
receiver of them. In a “Pull” mechanism, the Receiver is the initiating/requesting/consuming system and
the Sender is the responding/generating/returning system.
Page 10Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
2 General Guidance
This section addresses overall issues, pain points and best practices.
2.1 Moving from just CCDs to a well-factored clinical view of a patient
With the advent of ONC Certified Electronic Health Record Technology (CEHRT) and the CMS EHR
Meaningful Use Program came an increase in the adoption of CDA documents. First, in the form of the
HITSP C32 and in later stages, the HL7 Consolidated-CDA (C-CDA). Each new CEHRT rule and C-CDA
version added additional data requirements. In the ONC certification rule, the 2015 Edition Health IT
Certification Criteria, the requirement to support the Common Clinical Dataset (CCDS) again increased
the amount of data reported in these documents, much of it in codified form. While this has been a
positive development it has also had some unintended side effects.
In the 2014 and 2015 Editions of the ONC Certification Criteria, patient health summary requirements
primarily referenced the CCD (Continuity of Care Document) template within the HL7 C-CDA standard.
As data requirements have increased, many vendors have taken to creating only CCDs and including as
much information as possible. This has led to the issue of unnecessarily large CCDs that may span
dozens of pages, which include information of limited value to the document recipient, and which most
providers do not have the time to review. This was a driving force behind the efforts of this workgroup
to improve the quality and focus of data being included.
Pain Point: I don't want to receive one document type (CCD) for all clinical
situations, when more specific types are available.
Pain Point: I don't want to receive bloated documents.
The primary mechanisms that address these pain points are:
• Express the minimum clinical view of a patient as a Patient Summary and a series of Encounter
Summaries.
• Employ query filtering to reduce both the size and the number of documents that are returned.
The following sections, 2.1.1 and 2.1.2, provide high level guidance for Responding and Requesting
systems to accomplish this. Later sections will provide more detailed guidance.
2.1.1 Providing Patient and Encounter Summary Documents
The Joint Document Content Work Group decided that in order for Responding
systems to provide a complete picture of a patient's history, they SHALL provide
access to, at a minimum, one Encounter Summary Document for each available
Page 11Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
encounter and a current Patient Summary Document, if they have control over
the documents they generate and/or return.
Encounter Summary Documents provide information about the patient used or generated during an
encounter, complementing the existing Patient Summary document exchanged by systems today. This
guide defines document types for Outpatient/Ambulatory encounters and Inpatient/Hospital
encounters. Patient Summary Documents provide the current information about a patient.
The meaning of "one Encounter Summary Document for each available encounter" is fully specified in
Section 3, Encounter Summary Documents. The meaning of "a current Patient Summary Document" is
fully specified in Section 4, Patient Summary Documents.
To help understand this decision, the Joint Document Content Work Group considered the following
scenario:
1. A clinician requests a patient’s historical visits from 9/1/2017-12/1/2017.
2. The patient had 3 visits during this time, so the system returns 3 individual Encounter Summary
Documents.
3. Each Encounter Summary Document includes the information (e.g. Medication List) at the
conclusion of that encounter.
Responding systems MAY share other document types as needed. This guide does not further specify
nor constrain them.
This guide assumes an IHE XDS document sharing “Pull” environment using the XCA profile to query and
retrieve documents. Responding systems SHALL support the FindDocuments query and all its
parameters (Note: this is already required by the IHE specifications).
2.1.2 Requesting Patient and Encounter Summary Documents
As Responding systems adopt this guidance, Requesting systems will be able to find these documents in
queries. Below is a minimal XCA document query request that should return all available document
entries for a patient: at least one patient summary and one encounter summary for each known
encounter. It may find additional historical documents as well. The requester may then selectively
choose which documents to retrieve. See section 2.6.1, Document Exchange Workflow Guidance.
The aspects of approved/deprecated and On-Demand are needed even for a simple query; they will be
covered later in section 2.
Page 12Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
urn:ihe:iti:2007:CrossGatewayQuery
...
'st3498702^^^&1.3.6.1.4.1.21367.2005.3.7&ISO'
('urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Approved')
('urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1')
('urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248')
Figure 1 – A simple IHE XCA Query request, annotated
There are additional query parameters which serve to reduce the set of available documents returned.
This guide does not require any particular combination of parameters; requesting systems MAY choose
which parameters they will support. More comprehensive guidance on query filtering is given in section
2.6.3.
2.2 CDA Document Content Guidance
2.2.1 Smart Senders: Maintain proper references between coded values and
narrative
Narrative text linking is extremely important for processing and validating CDA documents that include
machine-processable entries. The narrative text linkages are the mechanism that associate human-
Page 13Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
readable information in the narrative text of each section to the entries carrying that information for
machine processing. Without proper narrative text linking, it is impossible to accurately validate if the
machine-readable entries and the human-readable representation of that information accurately reflect
the same semantic meaning.
Resources for more information:
● How to create narrative text linking in sections that contain machine-processable entries.
● HL7 C-CDA Companion Guide sections 5.1.1 and 5.1.2.
● See narrative reference examples in the HL7 CDA Examples repository. Search on “narrative”.
Page 14Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
2.2.2 Smart Senders: Maintain act/observation IDs across documents
Many entries in C-CDA require an identifier4 (ID) on every entry. Maintaining consistent IDs enables
receivers who machine-process the documents to de-duplicate the information and accurately identify
data that has been previously reported.
The C-CDA Companion Guide recommends using consistent identifiers; this guide requires them. For any
entry where an ID is required, systems SHALL maintain consistent IDs whether sending the entry in an
Encounter Summary Document, a Patient Summary document or any other CDA document types.
When senders don’t maintain consistent identifiers, the following example issues may occur:
• The receiving system may not be able to identify a single Allergy sent in both the Patient
Summary and Encounter Summary and may present duplicate information to a user.
• Updates to a previously-retrieved entry, such as a retracted lab result, may be listed as two
distinct lab results.
• Duplicate or conflicting information may be perceived by clinical users as a failure of the
interoperability ecosystem.
When entry IDs are consistently maintained, the receivers who machine-process the data will be more
successful and accurate in parsing, de-duplicating, and updating external data; and the clinical user
acting on the external information will be more efficient and confident in their workflows.
As a reminder, the HL7 V3 II data type requires these identifiers to be globally unique.
…
Figure 2 – Example id root only
…
Figure 3 – Example id root + extension
2.2.3 Smart Senders: Reconciliation flag
Sending systems may indicate that a particular list was reconciled prior to sending, as specified by the
IHE PCC RECON Supplement. The Reconciliation Act Entry Content Module
(1.3.6.1.4.1.19376.1.5.3.1.1.24.3.1) provides the structure to indicate the information in a section has
4C-CDA R2.1 Companion Guide 5.1.4 Use of Consistent Identifiers
Page 15Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
been reconciled. Systems SHOULD consider including this act, or a similar indicator, to explicitly state a
list has been reconciled, but only if the system is confident a user reconciled the list. This SHOULD NOT
be included if a clinician simply reviewed the list and did not reconcile it.
2.2.4 Support for USCDI
In 2021, the ONC released the latest U.S. Core Data for Interoperability (USCDI V2), following USCDI V1,
which had been released in 2020.
When sharing a newly generated document, Responding systems SHALL support data classes defined in
USCDI V1, as required by each document type specification and constrained by this guide, and according
to the USCDI V1 definitions for the data, with the following exception: if a requirement in the USCDI
current published version conflicts with USCDI V1, Responding systems MAY conform to the newer
requirement.
When sharing a newly generated document, Responding systems SHOULD endeavor to support the
USCDI current published version.
Clinical Notes and Provenance are two data elements identified in the USCDI since V1 for immediate
inclusion in exchanged documents beyond the required CCDS data elements. These are valuable data
elements and should be exchanged to improve patient care. However, participants in the Joint Work
Group are concerned systems will dump Clinical Notes in their existing Patient Summary documents
making them even larger.
Instead, the Joint Document Content Work Group believes Clinical Notes will serve the clinician best by
providing them in the context of the encounter where they were created. When systems add support
for Clinical Notes they SHOULD also add support for Encounter Summary documents, and SHOULD
include relevant notes to the encounter only inside those documents (i.e. not in Patient Summaries).
This guidance is expanded in the document-type-specific sections of this guide.
2.2.5 No Information
When sharing a newly generated document, if no information is included for a required section,
Responding systems SHALL include a ‘No information’5 assertion.
2.2.6 Section Time Range Observation
In current exchanges, sending systems include varying amount of information in sections. For example,
one sender might include immunizations for the current encounter, while another might include all
immunizations on record for the patient. When an end-user reviews a section they may not know what
portion of the available data the sender included. HL7 introduced a new observation, the Section Time
5
HL7 example for sending ‘No Information’. See also the C-CDA Companion Guide section 5.1.6.
Page 16Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
Range Observation6, to communicate what is included in a section. It was balloted with the C-CDA
Companion Guide and is available for use in any existing C-CDA section.
The purpose statement from the Companion Guide: This observation represents the date and time
range of the information contained in a section. It is an optional entry and may be used in any section.
The Joint Document Content Work Group recommends all sections include this observation and
corresponding text. The text should be included underneath the section header and state either:
● The section includes all information for this encounter
● Or, the section includes information corresponding to a time range with a low and a high value
Figure 4 – Sample display of Section Time Range
6
C-CDA R2.1 Companion Guide Section Time Range Observation (2.16.840.1.113883.10.20.22.4.201:2016-06-01)
Page 17Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
Procedures for the Encounter
The section includes all Surgical Procedures and Surgical Procedure Notes Associated to the
encounter
...
...
Figure 5 – Example of Section Time Range Observation
2.3 Dynamic Generation of Documents (aka On Demand)
There is a great deal of confusion around the term “On-Demand”. Some implementers use the term to
refer to the IHE On-Demand mechanism, but others use it to refer to any content that is generated
dynamically at the time of query or retrieve. This section is intended to clarify and provide guidance for
all such mechanisms, so they may be chosen intelligently. Later sections provide guidance pertaining to
specific document types. For clarity, we will use the term “dynamic” in this guide to refer to any content
that is generated in response to a request. The IHE On-Demand mechanism is one example of this.
Part of the confusion around dynamic documents is that they touch upon many underlying document
sharing mechanisms, so we will walk through those first.
Page 18Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
2.3.1 Basic IHE document sharing
IHE document sharing (described in detail here) consists of a family of profiles that enable sharing
documents and their metadata. This guide references the following:
• XDS, historically called XDS.b. This enables sharing documents in a well-controlled domain,
referred to as an “affinity domain”. XDS establishes all the basic mechanisms: document
metadata, error reporting, and “Pull” messages for querying and retrieving documents.
• XCA, which leverages XDS to share documents in a “Pull” fashion between different
“communities”. XCA is used by both Carequality and CommonWell as the basis for document
exchange.
The first key to understanding dynamic generation is understanding documents and document entries,
because all of the complexity has to do with when and how these are created.
• Document: A clinical document, related to a single patient. Usually a structured CDA variant, but
IHE supports any kind of document.
• Stable Document Entry: Information (called metadata) about a single document, for example:
the date the document was created, the author, and where the document is stored. For CDAs,
this information mostly corresponds to data in the CDA header.
o An entry has status of Approved (for clinical exchange) or Deprecated.
o An entry can be stable or on-demand; on-demand will be explained later.
The XCA document sharing workflow starts after the requesting system has located a patient it wants
clinical information for. It queries (using ITI-38) for document entries, chooses which documents to
retrieve, then retrieves (using ITI-39) the documents of interest. Often there is no explicit choice – all
available documents are retrieved. Note that in most cases, only Approved status is queried – this allows
the Requesting System to avoid the clutter of deprecated documents.
ITI-38, Cross Gateway Query, has multiple kinds of queries for different kinds of metadata. The primary
query used is FindDocuments, which supports a handful of filters and returns matching document
entries for a patient.
In the simplest case for the responding system, nothing is dynamic. The document is created first, then
the entry to describe it. This can be based on a trigger in an EHR, for example, completing an encounter,
or based on user action. Here is the state in the responding system at the time of query:
Page 19Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
Figure 6 IHE XDS Document entry and CDA document
The key thing to notice is that the document entry includes the size and hash of the document.
Note that the responding system could dynamically create both the document and its entry at the time
of the query. Because this doesn’t appear any different to the requester, this case is not explored
further.
2.3.2 Capability: Document Update Sharing
Requesting systems MAY support the Document Update Sharing capability, as specified in this section.
Note that while lack of support will not prevent accessing all available documents, it will prevent
discovering how documents relate.
Responding systems that dynamically generate documents SHALL support the Document Update Sharing
capability, as specified in this section.
Pain Point: When I discover an updated document, sometimes I need to know
how it relates to prior versions, ideally without having to retrieve the documents.
There are many situations where a document may be updated. For example, receiving a pending lab
result or a missing note may trigger an update. The base CDA standard provides a mechanism to replace
or append a previous document through the parentDocument relationship. The HL7 C-CDA R2.1
Companion Guide describes this scenario, with examples, in the section: 2.8 Options for Temporarily
Unavailable Data.
The document update capability as defined in this section adds to the CDA relationship described above.
It consists of the following:
• A relationship conveyed in the new CDA document’s header that references the prior
document. This can be a full replacement of the document or an appendix to it. The setId and
versionNumber elements are not necessary to convey an update, but may be used to convey
explicit version numbering.
• A relationship conveyed in XDS metadata, where if the update is a replacement the replaced
Page 20Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
document entry is marked deprecated, and an association links the document entries of the
original and the update.
Document updates use a specific kind of XDS metadata called associations that relate other metadata
objects. In XCA, support for associations is optional. This guide focuses on associations between
document entries, for example, where one document replaces another:
Figure 7 Document Replacement in XDS and CDA
The replaced document entry is marked as deprecated.
Resilient Receivers: In IHE XCA, association objects are not required to be supported by Responding
Gateways (although this section requires them). However, Responders that do not support
associations typically will at least reflect replacement by deprecating prior versions of document
entries. Resilient receivers that limit their usual queries to Approved availability status will only see
the latest document entries, not prior versions.
Also, note that the replacement association can be discovered in two ways:
• In an association metadata object which may be obtained without retrieving, through other ITI-
38 queries: GetAll, GetAssociations, GetDocumentsAndAssociations, and GetRelatedDocuments.
• In the header of the replacement CDA document, which may be examined once the document is
retrieved.
To address the pain point, the group decided to require both of these forms of expressing the
Page 21Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
relationship.
Anecdotally, the workgroup learned that replacement is far preferable to appending:
• Few systems reported that they support appending.
• Discussions in the Structured Documents Workgroup and its Implementation-A-Thons revealed
much confusion about the right way to structure and version an appending document.
• Understanding an appendix requires the receiver to know about both documents, and this may
be difficult to ensure, given the plethora of ways to discover documents (querying, direct push,
etc.).
Responding systems that support Document Update Sharing SHALL support document replacement:
• When replacing a document, in the header of the new document, the Responder SHALL
populate the relatedDocument element with a typeCode of “RPLC” and identify the prior
document id.
• When replacing a document, in the XDS metadata, the Responder SHALL change the
AvailabilityStatus attribute of the prior document entry to Deprecated.
• When replacing a document, in the XDS metadata, the Responder SHALL share a “replace”
association as defined in IHE ITI TF-3: 4.2.2.2.3.
Responding systems that support Document Update Sharing MAY support document appending:
• When appending a document, in the header of the new document, the Responder SHALL
populate the relatedDocument element with a typeCode of “APND” and identify the prior
document id.
• When appending a document, in the XDS metadata, the Responder SHALL share an “append”
association as defined in IHE ITI TF-3: 4.2.2.2.1.
Responding systems that support Document Update Sharing SHALL support ITI-38 queries as follows:
• The Responder SHALL implement the related XDS queries: GetAll, GetAssociations,
GetDocumentsAndAssociations, and GetRelatedDocuments, returning association and
document objects.
• The Responder MAY support returning Submission Set and Folder objects in the GetAll query.
2.3.2.1 Capability: Stable Document Update Detection
Responding systems that support Document Update Sharing and generate documents dynamically
SHOULD support the Stable Document Update Detection capability, as specified in this section.7
7 [IHE ITI TF] Vol 1 Section 10.4.11.3, Case 1, says “If errors need to be corrected or updates are needed, they are
the responsibility of the source.” Besides IHE, implementers may have legal medical record requirements to make
corrections available. This capability handles that responsibility by simple document replacement.
Page 22Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
Pain Point: I need to know if the content of a document has changed.
Pain Point: If the content of a document has not changed, I don't want to receive
a brand new document if I request it again.
Pain Point: I don’t want to have to retrieve a document to know whether it’s
changed.
With this capability, requesters can see that updates are available without needing to retrieve the
document.
Each time a Responding system that supports Stable Document Update Detection generates a document
that uses this capability, it SHALL track the underlying content for future changes.
If and only if the underlying content of a tracked document changes, if there is an Approved stable
document entry corresponding to the previously generated document (i.e. containing its hash and size),
the Responding system SHALL replace that document entry with a new one.
This capability MAY be constrained by:
• Establishing what kinds of changes must result in a new version of the document.
• Establishing limits on how long a Responding system must continue tracking updates to a given
document.
2.3.3 Capability: Delayed Document Assembly Option
Requesting systems MAY support the Delayed Document Assembly Option, as specified in this section.
Note that unless requesters intend to check and validate hash and size, use of this option by responders
is invisible to requesters.
Responding systems MAY support the Delayed Document Assembly Option, as specified in this section.
Note: there are more specific requirements to support this elsewhere in this guide.
Pain Point: I don’t want to generate a document unless and until it’s requested.
The Delayed Document Assembly (DDA) Option is a simple dynamic mechanism: it allows the responder
to “lazily” generate the document only if and when it is retrieved.
• At document query, return a stable document entry with size = 0 and hash of a zero length file.
• At document retrieve, generate the document, return it, and update the document entry to
reflect the actual size and hash.
• For the most part, this difference is unimportant to the requester. The only exception is if the
requester wishes to validate the size and hash. They would just have to re-query for the stable
Page 23Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
entry after retrieving.
Figure 8 Delayed Document Assembly in Practice
The Delayed Document Assembly Option is defined in this guide as follows:
• The option as defined by the IHE ITI Technical Framework on the XDS.b profile, extended to the
XCA profile.8
• This option does not require any grouping with XDS.b actors.
Responding systems that support the Delayed Document Assembly Option SHALL:9
• Initially set creationTime to the time the document entry was created, or to the time the clinical
information was “frozen”.
• Update creationTime with the time of document generation, when updating size and hash.
2.3.3.1 Capability: Delayed Document Assembly with Update Detection10
Responding systems that support the Delayed Document Assembly Option SHOULD support the Update
Detection capability as specified in this section.
Responding systems that support Delayed Document Assembly with Update Detection SHALL support
the Document Update Sharing capability as specified in section 2.3.2.
Responding systems that support Delayed Document Assembly with Update Detection SHALL support
the Stable Document Update Detection capability as specified in section 2.3.2.1, constrained as follows:
8 We have opened Change Proposal CP-ITI-1271 with IHE ITI to add this to XCA.
9 The Delayed Document Assembly Option in IHE is unclear on the use and meaning of the required creationTime
attribute. We have opened Change Proposal CP-ITI-1272 with IHE ITI to clarify this, and the requirement above is
our current interpretation.
10 We have opened a Change Proposal with IHE to clarify update behavior for DDA.
Page 24Concise Consolidated CDA: Version 2.0
Deploying Encounter Summary and Patient Summary Documents with Clinical Notes March 2022
• When replacing a document entry due to a change in the underlying content of a tracked
document, the new document entry MAY utilize Delayed Document Assembly.
Note: The above requirement allows the Responder to return the same new stable document entry in
subsequent queries even If content is still changing, as long as the document has not yet been
generated.
2.3.4 Capability: On-Demand Option
Requesting systems SHALL support the On-Demand Option, as specified in this section. This is needed to
prevent loss of information, because On-demand entries are not returned in queries unless asked for.
Note that Carequality requires support already.
A requesting system that supports the On-Demand Option SHALL request both On-Demand and Stable
document entries (see example in section 2.1.2), unless it is exercising a use case that requires targeted
query of only On-Demand or Stable.
Responding systems MAY support the On-Demand Option, as specified in this section. Note: there are
more specific requirements to support this elsewhere in this guide.
Pain Point: I don’t want to generate a document unless and until it’s requested.
The On-Demand Option is a dynamic mechanism addressing the same pain point as Delayed Document
Assembly, in that a document isn’t created until it is retrieved. What makes On-Demand different is that
it introduces the On-Demand document entry, which represents the potential document separately
from each generated document. In its most basic form, the On-Demand entry is simply a handle that
retrieves the latest content. This makes the mechanism a good match for content that is expected to
change often, like a current Patient Summary.
Figure 9 On-Demand Basic Functionality
Page 25You can also read
