Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Submitting WG/Project/Implementer Group

Da Vinci Payer Coverage Decision Exchange

Justification and Objectives

When a health plan member transitions from one health plan to another their treatment plans and decisions for existing health conditions should transition with them. Payer coordination is an important element to care continuity. For example, a patient who relies on home oxygen should not be at risk of hospitalization because a new payer is not aware of the requirement until after the oxygen runs out. By enabling an authorized transfer of information from the original payer to the new payer, the new payer can have access to information about what therapies are currently in place and the rationale for them, as well as what precursor steps have been taken to demonstrate the medical necessity and appropriateness of the current therapy. By automating this exchange and maximizing the computability of the information shared, a process that frequently takes weeks or months can be reduced to a few days or even minutes-- reducing costs and improving patient care safety, quality and experience.This need for continuity across payers has been recognized also by the United States’ largest payer, the Centers for Medicare and Medicaid Services (CMS), who has proposed in 2019 to require the exchange of data about ongoing and planned treatments covered by a previous payer and send it to a current payer along with the metadata around the conditions they are treating and how the determination was made.

This Connectathon track will use the Patent Coverage Decision Exchange (PCDEx) Implementation Guide as the basis for the track. This implementation guide defines standardized mechanisms for a patient or payer to enable a transfer of “current active treatments” with other relevant metadata and coverage-related information from a prior payer to a new payer. It also defines a standardized structure for organizing and encoding that information to ease its consumption by the new payer organization. The PCDEx IG should enable any individual's potential active treatments, metadata, and supporting documentation to be transmitted from one payer to another. 

The objectives of this connectathon include:

  • Patient authorizes an exchange from old payer to new payer
  • Can exchange treatment plans organized by therapy but including relevant conditions, providers, progress, and orders needed to execute continuation of therapy
  • Can append prior authorization to a treatment plan
  • Can append other attachments to a treatment plan
  • Can include data on prior unsuccessful or related therapies to an active treatment
  • Can include disease or care management programs
  • Where available, data from clinical systems and providers can be reused in these transmissions

Reference Implementation

A page has been created to document the requirements for the Reference Implementation that is related to the Payer Coverage Decision Exchange IG. You can find the page here:

Payer Coverage Decision Exchange Reference Implementation

Implementation Guide:

Connectathon Report-Out: 

This track will use what version of FHIR.


Clinical input requested (if any)

Yes to validate the 

Related tracks

This track should be situated with other Da Vinci tracks, including but not limited to, PDEx, Provider Directory.

Proposed Track Lead

Mark Scrimshire,

Joe Minieri/MITRE, 

Expected participants

The PCovEx IG is focused on Payer to Payer Exchange. Three to four payer organizations are expected to participate in the Connectathon.

IMO (Possibly - GDolin will confirm ASAP)

Track Orientation

A webinar will be hosted on Go To Meeting to share further participation information about this track.

Details about the Connectathon track will be presented on a weekly PCDEx conference call which will be recorded.

System Roles

Source Payer System:

The source payer will construct a Coverage Decision Exchange document and make this available for retrieval by a new payer.

The Source Payer will need to organize treatment information using care plan and append supporting documentation such as observations and diagnostic reports.

Receiving Payer System:

The receiving payer will connect to the source payer system and retrieve the document for a member and import the document into their own system.

An OAuth 2.0-based workflow will be used for the exchange between payer systems.

Role 1 Source Server


Present a HL7 FHIR R4 API with a capabilityStatement that supports the profiles and documents identified in the Payer Coverage Decision Exchange IG

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 a Treatment Plan document.

Process the received document and store the information as FHIR resources in the receiving payer system.


Describe the different scenarios participating systems can engage in during the connctathon. 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 Create Diabetes Treatment Plan

Action: Source Server creates a Diabetes Coverage Decision Exchange Document (Treatment Plan) for a Health Plan Member.


  • Manually compiled Treatment plan with minimum information.
  • Receiving Server is registered in Source Server system with valid OAuth2.0 credentials

Success Criteria: Publish Treatment Plan via OAuth2.0 REST API

Bonus point:

Scenario Step 2 Retrieve Diabetes Treatment Plan

Action: Receiving Server retrieves Coverage Decision Exchange Document via an OAuth2.0 transaction by New Payer querying old payer for the newly enrolled member.


  • Receiving Server is registered in Source Server system with valid OAuth2.0 credentials

Success Criteria: Plan successfully retrieves a FHIR document containing a Diabetes Treatment Plan document.

Bonus point:

Scenario Step 3 Create Sample Treatment Plan

Action: Create a Diabetes Coverage Decision Exchange Document (Treatment Plan)


  • FHIR Documents to support a treatment plan are available.
  • Receiving Server is registered in Source Server system with valid OAuth2.0 credentials

Success Criteria: Receiving Server successfully retrieves a Treatment Plan

Bonus point:

Scenario Step 4 Retrieve Sample Plan

Action: Retrieve Coverage Decision Exchange Document via an OAuth2.0 transaction


  • FHIR Documents to support a treatment plan are available.
  • Receiving Server is registered in Source Server system with valid OAuth2.0 credentials

Success Criteria: Plan successfully retrieves a FHIR document containing a CarePlan and supporting information.

Bonus point: Validate content of Treatment Plan document


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

Test scripts will be developed in conjunction with Aegis based upon the PCovEx IG content.

Test Scripts will cover:

  • Access Not Authorized - 403 error
  • Member Not Found Search - 404 error
  • Search and retrieve Treatment Plan document - 200 status
  • Treatment Plan not Found - 404 error

Security and Privacy Considerations

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

The exchange will be OAuth2.0 based.

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