Da Vinci Payer Data Exchange
2.2.0 - STU 2.2 United States of America flag

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.2.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

Payer-to-Payer Exchange (bulk)

Page standards status: Informative

Previous Page - Payer-to-Payer Exchange (single member)

Payer-to-Payer API bulk data guidance in this version of the IG is draft only. It has not appeared in ballot but has been tested at multiple Connectathons. This has been incorporated to meet the requirements of the CMS Prior Authorization Rule (CMS-0057)

When requested by a Health Plan member, the Exchange of clinical data, as scoped by USCDI version 1 or version 3 and represented in FHIR by US Core 3.1.1 or 6.1.0, is a requirement of the Advancing Interoperability and Prior Authorization Rule (CMS-0057) published in February 2024. The rule requires Payers to support the bulk exchange of data for multiple members.

The PDex Payer-to-Payer FHIR-based bulk data exchange in this section of the IG supports the exchange of data for a single member, or multiple members.

Bulk Payer-to-Payer exchange SHALL be accomplished by the use of the §pdex-129 Bulk FHIR API specification.

The Advancing Interoperability and Prior Authorization Final Rule requires that the Member consent to the retrieval of their data from their prior health plan.

The Advancing Interoperability and Prior Authorization Final Rule requires that health plans SHALL limit the data exchanged to data with a service date no §pdex-130 earlier than 5 years prior to the date of the data request. Prior Authorizations SHALL be limited to current/active Prior Authorizations in addition to Prior §pdex-131 Authorizations that have changed status within the last year, as of the date of request for information.

Status changes of Prior Authorizations will be determined by the Prior Authorization Processor. This IG is representing the change in status. For example, a Prior Authorization may be denied, but then approved upon appeal. A prior Authorization might be pended and then subsequently approved or denied.

If the Prior Authorization processor changes the status of the Prior Authorization then the date of change will be recorded, In the Provider and Payer-to-Payer APIs and Prior Authorization that has changed status in the previous 12 months (from the date of enquiry) SHALL be included in the API response. §pdex-132

The Advancing Interoperability and Prior Authorization Final Rule requires that Prior Authorizations exchanged via the Payer-to-Payer Exchange API SHALL include §pdex-133 the supporting clinical data used to make the prior authorization determination. The supporting data SHALL include unstructured data used in the prior §pdex-134 authorization determination.

The data available to be returned by the Bulk Payer-to-Payer Exchange API SHALL §pdex-135 include the following types of data:

The CMS Prior Authorization Rule (CMS-0057) requires Claims and Encounter data to be exchanged with Providers and Payers via the respective Provider Access API and Payer-to-Payer APIs, defined in this IG. The Rule requires that a non-financial view of those claims and encounters are provided. This IG utilizes the work of the CARIN Consumer Directed Payer Data Exchange IG which defines the following non-financial profiles:

Performing Bulk Data Exchange

The Payer-to-Payer bulk data exchange consists of two sequential asynchronous operations:

  1. $bulk-member-match: The requesting payer submits member demographics and consent for one or more members. This operation SHALL run asynchronously and upon completion returns Group resources categorizing members as matched, non-matched, or consent-constrained. §pdex-136 The Group Id for matched members is used in the next step.
  2. $davinci-data-export: Using the matched members Group Id, the requesting payer initiates a bulk data export. This also runs asynchronously and upon completion returns a manifest of NDJSON files containing the member health data.

Both operations follow the FHIR Asynchronous Request Pattern: each kick-off request returns an HTTP 202 Accepted response with a Content-Location header pointing to a status endpoint that clients SHALL poll to retrieve the completed result. §pdex-137

The R4 asynchronous request pattern was designed for bulk data export and delivers results as a JSON manifest pointing to NDJSON files. For an operation like $bulk-member-match that returns a bounded set of Group resources, this requires wrapping those resources in NDJSON files — an artificial fit. FHIR R5 introduced an async-bundle pattern that is a more natural match: upon completion the server returns a FHIR Bundle directly rather than a custom manifest. This IG targets FHIR R4 and adopts the R4 async pattern accordingly. When PDex moves to support FHIR R6, the async interaction pattern for $bulk-member-match will be reconsidered in light of the R6 async specification.

