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

This page will be used to describe the Da Vinci reference implementation for the Payer Coverage Data Exchange use case. The goal of this reference implementation is to demonstrate the need to exchange active treatments for a patient as they move from one payer to another as defined in the implementation guide. The reference implementation is not intended to reproduce all the functionalities of a payer's data or data system or an EHR. 

Implementation Guide


Mark Scrimshire and Julia Skapik - Use Case Leads

Lloyd MacKenzie  - IG Author

May Terry, Joseph Minieri, Dave Hill - RI developers

Bob Dieterle - Technical Director

HSPC Sandbox - Hosting environment -

PCDE FHIR Implementation Guide - 

During the Connectathon the Zulip Channel we will use is: TBD


Jacksonville, FL Da Vinci Connectathon - May 2019 – Payer Coverage Decision Exchange (PCDE) Use Case Convened

Virtual Connectation #1 - August 28, 2019 - PCDE Document FHIR example initial review and message exchange (PCDE document pre-existing)

Virtual Connectation #2 - September 4, 2019 - PCDE Document FHIR example refinement and message exchange (PCDE document CommunicationRequest)

Atlanta - September 2019 - FHIR Connectathon #22 Da Vinci PCDE Track

PCDex IG Balloting - September 2019 Ballot Cycle


Resources will be built using FHIR R4.

Test Script: DaVinci-PayerCoverageDecision-Touchstone_TestScript.docx


Authentication and Authorization (steps 1a-1e) are out of scope for the 2019 Connecathons.

HTTP Response Status Codes by Step

Step 1a:

  • Successful Login
  • Failed Login - Unauthorized (401)

Step 1c:

  • Successful Authentication
  • Failed Authentication - Forbidden (403)

Step 1d:

  • Authorization Granted
  • Authorization Not Granted / Cancel - Forbidden (403)

Step 2:

  • Post Succeeds - Created (201)
  • Post Fails 

Step 3:

  • Post Succeeds (201?)
  • Post Fails 

Step 4:

  • Get Succeeds (200)
  • Get Fails (400, 401, 408)

Issues to resolve:

  • No Active Treatment Plan
    • When will this get flagged?
      • On Patient Authorization? 
      • On Communication Request? 
      • On Communication Post?

FHIR Profiles

  • PCDE documents will conform to the pcde-bundle FHIR profile.
  • Follow US Core Profile validation rules

Scenario 1 

FHIR Server Endpoints:

The August 28 Virtual Connectathon will provide one FHIR server endpoint for both the new health plan and old health plan if needed:

Participants can provide their own FHIR server endpoint for exchange as either the old or new health plan.

Types of Request:

August 28 Connectahon:

  • GET PCDE document bundle
  • POST PCDE document bundle

Sept 13-14 Atlanta HL7 FHIR Connectation 22:

  • Authentication and OAuth2.0 Authorization
  • Post CommunicationRequest to Old Health Plan
  • Post Communication to New Health Plan

REST Actions

  • Post CommunicationRequest
  • Post Communication

Audience focus: Developers/Implementers:

Information to fill in...

  • FHIR Server Endpoints
  • Types of requests.
  • Expected status codes.
  • Payload format (only if it's useful)
  • Example search queries.
  • Architectural diagram.

This is a single-point of truth of what "payer data exchangers" will agree on for their own reference implementations.

  • No labels