Da Vinci Payer Data Exchange
2.1.0 - STU2 Ballot
Da Vinci Payer Data Exchange
2.1.0 - 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.0 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 covers the following data types:
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 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:
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 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 Capability Statements in this IG are:
This implementation guide uses specific terminology such as SHALL, SHOULD, MAY to flag statements that have relevance for the evaluation of conformance with the guide. As well, profiles in this implementation guide make use of the mustSupport element. Base expectations for the interpretations of these terms are set in the FHIR core specification and general Da Vinci-wide expectations are defined in HRex.
For querying and reading PDex and US Core Profiles, Must Support on any profile data element SHALL be interpreted as follows:
PDex Responders SHALL be capable of populating all data elements as part of the query results as specified by the PDex and US Core Server Capability Statement. PDex Requestors SHALL be capable of processing resource instances containing the data elements without generating an error or causing the application to fail. In other words PDex Requestors SHOULD be capable of displaying the data elements for human use or storing it for other purposes. In situations where information on a particular data element is not present and the reason for absence is unknown, PDex Responders SHALL NOT include the data elements in the resource instance returned as part of the query results. When querying PDex Responders, PDex Requestors SHALL interpret missing data elements within resource instances as data not present in the PDex Responder’s system. In situations where information on a particular data element is missing and the PDex Responder knows the precise reason for the absence of data, PDex Responders SHALL send the reason for the missing information using values (such as nullFlavors) from the value set where they exist or using the dataAbsentReason extension. PDex Requestors SHALL be able to process resource instances containing data elements asserting missing information.
Additional information about MustSupport can be found in the Da Vinci HRex Conformance Page and the US Core Must Support page.
NOTE: Typically PDex Responder Actor = Server and PDex Requestor Actor = Client NOTE: Readers are advised to understand FHIR Terminology requirements, FHIR RESTful API based on the HTTP protocol, along with FHIR Data Types, FHIR Search and FHIR Resource formats before implementing PDex requirements.
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.0 based on FHIR 4.0.1. Generated 2024-12-13
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change