Patient Cost Transparency Implementation Guide
0.1.0 - STU 1 Ballot

This page is part of the Da Vinci Patient Cost Transparency Implementation Guide (v0.1.0: STU 1 Draft) based on FHIR R4. . For a full list of available versions, see the Directory of published versions

Patient Cost Transparency Implementation Guide Home Page

This specification is a Standard for Trial Use. It is expected to continue to evolve and improve through connectathon testing and feedback from early adopters.

Feedback is welcome and may be submitted through the FHIR change tracker indicating "US Da Vinci PCT" as the specification.

This implementation guide 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 implementation guide (IG) defines an exchange mechanism for providers to request and receive cost information from a payer regarding a service or item. This exchange will result in an Advanced Explanation of Benefits (AEOB) which will help inform a clinician and patient cost conversation. Note: This exchange will be triggered via a “request” or “scheduled service”. The AEOB will also include the GFE(s) (Good Faith Estimate) used to inform the AEOB generation.

The goal of this IG is to support the request for cost information for specific services and items from the payer and return them in near real-time to allow effective decision making by the patient in consultation with the ‘ordering’ provider. The project team plans to work with existing FHIR artifacts where possible. If changes are necessary the project team will work with the responsible Work Group to review and implement (via Jira items or new PSS) any necessary enhancements to base FHIR resources, extensions, and/or profiles.

This project will reference where possible the ‘standards’ defined by the Health Record exchange (HRex) Library/Framework Implementation Guide and other FHIR IGs where applicable.

Since this IG describes a series of FHIR based use cases the use of X12 standards is not required. X12 will only be used to inform the PCT APIs. An implementer is not required to use X12 and there is no HIPAA mandate to do so.

Currently, there is no specific mandate dictating the Da Vinci Price Transparency IG work. Instead, this IG is informed by the No Surprises Act, which was enacted as part of the Consolidated Appropriations Act, 2021. The No Surprises Act specifically requires that providers share GFE(s) with a payer and that a payer make an AEOB available to a patient in advance of service. The initial scope of this IG was inspired by this general requirement. While rulemaking has not yet addressed how specifically this general requirement will need to be implemented, this IG is being developed to support the flow of the necessary information from providers to the payer, to a patient. Subsequent iterations of this IG or other IGs will take into consideration any relevant future regulation or legislation, as appropriate or upon request. We welcome feedback on this topic.

  • We ask the reader to please review all data elements. Are all the data elements in this IG required to produce an AEOB? Note: This IG was not produced to handle claims, but it was informed by X12 837 data elements. We are soliciting feedback on this topic.
  • During the develop of this IG the question arose on how related GFEs should be linked. Especially if they arrive at different times. If a linking ID is used at the GFE level, how should it be used? We are looking for feedback on this topic.

Acronyms used in this IG can be found here. The reader of this IG should become familiar with these before reading this IG.

AEOB Interaction Diagram Steps (High Level View)

  1. A patient schedules a service which triggers the composition of a collection of 1 or more GFEs. Note: The composition of the collection of GFEs is currently not in scope for this IG. In other words, how the scheduling provider coordinates with other providers is currently not in scope for this IG.

  2. The collection of GFEs in the form of a FHIR resource bundle (GFE Bundle) is submitted (via the gfe-submit operation) to the payer’s intermediary or payer’s endpoint for AEOB creation.

  3. The payer’s intermediary (or payer) can translate the GFE Bundle to X12. The payer would then process, adjudicate, and produce the AEOB bundle. Note: Translating the GFE bundle to X12 or any other format is not required to be conformant with this IG.

  4. The patient can now request and receive the AEOB Bundle via FHIR query.

Note: The patient below could be a third-party web portal or provider web portal.

AEOB Interaction Diagram

Downloads

Package File

The following package file includes an NPM package file used by many of the FHIR tools. It contains all the value sets, profiles, extensions, list of pages and urls in the IG, etc defined as part of this version of the Implementation Guides. This file should be the first choice whenever generating any implementation artifacts since it contains all of the rules about what makes the profiles valid. Implementers will still need to be familiar with the content of the specification and profiles that apply in order to make a conformant implementation. See the overview on validating FHIR profiles and resources: