Patient Cost Transparency Implementation Guide, published by HL7 International / Financial Management. This guide is not an authorized publication; it is the continuous build for version 2.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-pct/ and changes regularly. See the Directory of published versions
Plain Language Summary goes here
Patient Cost Transparency Implementation Guide Home Page
Official URL: http://hl7.org/fhir/us/davinci-pct/ImplementationGuide/hl7.fhir.us.davinci-pct
This specification is a Standard for Trial Use. It is expected to continue to evolve and improve through HL7® FHIR® Connectathon testing and feedback from early adopters.
STU1 focused on a payer receiving a good faith estimate (GFE) from a provider and returning an Advanced Explanation of Benefits (AEOB) to a patient. With STU2, this specification includes guidance on how multiple providers can work together to provide one collective GFE, GFE Summary and AEOB Summary for easier patient understanding of their overall estimated cost, as well as other valuable updates. See [Change Log](change_log.html) for additional information.
The IG STU2 content relating to the GFE Coordination is marked as DRAFT throughout this guide. The Da Vinci PCT open community of providers, payers, health IT including EHRs, revenue cycle experts, billing specialists, cost estimator experts and others that have provided requirements and vetted design decisions, recognize that the GFE coordination process is not happening today. Balloting this content provides the opportunity to gain feedback broadly and enable better insights for testing of the technology as the business process evolves to ready a standard for trial use.
Feedback is welcome and may be submitted through the FHIR change tracker indicating "US Da Vinci Patient Cost Transparency (PCT)(FHIR)" as the specification.
This implementation guide (IG) is dependent on other specifications. Please submit any comments you have on these base specifications as follows:
Feedback on the FHIR core specification should be submitted to the FHIR change tracker with "FHIR Core" as the specification.
Feedback on the US core profiles should be submitted to the FHIR change tracker with "US Core" as the specification.
Individuals interested in participating in the Patient Cost Transparency project or other HL7 Da Vinci projects can find information about Da Vinci here.
Overview
This IG provides detailed guidance to support providers and payers exchanging financial information for specific items and services using FHIR-based standards. This exchange involves a provider or group of providers submitting a Good Faith Estimate (GFE) to a patient (if self-pay or uninsured) or a payer. A payer can then generate an Advanced Explanation of Benefits (AEOB) for a patient (which may optionally be returned to the submitting provider).
When there are multiple providers involved in a patient’s service, these providers may need to coordinate in order to produce one comprehensive GFE. This IG provides guidance on how this collaborative GFE creation process can leverage FHIR. Information about the cost of healthcare items or services may enable better decision making by the patient in consultation with the provider.
Note: This exchange will be triggered via a “request” or “scheduled service”. When the patient has insurance they chose to use, the GFE will be sent from a provider to a payer. The payer will produce an AEOB, which will also include the GFE used to inform the AEOB generation. This IG describes system interactions using the FHIR standard.
This IG will reference where possible the “standards” defined by the Health Record exchange (HRex) Library/Framework IG, other FHIR IGs, and other industry standards where applicable.
This IG is informed by the No Surprises Act (see Division BB, Title I, Sections 111 and 112), which was enacted as part of the Consolidated Appropriations Act, 2021. The No Surprises Act specifically requires that a provider or providers share a GFE with a patient when the patient is self-pay/uninsured or with a payer for insured patients when the patient schedules a service or requests an estimate. When the payer receives a GFE, the payer must make an AEOB available to a patient in advance of the service.
Understanding the need for multiple providers to be able to work together to produce a single GFE in support of the law, this IG provides guidance on how to create this GFE using FHIR. This IG introduces a GFE coordination workflow that leverages a Coordinating Platform. The Coordinating Platform could be any number of systems - a practice management system, an EHR, a portal, a third party system, etc. When a patient contacts a provider to schedule a service or request an estimate for a service, the provider or facility who schedules the service or receives the request is the convening provider or convening facility per current CMS regulation for uninsured/self-pay patients.
The role a provider plays in this collaboration will change from case to case. In some cases, a provider will be a GFE Coordination Requester because the patient’s care is starting with them - the service was scheduled with this provider. If this provider is also providing items and services to be included in the GFE, they will also play the role of a GFE Contributor. For other patients, the same provider may be a co-provider supporting a different provider or facility with a patient’s period of care, in which case they will only act as a GFE Contributor. In either role, the IG provides tools to support the collaboration effort and the production of a single GFE. Certain state regulations may also inform which role a provider plays.
NOTE: At this time, the Departments have exercised enforcement discretion allowing providers to send separate GFEs to a patient or payer. Further federal regulation on this is anticipated. This IG can support this process, helping patients get the best, most usable information to make informed decisions about their care. If specific guidance is issued that requires adjustments to this IG, the IG will be updated.
The IG supports different methods of information sharing between payers and providers and payers and patients. In this way, the IG can support providers and payers as they work to meet the legislative and future regulatory requirement as well as enable information sharing valuable to supporting patient care. Since the law does not require an API to share these data, the method used to share the required information – an API, a portal, email, etc. – is the decision of the parties engaged in the process. Should future rulemaking mandate a specific scenario, this IG can be revised accordingly.
By using the FHIR standard and implementing this guide, providers and payers can enhance their existing technologies, where applicable, for estimating patient costs securely and efficiently using common open web technologies. The anticipated benefit of using FHIR APIs is to streamline the process of creating a single comprehensive GFE for self-pay/uninsured patients and a single AEOB for insured and to enable applications of the patients’ choice to give greater transparency into patient-specific estimated costs of expected healthcare items and services.
FHIR is being used for consumer access to healthcare related data at significant scale today, and there are regulatory requirements in the form of the CMS Patient Access API for FHIR support for the related use case of post adjudicated claims. Use of an industry standard would keep the barrier to stakeholder adoption relatively low.
Note: The scope of this guide does not include coordination of benefits or more than one coverage. This does not serve as a replacement for eligibility, scheduling, prior authorization or other financial and administrative use cases.
Acronyms used in this IG can be found here. The reader of this IG should become familiar with these before reading this IG.
General Workflow
This guide breaks the process into two main parts in support of the patient cost transparency use case:
GFE Coordination Workflow - Supports the ability for a provider to request and collect one or more GFEs from other providers that may participate in a set of procedures related to patient’s period of care for which a GFE is required, either to provide to the patient and/or to submit to a payer.
GFE Submission and AEOB Workflow - Supports the ability for a provider to submit a collection of one or more GFEs to a payer for them to process and produce an AEOB Packet to the patient and optionally to the provider. This submission may include GFEs from multiple providers or a consolidated GFE that were gathered in the GFE Coordination Workflow .
Good Faith Estimate and Advanced Explanation of Benefit High Level Workflow
GFE Submit Workflow
AEOB Interaction Diagram Steps (High Level View)
A patient schedules a service or requests an estimate for a service which triggers the composition of a collection of one or more GFEs.
The Providers involved in the service coordinate on their individual charges and services for the Good Faith Estimate through the GFE Coordination Workflow, if applicable. For self-pay or uninsured patients, the GFE can be made available to the patient at this step.
For insured patients, one or more GFEs in a FHIR Bundle resource (GFE Packet) is submitted (via the gfe-submit operation) to the payer’s endpoint for AEOB creation.
The payer would then process, adjudicate, and produce the AEOB Packet.
The patient and provider may receive a notification of availability of the AEOB Packet and can now request and receive the AEOB Packet via FHIR query.
Note: Communication to the patient could be direct from the provider or the payer or through a third-party app via an API.
Content and Organization
Content and Organization
This implementation guide (and the menu for it) is organized into the following sections:
Background - Supporting informative pages that covers the use cases and actors, but does not set conformance expectations
Reading this IG points to key pages in the FHIR spec and other source specifications that must be understood to understand this guide
Use Cases describes the intent of the implementation guide, gives examples of its use, and provides a high-level overview of expected process flow
GFE Coordination Overview describes the use case and workflow of the Good Faith Estimate (GFE) multiple provider coordination use case that describes how providers using varying technologies can coordinate to gather their constituent GFEs to pull together into a single GFE Packet.
GFE Submission and AEOB Overview describes the use case and workflow for a provider to submit a GFE Packet to a payer to request an Advanced Explanation of Benefits (AEOB) for their patient and making that AEOB available.
Project and Participants gives a high-level overview of Da Vinci and identifies the individuals and organizations involved in developing this implementation guide
Specification - Pages that set conformance expectations
Conformance Expectations defines base language and expectations for declaring conformance with the guide
GFE Coordination Specification describes the conformance requirements for implementers of the multiple provider using varying technologies can coordinate to the creation of a single a single GFE Packet.
GFE Submission and AEOB Specification describes the conformance requirements for a provider submitting a GFE Packet for an insured patient to a payer for an AEOB to be created and made available.
Privacy, Safety, and Security covers considerations around data access, protection, and similar concepts that apply to all implementations
FHIR Artifacts
Artifacts Overview introduces and provides links to the profiles, search parameters and other FHIR artifacts used in this implementation guide
Base Specs - Quick links to the various specifications this guide derives from
Support - Links to help with use of this guide
Discussion Forum is a place to ask questions about the guide, discuss potential issues, and search through prior discussions
Project Page includes information about project calls, agendas, past minutes, and instructions for how to participate
Implementer Support provides information about reference implementations, resources for testing, known errata, regulatory considerations, and practical implementation pathways
Specification Dashboard shows new and historical issues that have been logged against the specification, proposed dispositions, unapplied changes, etc.
Propose a Change allows formal submission of requests for change to the specification. (Consider raising the issue on the discussion forum first.)
Downloads allows downloading this and other specifications, as well as other useful files
Terms and Concepts
Term
Definition
AEOB
The Consolidated Appropriations Act includes provisions whereby group health plans and health insurance issuers, based on charges, billing and diagnostic codes provided by the provider(s), provide an Advanced Explanation of Benefits for scheduled services or upon request to give patients transparency into their estimated healthcare costs. AEOBs need to include which providers are expected to provide treatment, the network status of providers, good faith estimates of cost, cost-sharing and progress towards meeting deductibles and out-of-pocket maximums, as well as whether a service is subject to medical management and relevant disclaimers of estimates; for example, the disclaimer might state that the information provided in the notification is only an estimate based on the items and services reasonably expected, at the time of scheduling (or requesting) and is subject to change. For a complete breakdown of what needs to be included in the AEOB see 42 U.S. Code 300gg-111(f)(1)(A) through (H).
CAA Consolidated Appropriations Act
Also called "H.R. 133". The CARES (Coronavirus Aid, Relief, and Economic Security) Act implemented a variety of programs to address issues related to the onset of the COVID-19 pandemic.
The Consolidated Appropriations Act continued many of these programs by adding new phases, new allocations, and new guidance to address issues related to the continuation of the COVID-19 pandemic. Title I (the No Surprises Act) of Division BB of the Consolidated Appropriations Act, 2021 establishes new protections from surprise billing and excessive cost sharing for consumers receiving healthcare items/services.
The Consolidated Appropriations Act (2021) was passed by Congress on December 21, 2020 and signed into law on December 27, 2020.
GFE
The Good Faith Estimate is a notification of reasonably expected charges and billing codes for a scheduled or requested item or service. For a complete breakdown of what needs to be included in the GFE see 42 U.S. Code 300gg-136
HIPAA
The Health Insurance Portability and Accountability Act of 1996 (HIPAA) is a federal law that required the creation of national standards to protect sensitive patient health information from being disclosed without the patient’s consent or knowledge. The US Department of Health and Human Services (HHS) issued the HIPAA Privacy Rule to implement the requirements of HIPAA. The HIPAA Security Rule protects a subset of information covered by the Privacy Rule.
Dependencies
This guide is based on the FHIR R4 specification that is mandated for use in the U.S.
In addition, this guide also relies on several ancestor implementation guides:
This implementation guide defines additional constraints and usage expectations above and beyond the information found in these base specifications.
Intellectual Property Considerations
This implementation guide and the underlying FHIR specification are licensed as public domain under the FHIR license. The license page also describes rules for the use of the FHIR name and logo.
This publication includes IP covered under the following statements.
All X12 products are subject to this IP policy, including published and draft works.X12 is the only organization authorized to grant permission for use of X12 products. Users of all X12 products should make sure that they understand the permissible uses, as well as the limitations on such usage, as outlined below.Additional IP information can be found here
Send an email to ip@x12.org to request permission to reproduce X12 IP. Include your name, organization, title, address, city, state, zip, email, a detailed description of the Submitted Artifact, including the underlying or cited X12 Product, and a detailed description of the intended audience and planned distribution method for the Artifact.Additional information on X12 licensing program can be found here
To purchase code list subscriptions call (425) 562-2245 or email admin@wpc-edi.com.
All X12 work products are copyrighted. Any use of any X12 work product must be compliant with US Copyright laws and X12 Intellectual Property policies.Please see https://x12.org/products/licensing-program
Licensing information can be found here
These codes are listed within the UB-04 Data Specifications Manual. The Official UB-04 Data Specifications Manual, copyrighted by the American Hospital Association, is the only official source of UB-04 billing information adopted by the National Uniform Billing Committee. No other publication—governmental or private/commercial—can be considered authoritative. The AHA wants to make you aware that the use of codes, descriptions, or any other content contained in the manual to be used in a software application, publication, or any other derivative work must be properly licensed by the AHA. If your organization uses or intends to use any of the codes or other related content from the manual in this manner, please contact the AHA’s licensing manager, Tim Carlson, at 312.893.6816 or tcarlson@aha.org
The Centers for Medicare & Medicaid Services (CMS) maintain MS-DRGs used throughout the US health care industry. The CMS MS-DRGs are free to use without restriction.
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.
|
Propose a change