PACIO Transitions of Care Implementation Guide
1.0.0-ballot - STU 1 Ballot
PACIO Transitions of Care Implementation Guide
1.0.0-ballot - STU 1 Ballot
This page is part of the PACIO Transitions of Care Implementation Guide (v1.0.0-ballot: STU 1 Ballot 1) based on FHIR (HL7® FHIR® Standard) R4. No current official version has been published yet. For a full list of available versions, see the Directory of published versions
| Official URL: http://hl7.org/fhir/us/pacio-toc/ImplementationGuide/hl7.fhir.us.pacio-toc | Version: 1.0.0-ballot | |||
| IG Standards status: Trial-use | Maturity Level: 2 | Computable Name: PACIOTransitionsOfCare | ||
The purpose of the LTPAC Transitions of Care (TOC) Implementation Guide is to provide a standards-based solution to support care transitions and coordination for LTPAC patients across all settings of care. The five traditional Post-Acute Care (PAC) settings, Hospice, 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 best and most efficient services to their patients. This information may include standardized 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, Emergency Department, and Home- and Community-Based Organizations (HCBOs). This critical information is often not exchanged, resulting in gaps in care information during initial assessments and reassessments in new or parallel settings, and the data is never available as a specific role-based data set. This leads directly to potentially unsafe transition and coordination of care for these most vulnerable patients as well as information overload, additional documentation, errors in the patient record, incorrectly reconciled data, and a burden on families and patients to carry physical records with them during transitions.
The CMS Data Element Library provides the reference data (questions and answers) for key quality instruments in post-acute care, notably the MDS and OASIS. Today, most if not all information that could help inform the completion of these assessments is captured at the referral source, but not in a manner that can be meaningfully presented to the post-acute provider. Without this context and properly mapped information, providers in Post-acute care settings are piecing together information from scratch 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 Directives or Personal Care preferences.
The PACIO Project is a collaborative effort to advance interoperable health data exchange between PAC and other providers, patients, their caregivers, and key stakeholders across healthcare and to promote health data exchange in collaboration with policy makers, standards organizations, and industry through a consensus-based 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 full spectrum of patient care, including acute, sub-acute, long-term post-acute care (LTPAC), community-based organizations, and private practice practitioners. The PACIO community brings together healthcare providers with a deep understanding of patient functioning that makes them uniquely suited to author this IG. This understanding comes out of each provider's:
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.
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), 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, respectively.
The Act requires:
Data to be standardized and interoperable to allow exchange of data between PAC providers, among others, using common standards and definitions to provide access to longitudinal information and facilitate coordinated care.
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: These pages provide overall guidance in using the profiles and transactions defined in this guide.
Personas and Scenarios: Personas and scenarios give context to the data exchange standards detailed in the technical areas of the guide. They allow the non-technical reader to envision situations in which the implementation guide provisions would apply, and ensure that the guide meets the intended needs for exchange of this type of information.
Use Cases: A use case is a list of technical actions or event steps typically defining the interactions between a role and a system to achieve a goal. The actor can be a human or other external system. Technical scenarios that describe systems interactions between technical actors to implement the use case.
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.
General Guidance: Information about the structure and relationships between the profiles in this guide.
Formal Specification: Information about conformance to the guide including Must Support requirements, document signatures, and document workflow.
Underlying Technologies: Information about the terminologies, notations, and design principles, specific to FHIR, that this specification uses.
Security, Privacy, and Consent: General security requirements and recommendations for Transitions of Care mplementation Guide actors, including authentication, authorization, and logging requirements and guidance.
FHIR Artifacts: These sections provide detailed descriptions and formal definitions for all the FHIR objects defined in this guide.
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.
Profiles: This section lists the set of Profiles that are defined in this guide to exchange transitions of care information. Each linked Profile page includes a narrative introduction and a formal definition.
Extension Definitions: This section lists the set of Extensions defined in and used by the Profiles in this guide. Each linked Extension page includes a formal definition.
Terminology: This section lists the value sets and code system defined for Transtions of Care Implementation Guide profiles.
Examples: The section that contains examples of transitions of care information that is conformant to the profiles of this guide.
Search Parameters and Operations: This section lists the Transtions of Care Implementation Guide defined Operations and Search Parameters that are used in TOC transactions.
Downloads: This page provides links to downloadable artifacts.
There are no Global profiles defined
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.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.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. |
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.us.pacio-pfe#2.0.0-ballot 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 Tue, Aug 13, 2024 15:07+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. ScopeTo 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:
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#2.0.0-ballot 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. ScopeTo 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, Dec 17, 2024 21:15+0000+00:00) |
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.
This publication includes IP covered under the following statements.
IG © 2024+ HL7 International / Patient Care. Package hl7.fhir.us.pacio-toc#1.0.0-ballot based on FHIR 4.0.1. Generated 2025-03-28
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change
