This page is part of the Da Vinci Payer Data Exchange (v0.1.0: STU 1 Ballot 1) based on FHIR R4. The current version which supercedes this version is 1.0.0. For a full list of available versions, see the Directory of published versions

1-1 Overview

This guide is based on the HL7 FHIR standard, as well as the CDS Hooks, SMART on FHIR and OAuth2.0 standards, which build additional capabilities on top of FHIR. This architecture is intended to maximize the number of clinical systems that conform to this guide as well as to allow for easy growth and extensibility of system capabilities in the future.

Implementers of this specification therefore need to understand some basic information about these specifications, which act as building blocks for this Implementation Guide.

The purpose of this Implementation Guide is to enable data to be exchanged between Health Plans (Payers) and Practitioners (Providers) and via Member-authorized exchange between Health Plans and Third Party Applications. Health Plans SHOULD wherever possible present the information using vocabularies that are understood by the Provider.

All data exchanged by Health Plans using the interactions covered in this IG SHALL be transformed to FHIR R4 resources. Health Plans MAY have both data from clinical and claims sources that they store in their Systems of Record. This IG does not require Health Plans to store this data in FHIR formats, only to be able to transform it to FHIR resources for the purposes of data exchange with Providers, other Health Plans and Third Party Applications for the interactions covered in this IG.

There are items in this guide that are subject to update. This includes:

Value Sets
Vocabularies (X12, NUBC etc.)
Examples

The Vocabulary, Value Sets and codings used to express data in this IG are subject to review and will be reconciled with X12.

The schematic shown below provides an overview of this transformation.

Health Plans receive data from many other sources that contribute to a Member’s Health History. In addition to medical claims Health Plans may receive C-CDA documents or HL7 V2 messages, such as Admit, Discharge, Transfer (ADT) Messages. As an example the diagram below shows how an ADT Message can be transformed into HL7 FHIR Resources:

1-1-1 Exchange Methods

This IG covers three methods of information exchange:

CDS-Hooks and SMART-on-FHIR
OAuth2.0 Member-authorized Exchange
Bulk FHIR exchange via alternate secure channels

1-1-1-1 CDS-Hooks and SMART-on-FHIR

An overview of the flow of the CDS-Hooks and SMART-on-FHIR exchange is shown below. This exchange flow is used for communication between Providers and Health Plans.

1-1-1-2 OAuth2 Authorized Exchange

The well defined mechanism for enabling Member/Patient authorization to share information with an application using the FHIR API is to use OAuth2.0 as the Authorization protocol. The member SHALL authenticate using credentials they have been issued with by the Health Plan. This is typically the member’s customer portal credentials.

After authenticating the Member SHALL be presented with an Authorization screen that enables them to approve the sharing of information with the Third Party, or new Health Plan, Application that has client application credentials registered with the Health Plan.

An overview of the OAuth2.0 Flows using the FHIR API are shown below:

1-1-1-3 Bulk FHIR via Alternate Secure Transport

The Patient-everything operation enables the use of Bulk FHIR, using such formats as ND-Json. This IG does not define the alternate secure transport mechanisms that may be used for exchange between Health Plans. However, the IG does allow for the use of Bulk FHIR formats to exchange data for an individual member where the member has authorized that exchange.

1-1-2 Provenance

Since Health Plans compile information from many sources to create a Member’s Health History it is important that data traceability is maintained. The HL7 FHIR Provenance resource is used for this purpose. It is used to identify the source of information, the agents the data passed through and the actions the performed on the data.

Health Plans SHALL maintain provenance records that they receive as part of any exchange of FHIR data. Where a FHIR Provenance resource is not provided, such as when data is received from other non-FHIR sources, the Health Plan shall create FHIR Provenance record(s) to identify the source of the information being received and the actions that is taken on the data, such as converting from one format to another. Health Plans SHALL pass on Provenance records in any PDex information exchange.

Provenance is covered in more detail in Section 6-7 Handling Data Provenance.