Payer-to-Payer Exchange is an "opt-in" choice for Members. The requesting (or New) health plan SHALL request permission (i.e., consent) from the Member §pdex-138 to retrieve the data from their prior plan. Payer-to-Payer (single Member) Exchange), SHALL exchange the same data. §pdex-139

The following data SHALL be exchanged with §pdex-140 the prior plan for each Member that provides their consent in order for the prior plan to attempt to match the Member:

The following information MAY be exchanged with the prior plan for a member: §pdex-141

  • (optional) Current, or future, coverage provided by the Requesting Plan

The bulk Exchange workflow is based upon the workflows identified in the Payer-to-Payer (Single Member) exchange. The variations to support bulk exchange are documented in this section of the IG.

The requesting Payer SHALL obtain an access token in accordance with the §pdex-142 SMART Backend Services Authorization process, as documented in the FHIR Bulk Data Access IG (2.0.0 STU2).

The bulk Payer-to-Payer exchange is initiated by supplying a Parameter bundle to the $bulk-member-match operation. A set of OAuth2.0/SMART-on-FHIR Client Credentials SHALL be required to access the secured bulk-member-match operation endpoint. §pdex-143

For each member submitted to the bulk-member-match operation the following parameters SHALL be supplied as a parameter.part element in the §pdex-144 multi-member-match-bundle-in parameter bundle.

  • MemberPatient: - HRex Patient demographics
  • CoverageToMatch - details of the prior health plan coverage, supplied by the member, typically from the health plan coverage card. Uses the HRex Coverage Profile
  • Consent - Record of consent received by requesting payer from Member to retrieve their records from the prior payer. This is an opt-in. Uses the HRex Consent Profile

Optionally the new health plan MAY include the following element in the parameter.part §pdex-145 element for a member:

  • CoverageToLink - Optional parameter. Details of new or prospective health plan coverage, provided by the health plan based upon the member’s enrolment. Uses the HRex Coverage Profile

An example request bundle can be found here: PDex $multi-member-match request

The PDex $multi-member-match operation SHALL be submitted using a HTTP POST. §pdex-146 The HTTP Header SHALL include: §pdex-147

Prefer: respond-async

The $multi-member-match operation SHALL be performed asynchronously, following the Asynchronous Request Pattern defined in FHIR R4. §pdex-148 Implementers SHALL follow the guidance provided in the Bulk Data Status Request section of the Async Request Pattern.pdex-139a: The subsequent $davinci-data-export operation SHALL also be submitted using a HTTP POST and SHALL be performed as an asynchronous Bulk Data export, per the FHIR Bulk Data Access IG. §pdex-149

The Bulk Member Match Operation will use the following Parameters:

The async completion manifest provides the URLs of the ndjson output files. The Group resource for matched members provides the Group identifier that can be used by the requesting/new payer in the subsequent $davinci-data-export step.

Cross-Referencing Match Results with Submitted Members

Each Group member entry in the $bulk-member-match response (matched, non-matched, and consent-constrained) includes a matchedMember or nonMatchedMember extension that references a contained Patient resource. This contained Patient resource SHALL be the exact Patient resource as submitted by the requester in the MemberBundle input parameter, including all identifiers, demographics, and the original resource id supplied by the requester. §pdex-150 Responders SHALL NOT abridge, modify, or substitute the submitted Patient resource. §pdex-151 The contained Patient SHALL retain the original id and all identifiers supplied by the requester so that the requester can unambiguously correlate each match result back to the member they submitted. §pdex-152

When the same patient is submitted across multiple MemberBundles with different Coverage plans (e.g., an employer plan and a secondary plan), the patient may appear in both MatchedMembers and NonMatchedMembers Groups. In this case the responder SHALL also include the submitted CoverageToMatch resource as a contained Coverage in the Group and populate the matchedCoverage (or nonMatchedCoverage) extension on member.entity to reference it. §pdex-153 This allows the requester to distinguish which (patient + coverage) pair each Group member entry corresponds to, and avoids user confusion when results are reviewed.

