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-ballot 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
Page standards status: Draft |
The following page relates to the GFE Coordination workflow and is marked as DRAFT. This content has not yet met the requisite level of testing to be balloted as trail-use. However, this part of the specification has been reviewed by the Da Vinci PCT open community of providers, payers, and health IT vendors and was determined to be at a sufficient level of development to be included in this publication for the purposes of soliciting feedback from, and enabling testing by, the larger implementation community with the intention of bringing the content related to the GFE Coordination workflow to full STU status in a future version. 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 section of the Implementation Guide focuses on enabling providers and facilities to coordinate cost and planned service(s) or item(s) information for a patient’s period of care for which multi-provider Good Faith Estimates (GFE) are required, either to provide to the patient or to submit to a payer (for patients using insurance.)
This guide supports the:
Ability for a convening provider, acting as a coordination requester, to notify co-providers, acting as contributors, and request data to inform Good Faith Estimates (GFEs) for expected items and services
Ability for contributors to respond to a request for data back to a coordination requester with cost and planned items and services information. Ability for a Coordination Platform to communicate a GFE to payer (leveraging an existing PCT IG workflow,) and to other providers in the care team, prior to scheduled a service or upon request
The Coordination Platform is introduced in this guide to act as the system designated by the convening provider to aggregate the GFE information across providers when multiple providers are engaged in a service. This allows for variability in the role of “convening” providers and data for the GFE. Some examples of systems that could serve as GFE coordination platforms include a: practice management system, electronic health record (EHR) system, cost estimator, clearinghouse, billing services, or payer system.
Additionally, see the Terms and Concepts (link) and Systems and Actors (link) for more detail on acronyms and new terms.
Good Faith Estimate (GFE) Bundle including Good Faith Estimate resource profiles (Claim resources of type predetermination) along with supporting data (such as Patient, Coverage, etc.) to a payer. The payer can then use this information to generate an Advanced Explanation of Benefit (AEOB) Bundle including Advanced Explanation of Benefits resource profiles (ExplanationOfBenefit resources of type predetermination) along with supporting data that the patient, and optionally the provider (GFE submitter on claim resources), can retrieve to get an estimation of costs for expected services as known at a specific point in time.
GFE Coordination Diagram Steps (High Level View)
Pre-Step: A patient schedules a service or requests an estimate for a service which triggers the collection of one or more GFEs. Note: This workflow is used when there is need for a standard means of coordinating on a GFE with multiple providers.
A GFE Coordination Requester identifies all of the co-providers and retrieves their FHIR identifiers from the Coordination Platform.
The GFE Coordination Requester creates a set of Tasks (a single Coordinating GFE Coordination Task and one or more GFE Contributor Task(s)) that contain the information necessary to create an estimate on the Coordination Platform.
GFE Contributors are notified of a new task assignment.
The GFE Contributor retrieves the task and request information (GFE Information Bundle) The GFE Contributor can then decide to accept or reject the request and update the task appropriately.
The GFE Collaboration Requester is notified of status updates to the tasks they created.
When notified of a reject status, the GFE Coordination Requester can create a new GFE Contributor Task for a new contributor if they would like.
If the GFE Contributor accepts the request, they will collect the requested estimate(s), place them into a GFE Bundle, attach it to the task and mark completed.
The GFE Coordination Requester can retrieve a GFE Collection Bundle (made up of attached GFE Bundles and information about GFE Missing Bundles) at any time through a gfe-retrieve operation. They could also choose to ‘close’ the Coordination Task by marking it as completed.
Below are illustrations showing the relationships between the profiles involved in this workflow.
Note: For brevity, not all data elements are shown.
Figure 1 shows a GFE Coordination Bundle which is a transaction Bundle that can be used by a GFE Coordination Requester to submit all resources involved in a GFE coordination request in a single POST transaction. It includes a single GFE Coordination Task, and one or more GFE Contributor Tasks. The GFE Coordination Task must have a GFE Information Bundle associated to it. This information bundle is used to express all of the generally applicable information needed for GFE Contributors to make their estimates. Optionally, the GFE Contributor Tasks may also have a GFE Information Bundle associated to them to convey any provider specific information, such as specific services or to share specific contextual clinical information.A GFE Information Bundle is preferably associated to its respective Task resource by encoding it in the Task.input.valueAttachment
. Alternatively a GFE Information Bundle may be referenced by the Task.input.valueReference
and be written to the Coordination Platform as a separate Bundle.
The Task references to to Practitioner and Organization references in must point to the instances on the Coordination Platform.
Figure 1. GFE Coordination Bundle as created by the GFE Coordination Requester
Figure 2 shows the relationships of the resources involved in GFE coordination request as they exist on the Coordination Platform whether they be written individually or through the GFE Coordination Bundle transaction. If the GFE Information Bundles are not contained in the Task, they would exist as Bundle resources that would be individually retrievable from the Coordination Platform.
Figure 2. GFE Coordination Bundle content as stored on the Coordination Platform
Figure 3 shows the GFE Information Bundle is created by the GFE Coordination Requester and is meant to contain the information needed for GFE Contributors to make their estimate. This includes the Patient, Coverage and Payer if applicable, specific providers or roles being asked for (not the same as those on the Coordination Platform), requested items (including items and services), and any additional documentation. Additional resources that provide important contextual information that could affect needed items, services, or costs, such as Conditions or Observations, are also allowed.
Figure 3. GFE Information Bundle created by the GFE Coordination Requester
Figure 4 shows the GFE Bundle which is created by the GFE Contributor and attached to their GFE Contributor Task. It contains the Patient, Coverage and Payer if relevant, involved providers, and Claims data with the estimated costs.
Figure 4. A GFE Bundle created by the GFE Contributor
Figure 5 shows the GFE Missing Bundle which is used to convey that a GFE Contributor Task did not have a GFE Bundle attached when a GFE Collection Bundle was compiled. The purpose of this bundle is to provide an indication that aGFE collection is incomplete and what is missing, including the GFE Contributor and the items and services that an estimate requested for.
Figure 5. A GFE Missing bundle created by the Coordination Platform
Figure 6 shows the GFE Collection bundle created by the Coordination Platform when the GFE Coordination Requester calls the GFE-retrieve operation. In response to the gre-retrieve operation the provider (Practitioner or Organization). As part of the GFE Submission and AEOB Workflow, this represents the GFE submitter (which can be changed before the submission if necessary).
Figure 6. GFE Collection Bundle created by the Coordination Platform
Figure 7. GFE Coordination Technical Workflow
accepted
.rejected
.After each GFE Contributor has updated their respective GFE Contributor Task, the GFE Coordination Requester is notified of the changes (same process as step 3) and reviews the updates. If a GFE Contributor has rejected, the GFE Coordination Requester may choose to replace the contributor or cancel the entire request depending on the reason if one is provided in Task.statusReason
(e.g. if a key participant is unable to participate due to a proposed date of service, the GFE Coordination Requester may wish to cancel the entire request and make a new request with a time that works for that participant).
After accepting a GFE Contributor Task, each GFE Contributor creates a GFE Bundle with their good faith estimate and any supporting resources. They then attach that bundle to their GFE Contributor Task, sets the status to “completed” and does an HTTP PUT operation to update the task.
GFE Coordination Requestor provides the GFE Bundle to the patient directly, or proceeds to the GFE Submission and AEOB Workflow and submits the GFE Collection Bundle to the Payer.
closed
and uses an HTTP PUT to update the task on the Coordination Platform’s FHIR server.Timeline Example Scenario The diagram below demonstrates use of the available date elements to meet turnaround times to provide Good Faith Estimates (GFE)
Figure 8. Request Timeline Example
Note: This is one example scenario. Providers and facilities will determine what role they play. Providers and facilities may need to be prepared to play the convening provider or co-provider, depending on their role in the patient’s service and in accordance with federal, state, and local regulations.
Assumptions:
On Monday, Adam Everyman is seen by Dr. Carla Cutter, a surgeon, and is advised a surgical procedure is needed. Adam Everyman presents as self-pay for the surgery and associated services in the period of care.
Dr. Carla Cutter requests a surgical case time from Good Health Hospital (Convening Facility)
On Tuesday, Good Health Hospital (Convening Facility) confirms and schedules the surgery, booking the OR for 8 days from today (clock starts here)
Good Health Hospital (Convening Facility) identifies the co-providers needed for the procedure and triggers a request for price estimate from the ordering surgeon, Dr. Carla Cutter (co-provider 1), Sleeper Anesthesiologist Group (co-provider 2), through their designated Coordination Platform.
Dr. Carla Cutter’s office and Sleeper Anesthesiologist Group (Co-Providers) each review the procedure(s), relevant clinical data and respond to the GFE coordination request with procedures, pricing, including patient responsibility via the designated Coordination Platform.
Good Health Hospital’s assigned Coordination Platform aggregates all convening and co-provider estimates into a single GFE, with the summary total for the surgery across providers as well as the details per provider.
GFE is posted to API available to the Patient by Tuesday (within one business day from time of scheduling)