Page tree
Skip to end of metadata
Go to start of metadata

Submitting WG/Project/Implementer Group

Financial Management / Da Vinci 

Justification and Objectives

This track will have the following objective:

  1. Test Consumer Apps connecting to a server that provides US Core resources that have been generated from Payer Claims information. The primary resources to be focused on for testing are:
    1. Encounter
    2. Condition
    3. Procedure
    4. Observation
    5. Provenance

NOTE: The $member-match operation will be covered as part of the 2020-09 DaVinci HRex/CDex/PCDE - Clinical Data, Payer Coverage Decision & Health Record Exchange Track 

Track Orientation

Kick Off 4:00 pm ET

Zoom Link: 

Track Orientation Session Recording: 


Track Wrap-up


Meeting Recording:


This track will use the following Zulim chat on chat.fhir.orgDa Vinci PDex

Da Vinci Sync up Schedule: 


Time (EDT)

Event Type


Wednesday, September 9th 4pm ETDa Vinci Track Kick-Off
Thursday, September 10th 9am - 5pm ETDa Vinci Track Sync-Up

11am - 12pm ETProvenance Discussion

3pm - 4pm ETCAQH Payer End Point Directory

4pm - 5pm ETPayer-to-Payer Exchange
Friday, September 11th 9am - 2pm ETDa Vinci Track Sync-Up
Friday, September 11th 2pm - 4pm ETDa Vinci Track Demos


This track will enable Payers and Providers to share claims and clinical data using FHIR API guidance specified in the US Core, PDex and HRex implementation guides. 


This track will use 4.0.1 version of FHIR.

Clinical input requested (if any)

The track requires clinical input to assess the value and priority of payer data to be added to a patient's record.

Related tracks

This track is a part of the larger Da Vinci Program. It also is related to the Financial Management track.

Payer Coverage Decision Exchange Track.

Proposed Track Lead

Mark Scrimshire, Track leads must be registered users on

Expected participants

How many do you expect to attend? To be confirmed: 4-6 people.

NameOrganizationEmail Address

Scrimshire, Mark

(Track Lead)


Please email if you are volunteering to provide a server or client to participate in testing for this track. You can also add your name to the list above.

Track Orientation

Track information sessions will be included in PDex Weekly Work Group Conference calls that are held on Friday's from noon - 1:00pm ET on the following dates:

  • 7/31/20, 8/7/20, 8/14/20, 8/21/20, 8/28/20, 9/4/20

 Visit the Conference Call page for the dial-in information.

Look for the call titled: Payer Data Exchange (PDex) (for Da Vinci Project).

Once participants have been established separate calls may be established. 


Sandbox Name: DaVinciPDex-R4-Payer
Sandbox Description: Payer FHIR R4 Endpoint for CDS-Hooks
Sandbox ID: DVPDexR4Payer1
Secured FHIR Server URL:
Open FHIR Server URL:
Sandbox FHIR Version: FHIR R4 (v4.0.0)

Organization resource: Organization-diamond-health.json

Bundle of Coverage Resources: Bundle-Coverage.json


Lauren Dent is a 62-year-old female, living in Wisconsin but she spends winters in Tampa Bay, FL.

Lauren works on a seasonal basis and has just accepted a new position with a new employer and has moved to Madison, WI to live with her daughter, leaving her previous home in La Crosse, WI. As a result of the move she has to select a new Primary Care Provider and a new Health Plan offered by her new Employer.

Lauren is in reasonable health but is managing a number of conditions:
* She has been diagnosed as Pre-Diabetic and is being treated with medications.
* She is taking medication for hypertension.
* She had a knee replacement 5 years ago.
* She had a procedure seven years ago to correct a problem with a disc in her lower back.
* A history of a normal colonoscopy 5 years earlier
* A history of a pneumovax and zostavax 4 years earlier.

Example 1:

The subject is switching from one health plan to a new health plan. 

During enrollment with the new health plan Lauren provides demographic information and the details of her old health plan, taken from her insurance card.

Lauren also gives the New Health Plan permission to request her health record from her old health plan.

The New Health Plan connects to the Old Health Plan and supplies a coverage record complete with old health plan information and member demographics to a /Patient/$member-match endpoint.

The old health plan performs a member match and returns a Patient resource for the matched member (or a 404 if not found).

The New Health Plan receives the Patient resource and an access Token to enable them to query the old health plans FHIR endpoint for specific clinical resources, or to perform a /Patient/{id}/$everything to get a bundle of records back that represent the member's clinical record.

Scenario Steps:

Use USCDI to represent payer data derived from claims, laboratory testing, diagnostic reports, immunization registries, data extracted from C-CDA documents and other sources.


Aegis has loaded Touchstone Test Scripts for this track's Use Cases HERE.  Please contact us at if you have any questions about using Touchstone or the scripts.

Security and Privacy Considerations

We are considering Security and Privacy topics out of scope for Connectathon. These issues are discussed in the Health Record Exchange (HRex) implementation guide.


PDEX FHIR Connectathon 25 ReportOut.pptx

Highlights from the Report Out Presentation 

Track Highlights:

  • PDex support for CMS Interoperability Rule
  • Payer End Point Directory – Payer-to-Payer Exchange
  • Payer Provenance – Kick Start the Chain of Trust


  • Leverage US Core wherever practicable
  • Add in elements to meet specific payer needs
    • MedicationDispense
    • Device v US Core Implantable Device
    • Payer Provenance
  • USCDI v1 > US Core v3.1.1 = PDex 


  • CAQH presented a POC for payer endpoint discovery
  • Needed for Payer-to-Payer Exchange (CMS Rule: 2022)
  • Compliments $Member-Match operation
  • Current situation is non-scalable


  • Resolving PayerProvenance Structure with Security WG
  • SourceFormat Value Set : May need to add PDF as a format
  • Need to address ease of requesting Provenance
    • revInclude could be a heavy load on a server
    • May recommend a _provenance global search parameter
      • Ie. Get Provenance for all resources in this searchset
  • Call for server support and testing

  • No labels