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

Artifacts - Supporting References


Connectathon Track Communications

PCDE has merged with PDex to a combined track because they share a common use case scenario to test the $member-match operation.


This track will use what version of FHIR.

R4

Clinical input requested (if any)

Yes to validate the contents of the data included in the PCDE Coverage Transition Document.

Related tracks

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

Proposed Track Leads


Participants

The PCDE IG is focused on Payer to Payer Exchange. The following organizations are expected to participate in the Connectathon.

  • Mettle Solutions
  • MITRE
  • Cognizant ($member-match only)
  • Cigna ($member-match only)


Track Orientation Webinar

A webinar was held on Friday, April 17 at 2PM ET.


System Roles

Old Health Plan (aka: source payer):

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.


New Health Plan (aka: 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.

Use Case Scenario #1 - Member Discovery

Goal: to identify what member data is minimum and necessary to have a deterministic patient match.

Role 1 Source Server

Prerequisites/Assumptions:

  • The old health plan and new health plan have not previously exchanged the unique member ID to be used in the exchange of a PCDE coverage transition document.
  • There is clear guidance on the use of a new HL7 Da Vinci PDex $member-match operation used for supporting member discovery. 


Scenarios

  • The old health plan receives a $member-match message from the new healthplan, which includes the following resources:
    • Patient
    • 2 coverage resources, one reflecting coverage information from the new health plan, and one reflecting coverage details about the old health plan.
  • The old health plan returns a unique member identifier that can be used for the PCDE message exchange. Reference the HL7 Da Vinci PDex $member-match documentation for further details and an example.


Role 2 Receiving Server

Prerequisites/Assumptions:

  • This is a newly added enrollee to the new health plan.

Scenarios

  • Identify the member in a way that ensures a singular and deterministic match, using the $member-match operation. The HL7 Da Vinci PDex $member-match message from the new healthplan includes the following resources:
    • Patient
    • 2 coverage resources, one reflecting coverage information from the new health plan, and one reflecting coverage details about the old health plan.
  • The new health plan receives a response either containing a unique member ID that can be used for the PCDE message exchange, or an error.
    • note: the format of the return message, and list of potential errors is TBD pending a specification on $member-match. 

Use Case Scenario #2 (optional) - Old Health Plan Generates a PCDE Bundle

Scenarios

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.

Precondition:

  • The unique member identifier for exchange of coverage transition data has been determined via the HL7 Da Vinci PDex $member-match exchange.
  • Manually compiled Treatment plan with minimum information.


Use Case Scenario #3 (optional) - New Health Plan comprehensively ingests all sections of the PCDE Bundle

Pre-requisites:

  • A PCDE bundle received by the new health plan. 
  • The PCDE bundle contains content representative of all of the sections and entries in a PCDE bundle as specified in the FHIR IG, namely an activeTreatment (carePlan, priorCoverage, supportingInformation) and OtherInformation.

The new health plan will parse and display all of the sections and entries within the PCDE bundle in a way that is understandable by a payer Utilization Manager or clinician that determines medical necessity.

Use Case Scenario #4 - PCDE supports Data Sharing Workflow - Bundle is requested using the TASK resource

Pre-requisites:

  • A PCDE coverage transition document has not been created prior to the request.


Supporting References:


Scenario Steps:

  • The old health plan receives a Task message from the new health plan.
  • The old health plan responds sending the PCDE Bundle to the new health plan.

Use Case Scenario #5 - New Health Plan requests a PCDE bundle when none previously existed.

In this use case, the old health plan receives a request for a PCDE bundle, and the PCDE bundle did not previously exist. It is the most common and probable case that a period of time elapses, likely in days, before a PCDE bundle is ready to send. This implies some messaging means is needed for the new health plan to receive the bundle when it is ready.

Pre-requisites:

  • The unique member identifier for exchange of coverage transition data has been determined via the HL7 Da Vinci PDex $member-match exchange.
  • A PCDE bundle received by the new health plan. 
  • A PCDE coverage transition document has previously been created and sent from an initial request by the new health plan.

Note: If the old health plan does not auto-generate a PCDE Bundle (scenario #2), then you can use the following pre-canned example to modify/send for the payload.


Sub-Scenario #1: Updates through polling

  • The new health plan will check for any new updates by polling the old health plan for the PCDE bundle every X period of time.


Supporting References:


TestScript(s)

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 PCDE 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

Touchstone Tests are found at: Touchstone_DaVinci_PayerCoverageDecEx_Scripts

Please create a Touchstone user account (free) associated to the DaVinci organization if you have not already in order to run your systems through the test scripts.



Security and Privacy Considerations

  • Member-mediated authentication using OAuth is not included in our scenarios, and is out of scope.
  • Security and privacy measures between the old and new health plans are out of scope. It is assumed that both entities are trusted sources.


  • No labels