The Operation Definition for Bulk Member Match is:

PDex Bulk Member Match

The $bulk-member-match operation follows the FHIR Asynchronous Request Pattern. The kick-off HTTP POST returns HTTP 202 Accepted with a Content-Location header pointing to a status endpoint. When processing is complete, the status endpoint returns a manifest of ndjson file URLs — each ndjson file contains serialized Group resources (MatchedMembers, NonMatchedMembers, and/or ConsentConstrainedMembers) conforming to the PDex Multi-Member Match Response profile. The OperationDefinition does not declare inline out parameters for these Groups because the output is delivered via the async manifest, not in a synchronous HTTP response body — consistent with how $davinci-data-export handles its output.

The Bulk Member Match Operation SHALL evaluate the consent request for each member and determine whether the request for only Non-Sensitive data, as determined by federal and state regulations that apply to the data holder, can be complied with. §pdex-154 The following decision tree illustrates how the Consent determination SHALL be made. §pdex-155

Consent SHALL be evaluated at the time of the data request to ensure that the Member §pdex-156 has not contacted their previous payer to override sharing consent.

The consent decision logic is the same for Single Member Match and Bulk Member Match. It is the result of the decision that differs. For Single Member Match Operation, either the Patient information is returned, or an Operation Outcome is generated. In Bulk Member Match a member is assigned to a Matched, Non-Matched or Consent Constrained Group and processing continues until every member has been evaluated. The resulting Group resources are serialized to ndjson and delivered via the async completion manifest — they are not returned in a synchronous HTTP response body.

The consent decision flow for the bulk member match is shown in the following diagram:

Bulk Member-match Consent Decision Flowis bundle format validnoyesreturn 422 Unprocessable Entity inOperation Outcome - Bad bundle formatIs Member Matched?Yesnothingcheck consentWrite Member to NotMatched GroupCan Payer Comply with Consent Request?write Member to Matched Member Groupwrite member to Matched Member Groupwrite member to Consent Contraint Groupwrite MatchedMember Group to FHIR StoreReturn:1. Matched Member Group2. NotMatched Group3. Consent Constraint Groupcompile Member-Match responseReturn Groups in response bundleSensitive Data is excludedSensitive data is NOT taggedSensitive data is tagged

Searching for Matched Groups

A payer may send multiple requests for member matching to another Payer. This can result in multiple Matched Group records being created. The FHIR Group resource supports searching on characteristic. To enable searching the PDexMemberMatchGroup Profile sets the characteristic element to include the "match" code, the identifier of the requesting payer in (characteristic.valueReference), sets characteristic.exclude to false and characteristic.period.start to the date of the match request.

Implementers SHALL support the standard search parameters for group that are specified in the base §pdex-157 Group resource in FHIR R4 specification: Group Search Parameters.

Da Vinci Data Export Payload

The Payer-to-Payer data export operation is meant to retrieve the information requested by the member when they join a new payer. The payer rtrieves their information using Payer-to-Payer exchange. Under the requirements of the CMS Prior Authorization Rule (CMS-0057) the data available through the API SHOULD include: §pdex-158

DaVinci-Data-Export Operation

The davinci-data-export Operation and the optional parameters are defined in the Da Vinci Member Attribution (ATR) List Implementation Guide STU2.1.

Requesting/New Payer:

- SHALL be issued with OAuth2.0/SMART-On-FHIR client credentials that enable access to /Group/{id}. §pdex-159 Where {id} is the PDex Member Match Group(s) resulting from the Bulk Member Match Operation. - SHALL be permitted to SEARCH /Group. §pdex-160 The search function and the bundle contents returned SHALL be restricted to the {ids} that are associated with theRequesting/New Payer. §pdex-161 - MAY be associated with more than one PDex Member Match group list. §pdex-162 - SHALL be permitted to GET /Group/{id} for any PDex Member Match Group list they are associated with. §pdex-163 - SHALL be permitted to call $davinci-data-export operation for any /Group/{id} they are associated with. §pdex-164 - SHALL be permitted to retrieve data with a service date within 5 years of the date of the request for information. §pdex-165

