PACIO Transitions of Care Implementation Guide
1.0.0 - STU 1 US

PACIO Transitions of Care Implementation Guide - Local Development build (v1.0.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

## PACIO Transitions of Care Implementation Guide

Official URL: http://hl7.org/fhir/us/pacio-toc/ImplementationGuide/hl7.fhir.us.pacio-toc | Version: 1.0.0
IG Standards status: Trial-use | Maturity Level: 2 | Computable Name: PACIOTransitionsOfCare

### Background

The purpose of the Post-Acute Care Interoperability (PACIO) Project’s Transitions of Care (ToC) Implementation Guide is to provide a standards-based solution to support care transitions and coordination for patients across Long-Term Post-Acute Care (LTPAC) settings. The traditional Post-Acute Care (PAC) settings, Home Health, Skilled Nursing, Long Term Care Hospitals, and Inpatient Rehab facilities employ many types of clinicians, practitioners, therapists, and allied professionals who each require different information to provide the highest value and most efficient services to their patients. This information may includestandardized assessments, patient preferences, observations, and other important data. Many of these items are valuable during a transition of care from one setting to another, including settings outside of Post-Acute Care such as Acute Inpatient or the Emergency Department. This critical information, when it has been documented, is often not exchanged, resulting in gaps in care information during initial assessments and reassessments in new or parallel settings. By documenting this information as discrete coded data elements that is human- and machine-readable at the transition of care it can be exchanged and consumed by the recipient system. This results in reduced provider burden, as well as minimized transcription and associated errors. In addition, some specific data is more relevant to certain care roles, however, patient data at transfer are never available as a specific role-based data set. Coded data can be grouped in a specified role based fashion aiding the responsible caregivers at transition. When patient transition information is printed, faxed, or arrives electronically as human-readable only, this leads directly to potentially unsafe transition and coordination of care for these most vulnerable patients.

The Centers for Medicare and Medicaid Services (CMS) Data Element Library (DEL) provides the reference data (questions and answers) as coded data for key quality instruments in post-acute care, notably the Minimum Data Set (MDS) and Outcome and Assessment Information Set (OASIS). Today, most if not all information that could help inform the completion of these assessments is captured at the referral source but is either not transferred at all or is not transferred in a manner that can be meaningfully presented to the post-acute provider. Without this context and properly mapped information, providers in PAC settings are piecing together information through clinical observation or laborious review of narrative and other documentation that accompanies a referral. The challenge is similar outside of these instruments—stretching into areas like Advance Healthcare Directives or Personal Care preferences.

### Why PACIO

The PACIO Project is a collaborative effort to advance interoperable health data exchange between PAC and other providers, patients, and key stakeholders across health care and to promote health data exchange in collaboration with policy makers, standards organizations, and industry through a consensus-based, use case-driven approach. The primary goal of the PACIO Project is to establish the technical foundation for data exchange within PAC and partner organizations across the spectrum of care. It seeks to do so by creating a framework for and community through the development of Fast Healthcare Interoperability Resource (FHIR®) technical implementation guides (IGs) and reference implementations that will facilitate health data exchange through standards-based use case-driven application programming interfaces (APIs). Information covered in this IG is relevant to providers across the spectrum of patient care, including acute, sub-acute, and long-term post-acute care (LTPAC), and specifically designed for all roles within healthcare. The PACIO community brings together healthcare providers with a deep understanding of patient functioning, healthcare workflows and health information technology that makes them uniquely suited to author this IG. This understanding comes out of each author's:

- goal of helping individuals in these settings return to living in their homes and communities.
- knowledge of the activities that individuals need to perform and how to help them regain the ability to perform these activities by leveraging the necessary treatments and supports.
- desire to decrease the burden of care and ineffective transitions while increasing the value of the patient care delivered.

### Scope and Domains

#### Scope

The scope of this guide is intentionally broad, as the nature of specific conditions and the disciplines required to care for them require varying sets of information. This guide relies predominantly upon the existing body of work supported by the PACIO Project using CMS’s data element library and using these structures to define key pieces of information needed by a post-acute provider receiving a referral.

- CMS Data Element Library
- PACIO Personal Functioning and Engagement
- Personal Health Records
- FHIR Composition

#### Alignment with other Standards

- To represent Consolidated CDA Templates for Clinical Notes (C-CDA) 2.1 templates using FHIR profiles.
- This first stage of the project defines all the C-CDA document-level profiles on the Composition resource and contained sections.
- Any coded data used by sections will be represented using relevant U.S. Core FHIR profiles where they exist. FHIR profiles defined by other work groups or unconstrained FHIR resources may also be referenced if no appropriate US Core Profile exists.
- For further information see the latest C-CDA (HL7 CDA® R2 Implementation Guide: Consolidated CDA Templates for Clinical Notes, Edition 4 - US Realm) here.

### The IMPACT act

One impetus for this IG is the amendment to the Social Security Act in 2014 to include the Improving Medicare Post-Acute Care Transformation (IMPACT) Act. The IMPACT Act requires the standardization and interoperability of patient assessments in specific categories for PAC settings, including long-term care hospitals (LTCHs), home health agencies (HHAs), skilled nursing facilities (SNFs), and inpatient rehabilitation facilities (IRFs). It focuses on the standardization of data elements in specified quality measure and patient assessment domains for cross-setting comparison and clinical information exchange. The Act requires:

- Reporting of standardized patient assessment data through commonly used PAC assessment instruments:
  - Minimum Data Set (MDS) for SNFs
  - Inpatient Rehabilitation Facility – Patient Assessment Information (IRF – PAI) for IRFs
  - LTCH Continuity Assessment Record and Evaluation (CARE) Data Set (LCDS) for LTCHs
  - Outcome and Assessment Information Set (OASIS) for HHAs
- Implementation of domain-specific data elements as standardized, coded, machine- and human-readable values nested within the PAC assessment instruments required for submission by SNF, IRF, LTCH, and HHA providers.

These standardization requirements enable interoperable data exchange among PAC providers and other care settings, using common standards and definitions to support access to longitudinal patient information and facilitate coordinated care transitions.

### How to read this guide

This Guide is divided into several pages which are listed at the top of each page in the menu bar.

- Home: The home page provides the introduction and background information to set context for the use of the HL7 FHIR® Transitions of Care Implementation Guide.

- Guidance:

  - General Guidance: This section describes the purpose and structure of the transitions of care document. It provides evidence-based context for why standardized post-acute care transitions matter, and defines each section of the Transitions of Care composition — including its clinical scope, applicable LOINC code, and usage notes to guide implementers in populating it correctly.

  - Use Cases, Personas, and Scenarios: This section grounds the technical standards in real-world context by describing the roles, situations, and goals that this guide is designed to support. Personas represent the key people involved in post-acute care transitions — such as intake staff, care team members, and medical records teams — while scenarios illustrate how those transitions unfold in practice, for example when a patient moves from a skilled nursing facility to a home health agency. Use cases then translate these real-world situations into the specific technical interactions between systems and actors needed to achieve a successful transition of care.

  - Formal Specification: Information about conformance to the guide including Must Support requirements, document signatures, and document workflow.

  - Discipline-Specific Information: The discipline-specific information contains the select list of Centers for Medicare and Medicaid Services (CMS) data element library (DEL) information that is rated high importance by seven different role types across post-acute care settings.

  - Security, Privacy, and Consent: General security requirements and recommendations for ToC IG actors.

  - Underlying Technologies: Information about the terminologies, notations, and design principles, specific to FHIR, that this specification uses.

- FHIR Artifacts: These sections provide detailed descriptions and formal definitions for all the FHIR objects defined in this guide.

  - Profiles: This section lists the set of Profiles that are defined in this guide to exchange TOC information. Each linked Profile page includes a narrative introduction and a formal definition.

  - Terminology Value Sets: This section lists the value sets and code system defined for TOC Implementation Guide profiles.

  - Terminology Local Code Systems: This section includes local codes assigned to specific TOC CodeableConcepts where no suitable term exists in standard healthcare terminologies or controlled vocabularies. These codes will be replaced once new term requests are approved by the relevant terminology standard organization.

  - Search Parameters and Operations: This section lists the Transitions of Care Implementation Guide defined Operations and Search Parameters that are used in TOC transactions.

  - Capability Statement: This artifact defines the specific capabilities that different types of systems are expected to have in order to comply with this guide. Systems conforming to this guide are expected to declare conformance with this capability statement.

- Examples: The section that contains examples of transitions of care information that is conformant to the profiles of this guide.

  - ToC Example: This example provides a narrative description of a patient scenario and associates FHIR resources for ease of use.

- Change Log: A summary of IG changes and resolved ballot issues.

- Downloads: This page provides links to downloadable artifacts.

### Authors and Contributors

- Shelly Coyle - CMS
- Dave Hill - Global Alliant
- Yolanda Liu - MITRE Corporation
- Holly Miller, MD - Centauri Health Solutions
- Terrence O'Malley, MD
- James Patterson - MITRE Corporation
- May Terry - MITRE Corporation
- Lorraine Wickiser - CMS

The authors also recognize HL7 sponsorship and input from the HL7 Patient Care Working Group.

### Global Profiles

There are no Global profiles defined

### Package Dependencies

IG | Package | FHIR | Comment
--- | --- | --- | ---
PACIO Transitions of Care Implementation Guide | hl7.fhir.us.pacio-toc#1.0.0 | R4 |
HL7 Terminology (THO) | hl7.terminology.r4#7.1.0 | R4 | Automatically added as a dependency - all IGs depend on HL7 Terminology
FHIR Extensions Pack | hl7.fhir.uv.extensions.r4#5.2.0 | R4 |
PACIO Advance Directive Interoperability Implementation Guide | hl7.fhir.us.pacio-adi#1.0.0 | R4 |
US Core Implementation Guide | hl7.fhir.us.core#4.0.0 | R4 |
FHIR Bulk Data Access | hl7.fhir.uv.bulkdata#1.0.1 | R4 |
VSAC | us.nlm.vsac#0.3.0 | R4 |
HL7 Terminology (THO) | hl7.terminology#5.4.0 | R4 |
FHIR Extensions Pack | hl7.fhir.uv.extensions.r4#1.0.0 | R4 |
VSAC | us.nlm.vsac#0.15.0 | R4 |
PACIO Personal Functioning and Engagement Implementation Guide | hl7.fhir.us.pacio-pfe#2.0.0 | R4 |
HL7 Terminology (THO) | hl7.terminology.r4#6.5.0 | R4 |
US Core Implementation Guide | hl7.fhir.us.core#6.1.0 | R4 |
HL7 Terminology (THO) | hl7.terminology.r4#5.0.0 | R4 |
Bulk Data Access IG | hl7.fhir.uv.bulkdata#2.0.0 | R4 |
SMART App Launch | hl7.fhir.uv.smart-app-launch#2.1.0 | R4 |
VSAC | us.nlm.vsac#0.11.0 | R4 |
Structured Data Capture | hl7.fhir.uv.sdc#3.0.0 | R4 |
PHINVads | us.cdc.phinvads#0.12.0 | R4 |
IHE FormatCode Vocabulary | ihe.formatcode.fhir#1.1.0 | R4 |
SDOH Clinical Care | hl7.fhir.us.sdoh-clinicalcare#2.2.0 | R4 |
HL7 Terminology (THO) | hl7.terminology.r4#6.0.2 | R4 |
FHIR Extensions Pack | hl7.fhir.uv.extensions.r4#5.1.0 | R4 |
US Core | hl7.fhir.us.core#3.1.1 | R4 |
Subscriptions R5 Backport | hl7.fhir.uv.subscriptions-backport.r4#1.1.0 | R4 |
VSAC | us.nlm.vsac#0.19.0 | R4 |
Standardized Medication Profile (SMP) FHIR IG | hl7.fhir.us.smp#1.0.0 | R4 |
HL7 Terminology (THO) | hl7.terminology.r4#6.3.0 | R4 |
VSAC | us.nlm.vsac#0.21.0 | R4 |
US Core Implementation Guide | hl7.fhir.us.core#8.0.1 | R4 |
HL7 Terminology (THO) | hl7.terminology.r4#7.0.0 | R4 |
SMART App Launch | hl7.fhir.uv.smart-app-launch#2.2.0 | R4 |
HL7 Terminology (THO) | hl7.terminology#5.5.0 | R4 |
VSAC | us.nlm.vsac#0.24.0 | R4 |
International Patient Summary Implementation Guide | hl7.fhir.uv.ips#2.0.0 | R4 |
International Patient Access | hl7.fhir.uv.ipa#1.1.0 | R4 |
HL7 Terminology (THO) | hl7.terminology.r4#6.2.0 | R4 |
SMART App Launch | hl7.fhir.uv.smart-app-launch#2.0.0 | R4 |
Dental Data Exchange | hl7.fhir.us.dental-data-exchange#1.0.0 | R4 |
C-CDA on FHIR | hl7.fhir.us.ccda#1.1.0 | R4 |
US Core | hl7.fhir.us.core#3.1.0 | R4 |
Da Vinci Health Record Exchange (HRex) | hl7.fhir.us.davinci-hrex#0.1.0 | R4 |
US Core R4 | hl7.fhir.us.core#3.0.0 | R4 |
HL7 FHIR Profile: Occupational Data for Health (ODH), Release 1.0 (Standard for Trial Use) | hl7.fhir.us.odh#1.0.0 | R4 |
HL7 Terminology | hl7.terminology#1.0.0 | R4 |
C-CDA on FHIR | hl7.fhir.us.ccda#1.2.0 | R4 |
HL7 Terminology (THO) | hl7.terminology.r4#5.3.0 | R4 |
FHIR Tooling Extensions IG | hl7.fhir.uv.tools.r4#1.1.2 | R4 | for example references

Package hl7.fhir.uv.extensions.r4#5.2.0 This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Mon, Feb 10, 2025 21:45+1100+11:00)

Package hl7.fhir.us.core#4.0.0 The US Core Implementation Guide is based on FHIR Version R4 and defines the minimum conformance requirements for accessing patient data. The Argonaut pilot implementations, ONC 2015 Edition Common Clinical Data Set (CCDS), and ONC U.S. Core Data for Interoperability (USCDI) v1 provided the requirements for this guide. The prior Argonaut search and vocabulary requirements, based on FHIR DSTU2, are updated in this guide to support FHIR Version R4. This guide was used as the basis for further testing and guidance by the Argonaut Project Team to provide additional content and guidance specific to Data Query Access for purpose of ONC Certification testing. These profiles are the foundation for future US Realm FHIR implementation guides. In addition to Argonaut, they are used by DAF-Research, QI-Core, and CIMI. Under the guidance of HL7 and the HL7 US Realm Steering Committee, the content will expand in future versions to meet the needs specific to the US Realm. These requirements were originally developed, balloted, and published in FHIR DSTU2 as part of the Office of the National Coordinator for Health Information Technology (ONC) sponsored Data Access Framework (DAF) project. For more information on how DAF became US Core see the US Core change notes. (built Mon, Jun 28, 2021 19:09+0000+00:00)

Package hl7.fhir.uv.extensions.r4#1.0.0 This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sun, Mar 26, 2023 08:46+1100+11:00)

Package hl7.fhir.us.pacio-adi#1.0.0 PACIO Advance Directive Interoperability Implementation Guide (built Thu, Jan 11, 2024 17:40+0000+00:00)

Package hl7.fhir.uv.bulkdata#2.0.0 FHIR based approach for exporting large data sets from a FHIR server to a client application (built Fri, Nov 26, 2021 05:56+1100+11:00)

Package hl7.fhir.uv.sdc#3.0.0 The SDC specification provides an infrastructure to standardize the capture and expanded use of patient-level data collected within an EHR. This includes two components: * Support more sophisticated questionnaire/form use-cases such as those needed for research, oncology, pathology and other clinical domains. *Support pre-population and auto-population of EHR data into forms/questionnaires for uses outside direct clinical care (patient safety, adverse event reporting, public health reporting, etc.). (built Tue, Mar 8, 2022 18:32+0000+00:00)

Package ihe.formatcode.fhir#1.1.0 Implementation Guide for IHE defined FormatCode vocabulary. (built Thu, Feb 24, 2022 16:55-0600-06:00)

Package hl7.fhir.us.core#6.1.0 The US Core Implementation Guide is based on FHIR Version R4 and defines the minimum conformance requirements for accessing patient data. The Argonaut pilot implementations, ONC 2015 Edition Common Clinical Data Set (CCDS), and ONC U.S. Core Data for Interoperability (USCDI) v1 provided the requirements for this guide. The prior Argonaut search and vocabulary requirements, based on FHIR DSTU2, are updated in this guide to support FHIR Version R4. This guide was used as the basis for further testing and guidance by the Argonaut Project Team to provide additional content and guidance specific to Data Query Access for purpose of ONC Certification testing. These profiles are the foundation for future US Realm FHIR implementation guides. In addition to Argonaut, they are used by DAF-Research, QI-Core, and CIMI. Under the guidance of HL7 and the HL7 US Realm Steering Committee, the content will expand in future versions to meet the needs specific to the US Realm. These requirements were originally developed, balloted, and published in FHIR DSTU2 as part of the Office of the National Coordinator for Health Information Technology (ONC) sponsored Data Access Framework (DAF) project. For more information on how DAF became US Core see the US Core change notes. (built Fri, Jun 30, 2023 14:02+0000+00:00)

Package hl7.fhir.uv.extensions.r4#5.1.0 This IG defines the global extensions - the ones defined for everyone. These extensions are always in scope wherever FHIR is being used (built Sat, Apr 27, 2024 18:39+1000+10:00)

Package hl7.fhir.uv.subscriptions-backport.r4#1.1.0 The Subscription R5 Backport Implementation Guide enables servers running versions of FHIR earlier than R5 to implement a subset of R5 Subscriptions in a standardized way. (built Wed, Jan 11, 2023 15:34+1100+11:00)

Package hl7.fhir.us.sdoh-clinicalcare#2.2.0 This HL7 Implementation Guide (IG) defines how to exchange Social Determinants of Health (SDOH) content defined by the Gravity Project using the HL7 FHIR standard.. (built Tue, Aug 27, 2024 16:48+0000+00:00)

Package hl7.fhir.us.pacio-pfe#2.0.0 FHIR Implementation Guide to exchange assessments of and data on a person's functioning, including body functions, activities, and participation, between post-acute care (PAC) and other providers, patients, and key stakeholders (built Wed, Jul 23, 2025 17:08+0000+00:00)

Package hl7.fhir.us.smp#1.0.0 Guidelines for conveying coverage requirements to clinicians when planning treatment. (built Fri, May 16, 2025 20:17+0000+00:00)

Package hl7.fhir.us.core#8.0.1 The US Core Implementation Guide is based on FHIR Version R4 and defines the minimum conformance requirements for accessing patient data. The Argonaut pilot implementations, ONC 2015 Edition Common Clinical Data Set (CCDS), and ONC U.S. Core Data for Interoperability (USCDI) v1 provided the requirements for this guide. The prior Argonaut search and vocabulary requirements, based on FHIR DSTU2, are updated in this guide to support FHIR Version R4. This guide was used as the basis for further testing and guidance by the Argonaut Project Team to provide additional content and guidance specific to Data Query Access for purpose of ONC Certification testing. These profiles are the foundation for future US Realm FHIR implementation guides. In addition to Argonaut, they are used by DAF-Research, QI-Core, and CIMI. Under the guidance of HL7 and the HL7 US Realm Steering Committee, the content will expand in future versions to meet the needs specific to the US Realm. These requirements were originally developed, balloted, and published in FHIR DSTU2 as part of the Office of the National Coordinator for Health Information Technology (ONC) sponsored Data Access Framework (DAF) project. For more information on how DAF became US Core see the US Core change notes. (built Wed, Dec 10, 2025 03:47+0500+05:00)

Package hl7.fhir.uv.ipa#1.1.0 This IG describes how an application acting on behalf of a patient can access information about the patient from an clinical records system using a FHIR based API. The clinical records system may be supporting a clinical care provider (e.g. a hospital, or a general practitioner), or a health data exchange, including a national health record system. (built Wed, Mar 19, 2025 14:34+0000+00:00)

Package hl7.fhir.us.ccda#1.1.0 Consolidated CDA (C-CDA) is one of the most widely implemented implementation guides for CDA and covers a significant scope of clinical care. Its target of the 'common/essential' elements of healthcare is closely aligned with FHIR's focus on the '80%'. There is significant interest in industry and government in the ability to interoperate between CDA and FHIR and C-CDA is a logical starting point. Implementers and regulators have both expressed an interest in the ability to map between FHIR and C-CDA. This Implementation Guide (IG) defines a series of FHIR profiles on the Composition resource to represent the various document types in C-CDA. This release does not directly map every C-CDA template to FHIR profiles, rather tries to accomplish the C-CDA use case using Composition resource profiles created under this project (the equivalent of Level 2 CDA documents), and begins by linking to the profiles created under the US Core project for any coded entries that would normally be included in C-CDA sections. To have a simpler, more streamlined standard that reuses existing work and focuses on the 80% that implementers actually need in production systems, the resources of US Core represents a portion of the 80% needed for coded entries for coded entries of CCD, Care Plan & Discharge Summary). The Composition profiles in this IG do not require coded data in any section. This is a departure from C-CDA, which requires coded data for Problems, Results, Medications, etc. This departure is intentional, as the C-CDA requirement for one or more coded entries in these sections resulted in some very complicated workarounds using nullFlavors to handle the fact that sometimes a patient is not on any medications, or has no current problems. In general, FHIR takes the approach that if something is nullable, it should simply be optional to ease the burden on implementers, thus C-CDA on FHIR does not require any coded entries, but rather uses the "required if known" approach, meaning that if an implementer's system has data for a section that requires data under Meaningful Use, they need to send it, but if they have no data there is no need for a null entry. We encourage feedback on these Composition profiles, and the general approach to the project as a whole. We also encourage implementers who wish to see more of the coded data from C-CDA mapped to FHIR to comment on the US Core project and make their requests known there. Once US Core creates new profiles, this project can reference them. ## Scope To represent Consolidated CDA Templates for Clinical Notes (C-CDA) 2.1 templates using FHIR profiles. This first stage of the project defines all the C-CDA document-level profiles on the Composition resource and contained sections. Any coded data used by sections will be represented using relevant U.S. Core FHIR profiles where they exist. FHIR profiles defined by other work groups or unconstrained FHIR resources may also be referenced if no appropriate US Core Profile exist. For further information see the C-CDA specification here: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=408. (built Wed, Oct 21, 2020 22:01+0000+00:00)

Package hl7.fhir.us.davinci-hrex#0.1.0 The Da Vinci Payer Health Record exchange (HRex) Framework/library specifies the FHIR elements used in multiple Da Vinci implementation guides. This includes FHIR profiles, functions, operations, and constraints on other specifications such as CDS-Hooks and other aspects of Da Vinci Use Cases that are common across more than a single use case. Da Vinci HRex Implementation Guide (IG) will make use of US Core profiles that are based on the FHIR R4 specification wherever practical. The HRex IG will use the HL7 FHIR Release 4/US Core STU3 specification as its base but will provide additional guidance and documentation to support implementations that follow the HL7 FHIR STU3/US Core STU2 and HL7 FHIR DSTU2/Argonaut specifications. The HRex profiles documented in this IG will be used to exchange data between providers systems (e.g. EHRs) and other providers, payers, and third-party applications were appropriate. In addition, exchanges from payer systems to providers, other payers, and third-party applications are supported by the HRex profiles and operations. HRex may define new extensions, profiles, value sets, constraints/extension to other specification (e.g. specific CDS-Hooks) that are specific Da Vinci requirements. Where appropriate these Da Vinci specific artifacts will be promoted for incorporation into the future versions of existing standards (e.g. R4 US Core profiles) and deprecated in this guide on publication in the updated standard. (built Thu, Jun 20, 2019 08:10-0400-04:00)

Package hl7.fhir.us.dental-data-exchange#1.0.0 This implementation guide provides HL7 FHIR resources to define standards for bi-directional information exchange between a medical and a dental provider or between dental providers. This publication provides the data model, defined data items and their corresponding code and value sets specific to a dental referral note and dental consultation note. This guide describes constraints on the C-CDA on FHIR header and body elements for dental information, which are derived from requirements developed by the Dental Summary Exchange Project of the Health Level Seven (HL7) Payer/Provider Information Exchange Work Group (PIE WG). Resources in this US Realm implementation guide are specific to dental referral and consultation notes for exchange and interoperability among dental providers and with medical providers. This guide contains a library of FHIR profiles and is compliant with FHIR Release 4. At a minimum, a document bundle (C-CDA on FHIR Referral Note or Consultation Note) will be exchanged along with a ServiceRequest, Patient, and associated medical and dental information. This guide specifies how and where these resources are included within the C-CDA on FHIR profiles. This guide defines 7 new profiles: Dental Bundle Dental Referral Note Dental Service Request Dental Consult Note Dental Condition Dental Finding Dental Communication All proprietary documents, guides, guidance, standards, codes, and values contained herein remain the property of their respective Standards Developing Organization (SDO). HL7 does not make any claim to ownership herein. This HL7 FHIR® R4 Implementation Guide: Dental Data Exchange is developed in parallel to the HL7 CDA® R2 Implementation Guide: Dental Data Exchange. (built Tue, Nov 2, 2021 16:19+0000+00:00)

Package hl7.fhir.us.ccda#1.2.0 Consolidated CDA (C-CDA) is one of the most widely implemented implementation guides for CDA and covers a significant scope of clinical care. Its target of the 'common/essential' elements of healthcare is closely aligned with FHIR's focus on the '80%'. There is significant interest in industry and government in the ability to interoperate between CDA and FHIR and C-CDA is a logical starting point. Implementers and regulators have both expressed an interest in the ability to map between FHIR and C-CDA. This Implementation Guide (IG) defines a series of FHIR profiles on the Composition resource to represent the various document types in C-CDA. This release does not directly map every C-CDA template to FHIR profiles, rather tries to accomplish the C-CDA use case using Composition resource profiles created under this project (the equivalent of Level 2 CDA documents), and begins by linking to the profiles created under the US Core project for any coded entries that would normally be included in C-CDA sections. To have a simpler, more streamlined standard that reuses existing work and focuses on the 80% that implementers actually need in production systems, the resources of US Core represents a portion of the 80% needed for coded entries for coded entries of CCD, Care Plan & Discharge Summary). The Composition profiles in this IG do not require coded data in any section. This is a departure from C-CDA, which requires coded data for Problems, Results, Medications, etc. This departure is intentional, as the C-CDA requirement for one or more coded entries in these sections resulted in some very complicated workarounds using nullFlavors to handle the fact that sometimes a patient is not on any medications, or has no current problems. In general, FHIR takes the approach that if something is nullable, it should simply be optional to ease the burden on implementers, thus C-CDA on FHIR does not require any coded entries, but rather uses the "required if known" approach, meaning that if an implementer's system has data for a section that requires data under Meaningful Use, they need to send it, but if they have no data there is no need for a null entry. We encourage feedback on these Composition profiles, and the general approach to the project as a whole. We also encourage implementers who wish to see more of the coded data from C-CDA mapped to FHIR to comment on the US Core project and make their requests known there. Once US Core creates new profiles, this project can reference them. ### Scope To represent Consolidated CDA Templates for Clinical Notes (C-CDA) 2.1 templates using FHIR profiles. This first stage of the project defines all the C-CDA document-level profiles on the Composition resource and contained sections. Any coded data used by sections will be represented using relevant U.S. Core FHIR profiles where they exist. FHIR profiles defined by other work groups or unconstrained FHIR resources may also be referenced if no appropriate US Core Profile exist. For further information see the C-CDA specification here: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=408. (built Tue, Mar 12, 2024 18:59+0000+00:00)

Package hl7.fhir.uv.tools.r4#1.1.2 This IG defines the extensions that the tools use internally. Some of these extensions are content that are being evaluated for elevation into the main spec, and others are tooling concerns (built Tue, Mar 24, 2026 11:13+1100+11:00)

### Cross-Version Analysis

This is an R4 IG. None of the features it uses are changed in R4B, so it can be used as is with R4B systems. Packages for both R4 (hl7.fhir.us.pacio-toc.r4) and R4B (hl7.fhir.us.pacio-toc.r4b) are available.

### Intellectual Property Considerations

This publication includes IP covered under the following statements.

- © Copyright 2022 American Medical Association
  Show Usage
  - NUCC Provider Taxonomy: Bundle/Example-Smith-Johnson-TOCBundle, PractitionerRole/Role-IMMD-AnitaChu, PractitionerRole/Role-Neuro-NuraMekel, PractitionerRole/Role-OT-JenCadbury and PractitionerRole/Role-SNFDoc-GeraldPark
- ISO maintains the copyright on the country codes, and controls its use carefully. For further details see the ISO 3166 web page: https://www.iso.org/iso-3166-country-codes.html
  Show Usage
  - ISO 3166-1 Codes for the representation of names of countries and their subdivisions — Part 1: Country code: PACIOTransitionsOfCare, PacioTocCapabilityStatement... Show 6 more, PointOfContactExtension, TOCBundle, TOCComposition, TOCDocumentReference, ToCTempCS and TocDELItemsLOINC
- Most of the information on the CDC and ATSDR websites is not subject to copyright, is in the public domain, and may be freely used or reproduced without obtaining copyright permission. For information and exceptions regarding use of CDC material please see https://www.cdc.gov/other/agencymaterials.html
  Show Usage
  - Vaccine Administered Code Set (CVX): Bundle/Example-Smith-Johnson-TOCBundle, Immunization/BSJ-Immunization-Fluzone and Immunization/BSJ-Immunization-PCV20
- This CodeSystem is not copyrighted.
  Show Usage
  - Transition of Care Temporary Code System: Bundle/Example-Smith-Johnson-TOCBundle, Composition/BSJ-TOCComposition and TOCComposition
- This material contains content from LOINC. LOINC is copyright © 1995-2020, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee and is available at no cost under the license. LOINC® is a registered United States trademark of Regenstrief Institute, Inc.
  Show Usage
  - LOINC: Bundle/Example-Smith-Johnson-TOCBundle, Composition/BSJ-TOCComposition... Show 5 more, DocumentReference/Example-Smith-Johnson-DocRef-Bundle, List/BSJ-SMPMedList, TOCComposition, TOCDocumentReference and TocDELItemsLOINC
- This material contains content that is copyright of SNOMED International. Implementers of these specifications must have the appropriate SNOMED CT Affiliate license - for more information contact https://www.snomed.org/get-snomed or info@snomed.org.
  Show Usage
  - SNOMED Clinical Terms&reg; (SNOMED CT&reg;): AllergyIntolerance/BSJ-AllergyACE, Bundle/Example-Smith-Johnson-TOCBundle... Show 22 more, Condition/BSJ-DressingConcern, Condition/BSJ-HeartDiseaseDiagnosis, Condition/BSJ-HemiparesisDiagnosis, Condition/BSJ-HyperlipidemiaDiagnosis, Condition/BSJ-HypertensionDiagnosis, Condition/BSJ-StrokeDiagnosis, Condition/OT-ProblemList-RightWeak, Encounter/BSJ-Encounter, MedicationRequest/BSJ-SMPMedReq1, MedicationRequest/BSJ-SMPMedReq4, MedicationRequest/BSJ-SMPMedReq9, MedicationStatement/BSJ-SMPMedStmt1, MedicationStatement/BSJ-SMPMedStmt4, MedicationStatement/BSJ-SMPMedStmt9, ServiceRequest/BSJ-PCPFollowUp, ServiceRequest/BSJ-SNFDischargeCallOTRefer, ServiceRequest/BSJ-SNFDischargeCallOrder, ServiceRequest/BSJ-SNFDischargeCallSLPRefer, ServiceRequest/BSJ-SNFDischargeDietSalt, ServiceRequest/BSJ-SNFDischargeLabOrderBMP, ServiceRequest/BSJ-SNFDischargeLabOrderCBC and ServiceRequest/BSJ-SNFDischargePTRefer
- This material derives from the HL7 Terminology (THO). THO is copyright ©1989+ Health Level Seven International and is made available under the CC0 designation. For more licensing information see: https://terminology.hl7.org/license.html
  Show Usage
  - identifierType: Bundle/Example-Smith-Johnson-TOCBundle and Patient/Example-Smith-Johnson-Patient1
  - ActCode: Bundle/Example-Smith-Johnson-TOCBundle and Encounter/BSJ-Encounter
  - NullFlavor: Bundle/Example-Smith-Johnson-TOCBundle and Patient/Example-Smith-Johnson-Patient1
  - RoleCode: Bundle/Example-Smith-Johnson-TOCBundle and Patient/Example-Smith-Johnson-Patient1
- Used by permission of HL7 International, all rights reserved Creative Commons License
  Show Usage
  - US Core CarePlan Category Extension Codes: Bundle/Example-Smith-Johnson-TOCBundle and CarePlan/BSJ-SNFDischargeCarePlan
  - US Core DocumentReferences Category Codes: DocumentReference/Example-Smith-Johnson-DocRef-Bundle
  - Race & Ethnicity - CDC: Bundle/Example-Smith-Johnson-TOCBundle and Patient/Example-Smith-Johnson-Patient1
- Using RxNorm codes of type SAB=RXNORM as this specification describes does not require a UMLS license. Access to the full set of RxNorm definitions, and/or additional use of other RxNorm structures and information requires a UMLS license. The use of RxNorm in this specification is pursuant to HL7's status as a licensee of the NLM UMLS. HL7's license does not convey the right to use RxNorm to any users of this specification; implementers must acquire a license to use RxNorm in their own right.
  Show Usage
  - RxNorm: AllergyIntolerance/BSJ-AllergyACE, Bundle/Example-Smith-Johnson-TOCBundle... Show 6 more, MedicationRequest/BSJ-SMPMedReq1, MedicationRequest/BSJ-SMPMedReq4, MedicationRequest/BSJ-SMPMedReq9, MedicationStatement/BSJ-SMPMedStmt1, MedicationStatement/BSJ-SMPMedStmt4 and MedicationStatement/BSJ-SMPMedStmt9