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

Submitting WG/Project/Implementer Group

HL7 Da Vinci Payer Data Exchange (PDEx)

Justification and Objectives

The purpose of this Track is to enable data to be exchanged between Health Plans (Payers) via Member-authorized exchange using an OAuth 2.0 authorization.

This track will use what version of FHIR.


Clinical input requested (if any)

The Track will use US Core Resources and other profiles defined in Da Vinci Implementation Guides, such as HRex. The data will be derived from a Payer's claims and other clinical resources.

Related tracks

2019-09 Da Vinci Payer Coverage Decision Exchange

Payer representatives will likely be involved in other Da Vinci or CARIN Blue Button Tracks.

Proposed Track Lead

Mark Scrimshire,

 Track leads must be registered users on

Expected participants

Payer Representatives. At previous Connectathon this track 8-10 participants.

Track Orientation

Orientation will be held during an upcoming PDex weekly conference call on Either August 2nd or 9th. 

PDex weekly conference calls occur at Noon ET on Fridays. The Orientation section of the call will be recorded.

A webinar will be hosted on date at time to share further participation information about this track.

System Roles

Source Health Plan Server - Hosting data for a departing member.

Receiving Health Plan Server - Hosting an account for a newly enrolled member.

Please include information here regarding how much advance preparation will be required if creating a client and/or server.

Participants may use the HSPC Sandbox servers used for previous PDex connectathons as a Source or Receiving Server.

Participants wishing to test with their own systems as a source system will need to publish a FHIR API Endpoint and provide test user accounts with data that supports the Patient/$Everything operation where the profiles encapsulated in the $Everything bundle conform to the HL7 FHIR R4 US Core Profiles.

Participants wishing to test with their own systems as a receiving system will need to be able to connect to a target FHIR Server using R4 and be able to retrieve and validate HL7 FHIR R4 US Core profiles. The retrieval operation could be a Patient/$Everything operation or could make individual calls to specific R4 profiles available in the source servers Capability Statement.

Role 1 Source Server


There are three scenarios to be tested:

  1. IN-FLOW: Member-authorized Exchange of Patient/$Everything bundle. Member connects to old plan from new plan and authorizes an exchange directly. Previously tested in Jacksonville. This exchange also supports Member-authorized exchange with a third-party application.
  2. INDIRECT-FLOW: Member-authorized exchange of Patient/$Everything bundle via a request made by the Member to the New Payer. i.e. Please go and get my data from my old plan.
  3. ENROLLMENT-FLOW: Payer-to-Payer HIPAA Business, Treatment and Operations covered exchange of Patient/$Everything bundle. When a new Member is enrolled in a health plan the plan identifies the old health plan and requests the Member's information from the old plan without requiring an authorization by the member.

These scenarios can use the same mechanisms to perform the exchange. ie. REST-based GET to an OAuth 2.0 protected API Endpoint . The difference will be the entity requesting an OAuth2.0 token.

Present a HL7 FHIR R4 API with a capabilityStatement that supports the following profiles and operations:


  • US Core Patient
  • Da Vinci HRex Coverage
  • US Core Encounter
  • US Core Procedure
  • US Core DiagnosticReport
  • US Core Observation
  • Da Vinci HRex MedicationDispense


  • Patient/$Everything

The API should be protected via OAuth2.0 that complies with the SMART-on-FHIR app launch framework

Role 2 Receiving Server


For a newly enrolled member initiate an OAuth 2.0-based connection to the member's prior payer by following the SMART-on-FHIR app launch framework.

Query the source FHIR Server for the member and retrieve their Health History using the Patient/$Everything operation.

Process the received bundle and store the information as FHIR resources in the receiving payer system as part of the newly enrolled member's health history.

Describe the different scenarios participating systems can engage in during the conenctathon. Each scenario should provide sufficient description that participants can appropriately construct their software in advance to prepare to interoperate during the connectathon.

Scenario Step 1 Receiving Server Connects to Source Server

Action: Receiving Server connects to Source Server using  SMART-on-FHIR app launch framework

Precondition: Source Server has Receiving Server identified as a valid OAuth2.0 application

Success Criteria: Receiving Server can connect to Source Server and retrieve CapabilityStatement

Bonus point:

Scenario Step 2 Source Server accepts connection from Receiving Server and enables search for a member

Action: Source Server allows connection from a Receiving Server and supports search for a member by MemberId

Precondition: Source Server has Receiving Server identified as a valid OAuth2.0 application.

Receiving Server has OAuth2.0 credentials for Source Server API Endpoint incorporated into connection workflow

Success Criteria: Receiving Server retrieves the Patient Resource for a member via a member id search

Bonus point: Source Server presents Observation resources coded from HL7 V2, 837 Claim and CCDA sources with associated Provenance Resource records as per guidance provided in PDex IG Companion Guide - Laboratory Reporting Resources.

Scenario Step 3 Receiving Server retrieves $Everything operation for Member

Action: Receiving Server requests the Patient/$Everything and retrieves all member health history as a paged bundle from the Source Server 


Success Criteria:

Bonus point: Systems support the request and return of the Patient/$Everything operation as a non-paged Bulk FHIR conformant NDJson transaction.  

Scenario Step 4 Receiving Server adds Patient/$Everything content to member record in the Receiving Payer's system

Action: The Receiving Server processes the records returned by the Patient/$Everything operation and adds the content to the new member's health history 

Precondition: Successful completion of Patient/$Everything operation with Source Server.

Success Criteria: Member Health History from Source Server is visible with Receiving Server's Member Health History.

Bonus point: Request individual records, or categories of US Core resources from Source Server and add to Member Health History on Receiving Server


Indicate any test scripts that will be used to help verify system behavior

Test Scripts will be created using the Aegis Test Script Template and will be linked here.

Test Scripts will cover:

  • Access Not Authorized - 403 error
  • Member Not Found Search - 404 error
  • Paged Bundle for Patient/$Everything
  • Non-Paged Bundle for Patient/$Everything
  • Bulk FHIR NDJson $Patient/$Everything non-paged bundle

Security and Privacy Considerations

Identify any expectations around security (e.g. will TLS, mutual-TLS, OAuth, etc. be required to participate

OAuth 2.0 will be used for Authorization. Connections will follow the SMART-on-FHIR app launch framework.

A Receiving Server should be authorized to search for any member via their Member ID and retrieve the data for that member.

  • No labels