While the davinci-data-export-operation enables granular resource requests the operation SHOULD be used with two scenarios: §pdex-166

  • Requesting all data within the previous 5 years for all members in the list.
  • Requesting all data for all members in the list since the last request.

The latter option is to enable two scenarios:

  • For "run-off" data to be collected for members that have switched plans
  • For members with concurrent coverage.

For members with concurrent coverage this will enable data to be requested at least quarterly.

The Data Export operation SHALL check the consent status for each member §pdex-167 at the time of execution. This is necessary to identify members that may have changed their opt-in/opt-out status for sharing with health plans.

Data that SHALL be available via the API includes: §pdex-168

Claims and clinical data SHALL be limited to records with a service date §pdex-169 within 5 years of the date of request for data. Prior Authorizations SHALL be limited to Active/Current Prior Authorizations and §pdex-170 Prior Authorizations that have changed status within the last year, as of the date of the information request.

ExportType

This is an optional parameter in the Da Vinci Data Export Operation. For Payer-to-Payer Bulk Exchange the exportType field SHALL have the following value: §pdex-171

  • hl7.fhir.us.davinci-pdex#payertopayer
_since

Resources in the Patient Access API can extend back to January 1, 2016. For Payer-to-Payer Exchange only data updated within five years of the transaction request date SHALL be returned via the API. §pdex-172 The _since parameter SHOULD be used for resource §pdex-173 requests when the full history is not required. It is expected that Payers MAY §pdex-174 first request data for members without limiting the request using the _since parameter. Subsequent requests MAY then use _since to limit data to information that is new. §pdex-175 This would enable the Payer to request "Run-off" data that the prior plan received after the initial enrollment by the member in the new plan.

If the _since parameter is earlier than five years before the transaction request the date/time SHALL be overridden and set to five years before the transaction §pdex-176 request date.

_until

The _until parameter MAY be used less frequently. §pdex-177 It is most likely to be used by the Payer to retrieve member data for a specific period. This may be the case where two Payers both share a Member that has concurrent coverage with multiple Payers. For example when requesting data for a particular quarterly period.

_type

The _type parameter MAY be used to restrict the resources retrieved by the §pdex-178 Payer. If this parameter is not used all available resources SHALL be returned §pdex-179 by the Payer, subject to the constraints applied by other input parameters.

_typeFilter

The _typeFilter parameter MAY be used to further restrict the resources §pdex-180 retrieved by the Payer. For example, to only retrieve Observations of a certain type. The _typeFilter, if used, SHALL comprise one, or more, valid FHIR §pdex-181 search queries for the respective resource being filtered.

NOTE: When constructing search queries to incorporate into a _typeFilter, Search parameters supported by the relevant profiles from the PDex, US Core or CARIN Blue Button IGs SHALL §pdex-182 be followed.

The overall workflow for Bulk Payer-to-Payer Exchange is shown in the diagram below:

Payer2 | New Payer | Requesting PayerPayer1 | Old Payer | Receiving PayerPayer2 | New Payer | Requesting PayerPayer2 | New Payer | Requesting PayerPayer1 | Old Payer | Receiving PayerPayer1 | Old Payer | Receiving PayerConnection InitializationStep 1: OAuth 2.0 Dynamic Registration or alternativeRequest registration (JWT with registration details)Payer2 submits JWK Set withservice registration detailsReturn Client Credentials (ClientID/ClientSecret)Secure Transaction Capability EstablishedBulk Member MatchStep 2a: Get $MemberMatch Operation TokenUse OAuth2.0 token endpoint to request accessto $MemberMatch operation onlyReturn access tokenToken endpoint issues access token usingPayer2 OAuth CredentialsStep 2b: Establish Common Members - secure operationSend bundle of bundles (Patient Demographics,Coverage & Consent for each member) to $MemberMatch async operationMatch EACH memberStore or Compute Consent(all / non-sensitive) for EACH MemberMember: IDPayer: ID (Client Credential)Policy: all | non-sensitiveConsent Period: start, endThis information will need to be checkedwhen Access Token is issued in Step 3.An active consent information will only be stored if the PolicyScope can be complied with. An inability to comply with the scopewill lead to a the member information being added to a "Consent Constraint" group.Successful Match results in Patient/{ID} for Memberbeing appended to a dynamically created Group record by Payer 1.Failed matches and Consent Constrained matches are compiled intotemporary group resource records that are included in the Parameter Response bundle.Upon completion of the match process the parameter response bundle is created.The response bundle is written to a storage location. The location is returned to the requestingparty in accordance with the FHIR Async protocol.Notify Payer that parameter Response bundle is available.Retrieves Parameter Response bundle.extract Matched Group Id to use in $davinci-data-export operation.This process assumes Payer1 provides Patient/{ID} foreach member that crosses all relevantcontract arrangements. Payer1 may determine concurrent coverage is in effectand covered by member consent to trigger reciprocalapp registration and $MemberMatch requests to Payer 2. Payer2 receives the Group/{ID} from Payer1.The Group/{ID} contains matched members where consentcan be complied with per date and policy constraints.Step 3: Request Access token forGroup/{ID}Use OAuth2.0 token endpoint torequest access using Group/{ID}/$davinci-data-exportReturn access tokenData RequestsStep 4: Exchange PDex (USCDI) Information via APIUse Access Token to call/Group/{ID}/$davinci-data-export operation.Performs Async operation as perFHIR Bulk Data Export specification to return bundle to requesting PayerOperation will validate Consent Scope and Valid Consent Period.This will be based upon data saved during Member-Match process foreach Member.Payer1 should check whether Member has provided more recent overridingconsent instruction directly.

Access and Refresh Tokens

Implementers SHOULD implement OAuth 2.0 access management in accordance with §pdex-183 the SMART Backend Services Authorization Profile. When SMART Backend Services Authorization is used, Bulk Data Status Request and Bulk Data Output File Requests with requiresAccessToken=true SHALL be protected the same way as §pdex-184 the Bulk Data Kick-off Request, including an access token with scopes that cover all resources being exported. A server MAY additionally restrict Bulk Data §pdex-185 Status Request and Bulk Data Output File Requests by limiting them to the client that originated the export. Health plans SHALL limit the data returned to §pdex-186 only those FHIR resources for which the client is authorized.

Clients SHALL require OAuth client credentials to enable secure access to read §pdex-187 and search the Group resources and perform Bulk export operations. Access Tokens SHALL be required to access the Group resources and the Bulk export operation. §pdex-188 Access and Refresh Tokens SHALL be issued to support the client requesting and §pdex-189 subsequently retrieving the bulk data response to their request.

Registering of a client application or service to perform the bulk Payer-to-Payer Exchange SHOULD be registered in accordance with the approach defined in the §pdex-190 SMART App Launch IG. That IG also encourages the use of the OAuth2.0 Dynamic Client Registration Protocol (DCRP). An alternative approach that is closely aligned with the DCRP protocol is to use the B2B protocols detailed in the HL7 Security for Scalable Registration, Authentication, and Authorization IG.

Scopes for Operations

SMART App Launch STU 2.1 defines granular scopes for resources. Following the model proposed in the section on FHIR Resource Scope Syntax the following scopes are proposed to control access to the Bulk-member-match
and Da Vinci Data Export Operations for Payer-to-Payer bulk exchange:

  • http://hl7.org/fhir/us/davinci-pdex/OperationDefinition/bulk-member-match
  • system.Group.u?code=http://hl7.org/fhir/us/davinci-pdex/ValueSet/PDexMultiMemberMatchResultVS match

This would be the scope to execute the bulk-member-match operation and the davinci-data-export operation for payertopayer exchange with the data export being restricted to the Group id(s) that the user is authorized to access.

Next Page - Data Mapping