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)

Type

Test an Implementation Guide

Track Lead(s)

Corey Spears  Vanessa Candelora 

Track Lead Email(s)

vanessa.candelora@pocp.com, cspears@mitre.org

Specification Information

https://build.fhir.org/ig/HL7/davinci-pct/

Call for participants

Providers, Payers, and other related HIT vendors

Zulip stream

PCT - Connectathon - Zulip Topic

Track Implementers Connection Call

6/17/2022 at 12:30pm Eastern

Recording - CMS Connectathon Implementer Connection Call (6/17) Recording 

Orientation Presentation:

 

Track Overview session:

Testing Scenario:

System roles:   

  1. 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.
  1. 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.
  1. 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.

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 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 Touchstone_Support@aegis.net for any questions. 


Security and Privacy Considerations:

OAuth 2.0 security should protect all payer endpoints.


Infusion of Drug Scenario (WIP):

This is under development. 

see Drug infusion Scenario


Security and Privacy Considerations: TBD 


Track Highlights: