Short Description

Test the Da Vinci Patient Cost Transparency (PCT) Implementation Guide (IG)

Long Description

This is to test the Da Vinci PCT IG. The STU 1 version of this IG was balloted during the January 2022 Ballot Cycle. 

  • Test the profiles specified in the IG
  • Test the request/response of the Advanced Explanation of Benefits (AEOB) API which includes the Good Faith Estimates (GFE)


Test an Implementation Guide

Related Tracks?

Call for participants

Providers, Payers, and other related HIT vendors

Track Prerequisites

Knowledge of USCore, HRex

See IG underlying technologies page:

Track Lead(s)

Track Lead Email(s);

Specification Information

Reference Implementations



Note: The reference implementations recently moved to HL7 Foundry, old links to the Logica Sandbox will not work. 

PCT - Connectathon - Zulip Topic

Track Kick off Call

December 16 at 12:30pm ET

Join Zoom Meeting
Meeting ID: 933 5803 5002 Passcode: 8675309 One tap mobile +13126266799,,93358035002# US (Chicago) +16465588656,,93358035002# US (New York)


System Roles

  • Patient: The patient will consult with the submitting Provider to initiate the submission of a request for an AEOB. The patient will receive a URL and an AEOB ID via an email address and use those to retrieve the AEOB from the payer. A track participant can create a user interface to show the AEOB returned. Note: There could be multiple AEOBs returned.
  • Provider: The submitting provider will assemble all the information in a FHIR bundle that is needed for the payer to produce an AEOB. This includes one or more GFEs of items/services, associated codes, provider identification number, etc. The provider will validate the bundle and submit it to a payer endpoint. The provider will receive an AEOB ID to access the AEOB if desired.
  • Payer: The payer will receive the AEOB request, validate the request bundle, and process all the GFE data elements to produce an AEOB. This will involve applying various accumulators such as deductibles to produce a total cost to the patient, as well as the total covered and paid by insurance. The payer will generate an AEOB ID for the response and send that back to the patient via email. The processing to produce an AEOB will be asynchronous. When the AEOB is ready to view, the Payer will send an email notification to the patient (and the provider if needed) to notify them that the AEOB is ready to view.

Testing Scenario:

MRI Scenario:

Dr. Patricia Primary recommends a brain MRI for patient Eve Betterhalf to diagnose recurrent migraine headaches. Eve visits the submitting provider radiologist Dr. Christine Curie who composes an AEOB request for Eve to get a brain MRI from ABC Radiology. The payer (Medical USA, or MUSA) receives the request and sends Eve and Dr. Curie a URL with an AEOB ID to check on the progress of the AEOB. MUSA processes the AEOB and sends a notification via email that the AEOB is complete. Eve and Dr. Curie access the AEOB by authenticating with an OAuth service and download the AEOB.

Precondition: It is assumed that the payer endpoint is known to Dr. Curie, and that the payer has email addresses on file for Dr. Curie and Eve Betterhalf.

Success Criteria:  Show a complete roundtrip from AEOB request submission to querying an AEOB.

Bonus points:  Test various error conditions, including malformed FHIR, and missing data elements. Implement authentication via OAuth for Eve and Dr. Curie. Test business rule errors, such as inactive Coverage, etc. 

Test Scripts: Aegis Touchstone PCT scripts and IG package for validation are up on Touchstone under FHIRSandbox/DaVinci

These scripts include the MRI scenario and also dynamic PCT scripts which allow a tester to paste a GFE bundle into the request to test any scenario they wish.

Contact for any questions. 

Security and Privacy Considerations:

Bonus points for cross track testing with the FAST UDAP security track. 

Security and Privacy Considerations: TBD