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:
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: http://build.fhir.org/ig/HL7/davinci-pcde/
Connectathon Report-Out: TBD
This track will use what version of FHIR.
Clinical input requested (if any)
Yes to validate the
This track should be situated with other Da Vinci tracks, including but not limited to, PDEx, Provider Directory.
Proposed Track Lead
Mark Scrimshire, firstname.lastname@example.org
Joe Minieri, email@example.com
The PCovEx IG is focused on Payer to Payer Exchange. Three to four payer organizations are expected to participate in the Connectathon.
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.
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.
Success Criteria: Publish Treatment Plan
via OAuth2.0 REST API
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.
Success Criteria: Plan successfully retrieves a FHIR document containing a Diabetes Treatment Plan document.
Scenario Step 3 Create Sample Treatment Plan
Action: Create a Diabetes Coverage Decision Exchange Document (Treatment Plan)
Success Criteria: Receiving Server successfully retrieves a Treatment Plan
Scenario Step 4 Retrieve Sample Plan
Action: Retrieve Coverage Decision Exchange Document
via an OAuth2.0 transaction
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:
Security and Privacy Considerations
Identify any expectations around security (e.g. will TLS, mutual-TLS, OAuth, etc. be required to participate
The exchange will not be OAuth2.0 based for this Connectathon.
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.