Da Vinci Payer Data Exchange
2.1.1 - STU2 Ballot
Da Vinci Payer Data Exchange
2.1.1 - STU2 Ballot
Da Vinci Payer Data Exchange, published by HL7 International / Financial Management. This guide is not an authorized publication; it is the continuous build for version 2.1.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-epdx/ and changes regularly. See the Directory of published versions
| Page standards status: Informative |
The PDex Implementation Guide (IG) identifies three actors and specifies three interactions that occur. Each interaction differs based upon the actors involved and the data payload that is being communicated.
Actors:
Interactions:
The STU2.1 Version of the PDex IG introduces two important new Interactions:
Payer-Provider Bulk Exchange is a bulk exchange of data for Members that have not chosen to opt-out of data sharing with providers. This exchange effectively supercedes the original Payer Provider exchange that used CDS Hooks.
Payer-to-Payer Bulk Exchange is a bulk exchange of data for Members that have opted in to enable a payer to retrieve data from a prior plan.
The Blue Button 2.0 initiative (The CMS Blue Button 2.0 API and the CARIN Consumer-Directed Exchange IG) specifies the profiles used to communicate claims information between health plans and their members. The PDex Implementation Guide (IG) is focused on presenting a member's health and claims information as FHIR clinical profiles (based on US Core) that are more easily consumed by Electronic Medical Records (EMR) systems.
Ad-hoc PDex Member History Requests via CDS Hooks provides a mechanism for providers/clinicians to request information from health plans about the medical history of their patient as part of their regular workflow. The requestor should be aware that the Health Plan may not have a complete medical history of services provided due to delays in billing, patient ability to pay for services, etc.
The same FHIR profiles used to support communication between the health plan and providers will also be used to provide the payload of member health information which will be exchanged between health plans when authorized by a health plan member.
While the authorization and communication mechanisms may differ between the provider-to-payer exchange and the member-authorized Payer-to-Payer exchange or member-authorized Payer to Third-Party Application exchange the API interactions and data formats may be the same.
The objective with the above approach is to:
The first release of the PDex IG will focus on the following in-scope items. Items in the deferred scope category will be considered for future iterations of the IG or will be accommodated via an alternative Da Vinci Use Case. Out of scope items are not being considered at this time.
Member/Patient Consent for scenarios covered in this Implementation Guide fall into two areas:
Under the CMS Prior Authorization Rule (CMS-0057) the Payer-to-Payer API is an op-in API. A member must actively opt-in to have their payer retrieve data from their prior payer. The member must provide the necessary coverage and demographics information to their health plan to enable them to be matched by their prior payer.
Claims and Encounter data included in the data exchange is required to exclude financial data.
Provider-Health Plan exchange of data is covered by the Health Insurance Portability and Accountability Act (HIPAA) under the Treatment Payment and Health Care Operations provision.
Under the CMS Prior Authorization Rule (CMS-0057) the Provider Access API is an opt-out API. A member's data is included by default in an exchange with an in-network provider unless the member has chosen to opt-out of sharing with any providers.
Claims and Encounter data included in the data exchange is required to exclude financial data.
The CMS Interoperability and Patient Access Rule requires that a member new to a health plan SHALL be able to request that their information be passed from their old health plan to their new health plan.
The CMS rule also specifies that all data from the member's health record that is held by the health plan since January 1, 2016, be available via API.
A Member SHALL also be able to use APIs to share information with Third Party Applications.
The Member-mediated Information Exchange method will build upon established OAuth2.0 protocols for patient access to their health and claims information that enables the sharing of information with third-party applications. The process of Member Authentication, typically using the member's user credentials from the Health Plan's portal, and OAuth2.0 authorization to share will form the basis of the member Consent to share.
The health history payload for the exchange would be the same FHIR resources that are passed to providers under the Provider-Payer exchange scenario. The Use Case Scenarios page contains examples of how the health history could be utilized.
The exchange of healthcare network/directory information and Pharmacy network/directory information is covered in the PDex-Plan-Net IG.
The exchange of Prescription drug formulary information is covered in the PDex-formulary IG.
The OAuth2.0-based exchange is covered in detail in the Member-Authorized OAuth2 Exchange.
This Implementation Guide is dependent on other specifications. Please submit any comments you have on these base specifications as follows:
Feedback on CDS Hooks should be posted to the CDS Hooks GitHub Issue List
Feedback on this Implementation Guide and supporting HL7 specifications should be submitted as issue tickets via the HL7 FHIR Jira system. Login to Jira and create an issue. Next enter the following information to identify the relevant specification:
Project: FHIR Specification Feedback Issue Type: Change Request Specification:
Individuals interested in participating in Payer Data exchange (PDex) or other HL7 Da Vinci projects can find information about the Da Vinci accelerator project here.
This Implementation Guide uses terminology, notations and design principles that are specific to FHIR. Before reading this implementation guide, it's important to be familiar with some of the basic principles of FHIR as well as general guidance on how to read FHIR specifications. Readers who are unfamiliar with FHIR are encouraged to read (or at least skim) the following prior to reading the rest of this Implementation Guide.
Wherever possible, the PDex IG will use established US Core STU 3.1.1 Profiles or US Core STU 6.1.0 Profiles. Where information must be presented in FHIR resources that fall outside of the US Core Implementation Guide (IG) the HL7 Da Vinci Health Record exchange (HRex) IG will define the necessary Da Vinci FHIR profiles or will refer to other Implementation Guides, as necessary.
Where profiles are specific to the PDex use case, the profiles will be defined in this guide.
The PDex Implementation Guide (IG) will utilize existing HL7 FHIR Profiles in the following order of descending priority:
Note: The ONC HTI-1 rule has set a date for January 1, 2026 when US Core 6.1.0 becomes the base standard, superceding US Core 3.1.1. Prior to that date Implementers may choose to implement either version of US Core.
This Implementation Guide recognizes that Electronic Medical Record systems used by providers may have existing FHIR APIs that are based on versions of FHIR prior to FHIR R4, with DSTU2 (Argonaut) being the most popular implementation.
Amongst Health Plans there has been limited adoption of FHIR specifications and FHIR APIs. Therefore, for profiles and APIs identified in this IG, the FHIR R4 version SHALL be used.
The PDex IG defines four types of data payload:
The CMS Interoperability rule requires Health Plans to make available data they hold for a member from Jan 1, 2016, onwards. When data is transferred from one plan to another the health plan receiving the data request is only obligated to share member health data for Five years prior to the date of the request. The data can include:
- CARIN Blue Button Claims data (without the financial content)
- US Core Clinical Data (Structured Data)
- Unstructured clinical data used to determine a prior authorization decision
- PDex Prior Authorization profile.
The Directory and Formulary data payloads are covered in their respective Da Vinci Implementation Guides.
All resources available via a FHIR API endpoint SHALL be declared in a FHIR CapabilityStatement.
The FHIR CapabilityStatement defines the resources and operations supported by the resources exposed via the FHIR API.
The Read and Search Operations SHALL be supported for the FHIR Profiles covered in this payload section. The V-Read and History operations MAY be supported.
The FHIR Resources that comprise the Member Clinical and Claims-derived history, otherwise referred to as the "Member Health History" SHOULD include the following profiles where payers have data to support the use of those profiles:
This IG supports three versions of US Core that represents a member's health history.
To understand the changes between US Core 3.1.1, US Core 6.1.0 and US Core 7.0.0 check out the Cross Version Comparisons Section section of the US Core 6.1.0 and US Core 7.0.0. IGs.
In addition, US Core 3.1.1 uses the Vital Signs Profile from the FHIR Specification.
The FHIR CapabilityStatement defines the resources and operations permitted on the resources exposed via the FHIR API.
The Permitted Operations for the FHIR Profiles covered in this payload section are defined in the PDex Server Capability Statement
The provision of a Member-accessible Healthcare Network Directory API is detailed in the companion, subsidiary Payer Data Exchange Plan Network Implementation Guide (PDex-plan-net IG).
The provision of a Member-accessible Pharmacy Network Directory API is detailed in the companion, subsidiary Payer Data Exchange Plan Network Implementation Guide (PDex-plan-net IG). A Health Plan's Pharmacy Network SHOULD be expressed using the same FHIR profiles used for the Healthcare Network Directory.
When a Health Plan provides prescription drug coverage the list of covered medications is known as a "Formulary." The provision of a Member-accessible Prescription Drug Formulary API is detailed in the companion, subsidiary Payer Data Exchange Drug Formulary Implementation Guide (PDex-formulary IG).
IG © 2024+ HL7 International / Financial Management. Package hl7.fhir.us.davinci-pdex#2.1.1 based on FHIR 4.0.1. Generated 2024-11-20
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change