Da Vinci Payer Data Exchange
2.1.0 - STU2 Ballot 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.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

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

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

The data available to be returned by the Bulk Payer-to-Payer Exchange API SHALL 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

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 to retrieve the data from their prior plan. Payer-to-Payer (single Member) Exchange), SHALL exchange the same data.

The following data SHALL be exchanged with 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:

  • (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 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.

For each member submitted to the $bulk-member-match operation the following parameters SHALL be supplied as a parameter.part element in the $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 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 and the subsequent $davinci-data-export operations SHALL be submitted using a HTTP POST. The HTTP Header SHALL include:

Prefer: respond-async

The Bulk Member Match Operation will use the following Parameters:

The Response Profile provides a Group identifier that can be used by the requesting/new payer to retrieve data.

The Operation Definition for Bulk Member Match is:

PDex Bulk Member Match

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. The following decision tree illustrates how the Consent determination SHALL be made.

Consent SHALL be evaluated at the time of the data request to ensure that the Member 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 and the resulting Groups are returned in the Operation response.

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 Group resource in FHIR R4 specification: Group Search Parameters.

Da Vinci Data Export Payload

The Provider Access is meant to enable in-network providers to retrieve the information they want about one or more patients that are attributed to them via an existing, or impending treatment relationship. Under the requirements of the CMS Prior Authorization Rule (CMS-0057) the data available through the API SHOULD include:

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.

Requesting/New Payer:

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

While the $Davinci-data-export-operation enables granular resource requests the operation SHOULD be used with two scenarios:

  • 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 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:

Claims and clinical data SHALL be limited to records with a service date within 5 years of the date of request for data. Prior Authorizations SHALL be limited to Active/Current Prior Authorizations and 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:

  • 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. The _since parameter SHOULD be used for resource requests when the full history is not required. It is expected that Payers MAY 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. 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 request date.

_until

The _until parameter MAY be used less frequently. 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 Payer. If this parameter is not used all available resources SHALL be returned by the Payer, subject to the constraints applied by other input parameters.

_typeFilter

The _typeFilter parameter MAY be used to further restrict the resources 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 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 be followed.

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

Payer2 | New Payer | Requesting PayerPayer2 | New Payer | Requesting PayerPayer1 | Old Payer | Receiving PayerPayer1 | Old Payer | Receiving PayerConnection IntitializationStep 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 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 be 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 422 error being returned from the $member-match for themember.Successful Match results in Patient/{ID} for Memberbeing appended to a dynamically created Group record by Payer 1.Return Group Identifier (Group FHIR ID).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 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 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 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 only those FHIR resources for which the client is authorized.

Clients SHALL require OAuth client credentials to enable secure access to read 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. Access and Refresh Tokens SHALL be issued to support the client requesting and 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 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 STU2.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