Patient Cost Transparency Implementation Guide
2.0.0 - STU 2 - Draft
Patient Cost Transparency Implementation Guide
2.0.0 - STU 2 - Draft
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
| 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 (IG) defines the specific conformance requirements for systems wishing to conform to this Patient Cost Transparency (PCT) IG for GFE Coordination. It focuses on the Good Faith Estimate (GFE) Coordination Task, though it also provides guidance on privacy, security, and other implementation requirements.
The GFE Coordination workflow uses the Task resource. This resource is used to define, assign, and track activities across individuals, systems and organizations. The type of Tasks is distinguished by the Task.code. This guide defines the code gfe-contributor-task to be used as the type for each Task that is assigned to a single provider (Practitioner, PractitionerRole, or Organization) that is to contribute a GFE Bundle. Each of these GFE Contributor Task resources are part of a single set of requests and share an association through the GFE Coordination Task with a Task.code of gfe-coordinating-task and is referenced by each GFE Contributor Task resource by Task.partOf. All of the tasks are created by the GFE Coordination Requester are posted to the Coordination Platform where they will be managed throughout the rest of the workflow culminating in the GFE Coordination Requester making the $gfe-retrieve operation to collect all available GFE Bundle resources posted by the of the GFE Contributor(s) into one PCT GFE Packet
In addition to the requirements specified in this section, GFE Coordination Requesters, Coordination Platforms, and GFE Contributors SHALL meet the requirements as specified in their respective requirements CapabilityStatements and sections defined in this IG.
This section describes the minimal workflow requirements and task transitions for both the GFE Coordination Task and the GFE Contributor Task. Except were specifically stated, this IG does not disallow other states or transitions. However, implementers should not expect other systems to recognize or understand variances from this process without prior agreement.
status.draft status.
draft status SHOULD NOT trigger a notification.draft status.status of ready (3), entered-in-error (6), or cancelled (7).status of the GFE Coordination Task to ready to initiate the GFE coordination process.
status to requested and the individual Contributor Task Workflow begins.status of entered-in-error (6) or cancelled (7).status to failed (8) in the event of a process of system failure or in-progress (4) when at least one of the associated GFE Contributor Task changes to a status of accepted.status to in-progress when at least one of the GFE Coordination Task’s associated GFE Contributor Task has a status change from received to accepted.
status of completed (5), entered-in-error (6) or cancelled (7).status to failed (8) in the event of a process of system failure.status of in-progress GFE Coordination Task to completed when the necessary GFE information is collected, or the time limit is reached and the Task needs to be closed.
statusReason in the update to the GFE Coordination Task.businessStatus of the GFE Coordination Task and all associated GFE Contributor Task to closed.status is not complete, with a status of failed and provide a statusReason matching the statusReason the GFE Coordination Task (that was the statusReason provided by the Coordination Requester).status of any open GFE Coordination Task to entered-in-error.
businessStatus of the GFE Coordination Task and all associated GFE Contributor Tasks to closed.status, where the status is not complete, to entered-in-error.status of any open GFE Coordination Task to cancelled.
statusReason in the update to the GFE Coordination Task.businessStatus of the GFE Coordination Task and all associated GFE Contributor Task to closed.status, where the status is not complete, to cancelled.status of GFE Coordination Task with status of ready or in-progress to failed in the event of a system or process issue.
statusReason provided with an explanation of the failure with a useful description in the statusReason.text.businessStatus of the GFE Coordination Task and all associated GFE Contributor Task to closed.status to failed.
draft status.
draft status GFE Contributor Task SHOULD NOT trigger a notification to the GFE Contributor it is assigned to.draft status.draft status GFE Contributor Task MAY be discoverable (searchable) by the assigned GFE Contributor (Task.owner), depending on business workflow needs.status of requested.status of requested based on the events in the GFE Coordination Workflow.
Task.owner) SHALL now have read access to the Task.Task.owner), either through a read or a search, the Coordination Platform SHALL automatically update the GFE Contributor Task status to received.status of entered-in-error (7), failed (8), or cancelled (9) based on the events in the GFE Coordination Workflow.status to received upon first retrieval, either through read or search.
Task.owner) SHALL now have write access to update the Task.status of accepted (4) or rejected (5).status of entered-in-error (7), failed (8), or cancelled (9) based on the events in the GFE Coordination Workflow.status of accepted when they decide to participate in the GFE coordination process for the request and plan on providing a GFE Bundle.
status of rejected (5), completed (6), or failed (7).status of entered-in-error (7), failed (8), or cancelled (9) based on the events in the GFE Coordination Workflow.status of rejected if they will not participate in the GFE coordination process for the request and will take no further action on the request.
statusReason for rejecting the Task.businessStatus of the GFE Contributor Task to closed.status of completed when they attach the GFE bundle and it is ready to be made available to the GFE Coordinator (via gfe-retrieve operation). This is usually done after there is a sufficient level of confidence in the GFE Bundle they had attached to the Task.
businessStatus is not set to a value of closed.businessStatus of the GFE Contributor Task to closed if there will be no further changes made.businessStatus of the GFE Contributor Task to closed if there will be no further changes made based on the events in the GFE Coordination Workflow.status of completed.status to entered-in-error based on the events in the GFE Coordination Workflow.
businessStatus of the GFE Contributor Task to closed.status to failed if they were unable to complete the task or the Coordination Platform SHALL set a GFE Contributor Task status to failed based on the events in the GFE Coordination Workflow.
status of failure SHALL have a statusReason provided with an explanation of the failure with a useful description in the statusReason.text.businessStatus of the GFE Contributor Task to closed.status to cancelled based on the events in the GFE Coordination Workflow.
businessStatus of the GFE Contributor Task Tasks to closed.status of any open GFE Coordination Task to cancelled if the status is not already rejected and SHOULD update the GFE Contributor Task statusReason.status of a GFE Coordination Task to cancelled if the status is rejected, and SHALL NOT update the statusReason of such a GFE Contributor Task.All Tasks with a businessStatus of closed SHALL not be updatable by the GFE Coordination Requester or GFE Contributors.
This section describes several requirements involved in the Coordination Workflow detailing the some of the actions necessary for each step of the process as well as providing guidance on activities that should or may take place.
The Coordination Platform is the system enabling all interactions between collaborating parties. As such, the Coordination Platform will need to manage all of the resources relating to all potentially participating parties along with their contact information and a means to notify each of Task assignments and changes in Task status.
After the GFE Coordination Requester, expectedly a Convening provider, determines that GFE collection needs to be coordinated across providers and determines the set of services and providers necessary, they will search the Coordination Platform for the references (FHIR IDs) for the providers to coordinate with. This lookup is generally done with an NPI, Tax ID or other identifying methods as supported by the Coordination Platform. For the purposes of this IG, the Coordination Platform provides a sort of “White Pages” phonebook lookup of providers. It is expected that providers largely maintain their own networks of potential care team members or have other means to find providers to work with. The “phonebook” lookup provided by the Coordination Platform is not expected to serve as a means to lookup providers by services offered or their service locations.
The Coordination Platform SHALL manage a current set of PCT Organization, PCT Practitioner, and US Core PractitionerRole resources as identified in this guide with enough data and searching capabilities to support GFE Coordination Requesters to identify and retrieve the FHIR IDs of GFE Contributors.
The GFE Coordination Requester SHALL use the FHIR resource IDs in all references to providers in both the GFE Coordination Task and GFE Contributor Task resource(s). These references include the Task.requester and the assigned Task.owner
When creating new Tasks, GFE Coordination Requesters SHALL reference only Coordination Participants where active=true.
If the GFE Coordination Requester must also contribute a GFE, they SHALL also create a GFE Contributor Task assigned to themselves for that purpose. This is done to enable a full set of GFEs to be made available for the Coordination Platform to put together into a complete GFE Packet.
Associating Request Information Bundles to Tasks
Once the GFE Coordination Requester has collected sufficient enough information necessary for GFE Contributors to be able to provide an accurate estimate, and places the information into one or more GFE Information Bundle resources, the information bundles SHALL be associated with the appropriate Task through the Task.input element.
The GFE Information Bundle resources SHALL be fully contained, meaning all references SHALL resolve within the bundle.
The information that applies to all of the tasks SHALL be identified in the GFE Coordination Task.
There SHALL be at least one information bundle associated in the GFE Coordination Task.
A GFE Coordination Requester MAY create GFE Contributor specific information bundles which SHALL be associated to the appropriate GFE Contributor Task.This can be done to provide specific providers only the information they need to see.
To associate an information bundle with a Task in the Task.input, the GFE Contributor SHOULD encode the bundle as an attachment in Task.input.valueAttachment, though they MAY associate it through a reference in Task.input.valueReference.
A GFE Information Bundle associated to a Task through a reference SHALL exist on the Coordination Platform and the Task SHALL have the Task.input.valueReference reference the instance on the Coordination Platform.
Since the information bundle is fully self-contained and its relevance only extends to the Task in which it is associated, there is no need for the bundle to be written directly to the Coordination Platform. This can simplify the management of the data and has the advantage of not enabling the bundle to be modified outside of the Task.
A potential disadvantage of having the information bundle contained in the Task is the size of the resource. An organization that has to manage and search through many GFE Contributor Task resources may have a notable increase in traffic volume. This may be mitigated by Coordination Platforms that support the _summary search parameter
A Coordination Platform SHALL support the ability for GFE Coordination Requesters to create a request in a single $gfe-coordination-request operation with a GFE Coordination Bundle. If any of the Tasks are unable to be written, the operation SHALL fail, no resources SHALL be written, and an OperationOutcome SHALL be returned indicating the nature of the error(s) if the nature of the problem is FHIR operation related (as opposed to a base HTTP issue like a Bad Request).
The GFE Coordination workflow is designed to allow participation of GFE Contributors that may not support this FHIR IG directly, or support FHIR at all. The Coordination Platform may provide another means to contribute data for GFE Bundle resources, such as through a delegate system or a portal. To support this, GFE Coordination Requesters SHOULD create GFE Contributor Task resources for all of GFE Contributors that a GFE Bundle is needed from if they have an active Coordination Participant Resource (Organization/Practitioner/PractitionerRole) on the Coordination Platform.
Notifications may take the form of FHIR Subscription (as defined in this IG), unsolicited notification, messaging or other method.
Coordination Platforms SHALL be able to notify GFE Contributors when a new GFE Contributor Task is assigned to them or is marked as cancelled.
Coordination Platforms SHALL be able to notify GFE Coordination Requesters when a GFE Contributor Task they created has had their status updated to rejected, accepted, or completed.
Implementers MAY support the R4 Subscriptions referenced in the FHIR Subscriptions R5 Backport Implementation Guide.
This IG defines the following minimal requirements for the support of subscriptions for systems conforming to this IG that choose to support subscriptions:
Subscription.criteria for the subscription topics supported SHALL be used. Other types of Subscriptions are allowed.id-only, though they can also support other content approaches.
Note: The
id-onlyapproach means that the id of the Task that was updated will be provided. The client will then perform a read or a query to retrieve the identified record(s) specified in the subscription notification.
The Coordination Requester subscription SHALL conform to the Subscription - GFE Coordination Task Update Notification and meet the following requirements:
Subscription.criteria = http://hl7.org/fhir/us/davinci-pct/SubscriptionTopic/davinci-pct-gfe-coordination-task-subscriptiontopicSubscription.criteria.extension[filterCriteria].valueString = Task?requester=[FHIR-ID] where [FHIR-ID] is the FHIR logical identifier for the Coordination Requester.The GFE Contributor subscription SHALL conform to the Subscription - GFE Coordination Task Update Notification and meet the following requirements:
Subscription.criteria = http://hl7.org/fhir/us/davinci-pct/SubscriptionTopic/davinci-pct-gfe-coordination-task-subscriptiontopicSubscription.criteria.extension[filterCriteria].valueString = Task?owner=[FHIR-ID] where [FHIR-ID] is the FHIR logical identifier for the GFE Contributor.Subscription.criteria.extension[filterCriteria].valueString = Task?_has:Task:part-of:owner=[FHIR-ID] where [FHIR-ID] is the FHIR logical identifier for the Coordination Contributor.
Note: This will enable the notification when the Coordination Task that is parent to the Contributor Task, is updated.
For notifications to patients (GFE Packet subject) the GFE Packet subscription SHALL conform to the Subscription - GFE Available for Subject Notification and meet the following requirements:
Subscription.criteria.extension[filterCriteria].valueString = DocumentReference?subject=[FHIR-ID] where [FHIR-ID] is the FHIR logical identifier for the patient.For notifications to authors (GFE Contributors) the GFE Packet subscription SHALL conform to the Subscription - GFE Available for Author Notification and meet the following requirements:
Subscription.criteria.extension[filterCriteria].valueString = DocumentReference?author=[FHIR-ID] where [FHIR-ID] is the FHIR logical identifier for the GFE Contributor.To support the access and ability to provide notifications appropriately, a GFE Packet DocumentReference and PCT GFE Composition SHALL NOT have their documentReference.type and Composition.type elements, respectively, modified. If either of these elements was entered in error, the GFE Packet DocumentReference documentReferece.status and PCT GFE Composition Composition.status SHALL be set to entered-in-error.
Both GFE Coordination Requesters and GFE Contributors need to be able to search for Tasks related to their role in the GFE Coordination workflow. Searching requirements are detailed the CapabilityStatements in this guide and SHALL be followed for a system to claim conformance to this guide.
GFE Contributors SHOULD NOT reject a Task because there is insufficient information to provide a GFE. Instead, the GFE Contributor SHOULD request the necessary information from the GFE Requester (the means of this communication is not defined by this specification). GFE Contributors MAY reject a Task if they are still unable to receive the necessary information after attempting to do so.
When submitting a GFE Bundle, GFE Contributors SHALL update the GFE Contributor Task with the GFE Bundle contained in Task.output.valueAttachement and SHALL set that Task.status to completed when the Task is considered complete.
The GFE Contributor MAY include other types of data in output.valueAttachment, but such data SHALL be in a FHIR Resource format and fully contained with no external references that can’t be resolved internally.
If there is a schedule change, a change to the items or services for which a GFE is being requested, or the context of which has changed such that it may materially affect the GFE of a GFE Contributor, the GFE Coordinator SHOULD cancel the GFE Coordination Task and create a new one.
This new replacement GFE Coordination Task SHOULD contain the task-replaces extension with a reference to the cancelled GFE Coordination Task that the new one replaces. This will enable GFE Contributors to refer back to any previous GFE Bundle resources in the case it may assist them in addressing the new task.
The cancellation and creation of a new task, instead of updating tasks, is recommended because there is limited time to provide an estimate and the intent is to provide the best possible estimate at time of the request. There could be any number of modifications during this process that will be difficult to track during this limited time. Closing and opening a new request provides some closure/finality to the interaction that should be easier to track, particularly without requiring systems, both server and client, to support FHIR resource versioning. Modifications of existing tasks would require each GFE contributor be notified of the change, some of which may have already closed out their task, potentially causing additional disruption, avoidable re-work, and errors.
Replacing a GFE contributor, does not present the same sort of coordination challenges and is being provided as a means to reduce burden of the other GFE Contributors that are participating by not requiring them to resubmit.
GFE Coordination Requesters SHALL be able to replace GFE Contributors regardless of the state of the status of the GFE Contributor Task as long as the GFE Coordination Task does not have a status of cancelled, failed, completed, or entered-in-error.
When replacing a GFE Contributor the GFE Coordination Requester SHALL change the target GFE Contributor Task status to cancelled if the status is not already rejected and SHOULD update the Task.statusReason. If the status = rejected it SHALL remain so and the statusReason SHALL remain unchanged.
When replacing a GFE Contributor, the GFE Coordination Requester SHALL write new GFE Contributor Task resource(s) for the GFE Contributor(s) that are replacing the previous GFE Contributor(s). The other existing Tasks SHALL remain intact (i.e., only replace the Tasks that need replacing as opposed to recreating all tasks). If more than a simple replacement GFE Contributors is required, such as a change in scheduled date or services, the GFE Coordinating Requester SHOULD cancel the GFE Coordination Task and create a new one.
Retrieval of the collection of contributed GFEs is done through the $gfe-retrieve operation. This operation collects the contributed GFE Bundle resources attached to the GFE Contributor Task resources as well as any GFE Missing Bundle resources for any GFE Contributor Task resources that do not have an attached GFE Bundle. A Task SHALL have an appropriately attached GFE Bundle and a status of completed in order to be included in the GFE Packet returned through the $gfe-retrieve operation. GFE Missing Bundle resources support indication that the GFE may be missing a portion that will contribute to their overall cost. These bundles are a technical requirement in the event the GFE must be sent without all contributor estimates included.
Retrieval of a GFE Packet SHALL be available to the GFE Coordination Requester that created the associated GFE Coordination Task and SHALL be retrieved using the FHIR ID of the GFE Coordination Task.
The $gfe-retrieve operation SHALL return a single GFE Packet when executed on a valid GFE Coordination Task instance for which the requester has access.
The GFE Packet SHALL consist of:
Task.extension[planned-service-period], this date/time SHALL be placed into the GFE Composition Composition.extension[gfeServiceLinkingInfo].extension[plannedPeriodOfService].valuePeriodTask.reasonCode SHALL be placed into the GFE Composition Composition.extension[requestOriginationType].valueCodeableConceptThe Patient Resource extracted from the GFE Information Bundle associated with the GFE Coordination Task
The Coverage Resource extracted from the GFE Information Bundle associated with the GFE Coordination Task, if present.
The Organization Resource (for payer) extracted from the GFE Information Bundle associated with the GFE Coordination Task, if present.
The Organization, Practitioner, PractitionerRole Resource (for providers) extracted from the GFE Information Bundle associated with the GFE Coordination Task, if present.
All of the FHIR Resources in .output.valueAttachment of the associated (that have a Task.partOf that references the GFE Coordination Task) GFE Contributor Task where the status is completed (NOTE: that each Contributor Task may have multiple output.valueAttachment iterations).
For each associated GFE Contributor Task that does not have a status or completed and does not have a GFE Bundle in output.valueAttachment and a status of completed, there SHALL be a GFE Missing Bundle. (This means there will be a GFE Missing Bundle for each task that has not been marked as rejected or cancelled and does not have a status of completed and an attached GFE Bundle.)
When deemed appropriate, the GFE Coordination Requester SHALL close the GFE Coordination Task by updating the status to completed, cancelled, or failed and SHALL include a statusReason to close the request when no new GFE Contributions will be needed or accepted.
Coordination Participants (GFE Coordination Requesters and GFE Contributors) SHALL be able to read and update all of the Task resources they created or are assigned to (via Task.owner) while the Task does not have a status of draft and does not have a businessStatus of closed and SHOULD retain read access regardless of status or businessStatus.
GFE Contributors SHALL have read access to GFE Coordination Task resources that are referenced by GFE Contributor Task resources that are assigned to and SHALL NOT have access to modify those GFE Coordination Task resources unless they are also the GFE Coordination Requester.
GFE Contributors MAY access the Tasks of other participants whose assigned Task references the same GFE Coordination Task if the Coordination Platform allows it.
GFE Contributor Tasks SHALL NOT be able to be modified by a GFE Contributor if the status is cancelled, rejected, entered-in-error, or completed
Tasks marked as completed, rejected, or entered-in-error SHOULD NOT be able to be modified by GFE Contributors..
Providers MAY make GFE information available to the patient, regardless of whether there is a need or intent to send it to a payer for an insured patient estimate (AEOB).
Note: Providers may provide GFE information in a number of ways, such as via mail, the patient portal, or via an API specified in this IG. This specification does not currently address requirements for sharing GFE information with patients through an API.
IG © 2025+ HL7 International / Financial Management. Package hl7.fhir.us.davinci-pct#2.0.0 based on FHIR 4.0.1. Generated 2025-08-27
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change