Da Vinci Payer Data Exchange
2.0.0 - STU2 United States of America flag

This page is part of the Da Vinci Payer Data Exchange (v2.0.0: STU2) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions

Payer-to-Payer Exchange (single member)

Previous Page - Handling Data Provenance

The Exchange of all of a member’s clinical data, as scoped by USCDI version 1 and represented in FHIR by US Core 3.1.1, is a requirement of the CMS Interoperability Rule.

All PDex Payer-to-Payer FHIR-based data exchanges in this IG will be limited to the exchange of data for a single member. Data Exchange for groups of Members is outside the current scope of this IG. Management of attribution lists for exchange of data for groups of members may be considered in a future version of the IG.

Payer-to-Payer exchange can be accomplished by three methods. Clients wishing to retrieve data should consult the Data Provider’s Server Capability Statement to determine which methods are made available by the data holder. Each retrieval method SHALL be preceded by the use of the following interaction to match a member and provide consent:

Payer2 | New Payer | Requesting PayerPayer2 | New Payer | Requesting PayerPayer1 | Old Payer | Receiving PayerPayer1 | Old Payer | Receiving PayerPayer Directory | Certificate AuthorityPayer Directory | Certificate AuthorityConnection IntitializationStep 1a: Verify Exchange, establish mutual TLS, and verify trust.1QueryPayer2 searches registryfor Payer1 details2Return endpoint, mutual TLS public cert,3Verify Cert4Establish Mutual TLS5Query mutual TLS Public CertPayer1 queries registryfor Payer2 details6Return mTLS public cert7Verify CertStep 1b: OAuth 2.0 Dynamic Registration via mTLS connection8Request registration (JWT with registration details)Payer2 submits JWT withservice registration details9Return Client Credentials (ClientID/ClientSecret)Secure Transaction Capability EstablishedMember ConnectionStep 2a: Get $MemberMatch Operation Token10Use OAuth2.0 token endpoint to request accessto $MemberMatch operation only11Return access tokenToken endpoint issues access token usingPayer2 OAuth CredentialsStep 2b: Establish common member - secure transaction12Send bundle (Patient Demographics,Coverage & Consent) to $MemberMatch operation13Verify member14Store or Compute Consent(all / non-sensitive) for 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.15Return Member Identifier (Patient FHIR ID)This process assumes Payer1 provides a unique ID forthe member that crosses all relevantcontract arrangements. Payer1 may determine concurrent coverage is in effectand covered by member consent to trigger reciprocalapp registration and $MemberMatch request Payer2 receives the Member Identifier (Patient FHIR ID) from Payer1.The Member Identifier (Patient FHIR ID) is only returned if memberis matched AND consent can be complied withper date and policy constraints.Step 3: Request Access token for Member Access16Use OAuth2.0 token endpoint torequest access using Member IdentifierToken endpoint matches to member usingMember Identifier and queries consent records to findthe latest active consent that matches on Member and Payer Identifiers.The Access Token process then confirms current date is withinthe consent period and the policy scope can be complied with. Checking the consentrecord is active provides for the receiving payer to invalidate the consent recordif a request is recieved via other channels to cancel the consent.17Return access tokentoken is scoped to single PatientData RequestsStep 4: Exchange PDex (USCDI) Information via API18Use Patient-scoped access token to access API19Return $everything orincremental data as appropriate/supportedby Payer1 Capability StatementUse retrieval method, as defined in use case scenarios, such as:1.) Individual search against each USCDI resource2.) $everything operation3.) asynchronous Bulk FHIR methods.

Health Plans SHALL support the $member-match operation.

The steps in the Member Match with Consent process are:

  • Establish a secure connection via mTLS
  • Use mTLS secure connection to perform OAuth2.0 Dynamic Client Registration to acquire OAuth2.0 client credentials
  • Use Client Credentials to acquire OAuth2.0 token to perform $member-match operation
  • The $member-match operation uses Patient Demographics and Coverage records to determine if a member is found
  • The $member-match operation evaluates the Consent resource for a matched member
  • If a member is matched and the Consent request can be complied with (Per Policy request and Date range) a Patient ID is provided to the requesting Payer (Payer2)
  • If a Patient ID is returned from $member-match, a request is made to the OAuth2.0 Token endpoint for an OAuth2.0 Access Token that is scoped to the identified shared member
  • If a Token is granted the requesting payer performs data retrieval steps using appropriate methods, defined below.

mTLS Endpoint Discovery

Payers need two capabilities in order to establish trusted connections with other Payers:

  1. A Discovery or Directory Service to be able to find other endpoints
  2. A Trust Framework in which both parties are members.

In the absence of a Trusted Exchange Framework and Common Agreement (TEFCA) or National Endpoint Directory service for Payers an interim solution is required. For this purpose, a public git repository will be established that will be used to store signed mTLS endpoint bundles.

Each Payer will create an mTLS bundle. The bundle will be signed by a Certificate Authority (CA) using public/private keys. The Endpoint will also be “endorsed” by a Trust Framework Manager using a certificate. The Trust Framework endorsement process is detailed below in the Trust Framework section of this page.

The mTLS Endpoint Bundle is profiled in this IG. It consists of an Endpoint And two Organization profiles: One for the Health Plan and One for the Managing Organization that operates the endpoint. These profiles use the National Directory (NDH) IG Profiles.

For Payers to establish a secure mTLS connection with another Payer there needs to be a discovery service. In the absence of a Trusted Exchange Framework and Common Agreement (TEFCA) or National Endpoint Directory service for Payers an interim solution is required. For this purpose, a public git repository will be established that will be used to store signed mTLS endpoint bundles. A test version of that repository has been established here: https://github.com/HL7-DaVinci/pdex-payer-payer. The repository includes some supporting tools and documentation relating to mTLS discovery.

Each Payer will create an mTLS bundle. The bundle will be signed by a Certificate Authority (CA) using public/private keys. The public key is included in the Endpoint record that is provided in the bundle. A public key should also be provided by the Trust Framework that is overseeing the Payer-to-Payer exchange process. The Associated Servers Extension will identify the PDex IG Base URI and the OAuth2.0 Dynamic Client Registration Protocol Endpoint. The PDex Capability Statement can be retrieved from [BASE URI]/metadata. The security section within the Capability Statement will define the SMART-on-FHIR endpoints for Access Tokens. The Registration Endpoint will only be accessible via the mTLS connection established using the mTLS endpoint information in the bundle.

The mTLS Endpoint Bundle is profiled in this IG. It consists of an Endpoint and two Organization profiles (One for the Health Plan, the other for the Operating entity that manages the Endpoint). These profiles use the National Directory (NDH) IG Profiles.

The profiles are:

The profiles in the mTLS bundle are modeled after the profiles in the National Directory (NDH) IG. The National Directory is not yet operational. Therefore, it is outside the scope of this IG to define search methods into the National Directory. In the interim payers will need to download the Git repository and perform searches against the bundles to identify other payers and extract the relevant data.

Trust Framework

A Trust Framework is a construct where the parties to the framework agree to a common set of operating rules. A manager of the Trust Framework would be appointed to administer the framework: the Trust Manager. This would involve the issuing and revocation of certificates that validate an organization’s membership of the framework.

The Trust Manager responsibilities include:

  • Obtain and manage a Signing Certificate from a Trusted CA.
  • Manage submissions from Payers that includes their public identity certificate and completed Framework agreement. The Framework agreement confirms their participation in the Trust Framework and observation of the Trust Framework operating requirements.

The management of payer submissions involves the following steps:

  1. Verifying the identity certificate.
  2. Verifying the signature to the Framework agreement.
  3. Signing the payer’s public identity certificate with a digital signature.
  4. Returning the signed payer’s public identity certificate and the public Trust Framework signing certificate to the payer.

Upon completion of the submission process the Payer creates the endpoint and includes the signed payer public identity certificate and the public Trust Framework signing certificate into an Endpoint resource. This is incorporated into a bundle that includes the Payer’s organization record and the organization record for the organization that manages the endpoint. Where the organization is both the payer and the managing organization there should still be two Organization records created.

The completed bundle would be posted to a new branch of the public GitHub Repository.

The Trust Manager would be responsible for reviewing and merging bundles submitted via a new branch of the GitHub repository into the main branch of the Repository.

Trust Framework members are responsible for refreshing their copy of the main branch of the GitHub repository which would be used to refresh and update their list of mTLS and Authentication Endpoints for current validated members of the Trust Framework.

OAuth2.0 Dynamic Client Registration

Once payers have setup a secure mTLS connection, the new Payer will query the Dynamic Client Registration Protocol (DCRP) endpoint of the target (old) payer to obtain a client credential with scopes that enable queries to be made to the $member-match operation endpoint.

Future Direction for Discovery and Registration

Future versions of this IG are expected to transition from the current discovery and registration process. The current process, outlined on this page, utilizes a git repository of mTLS endpoint bundles that are used to create a secure mTLS connection. That connection is then used to access an OAuth2.0 Dynamic Client Registration (DCRP) endpoint to register for a set of client credentials. Those credentials provide access to the $member-match operation.

A future workflow is likely to use the FAST National Directory to find other payers that are in a common trust framework. The endpoint information for those payers would point to a Unified Data Access Profiles service, as defined in the FHIR At Scale Taskforce (FAST) Security for Scalable Registration, Authentication, and Authorization IG. UDAP would be used to request a client credential that can be used to perform a $member-match and subsequently to request an OAuth2.0 token that is scoped to the member/patient returned from a successful match operation.

The $member-match operation

The $member-match operation is defined in the HRex member-match operation. The profiles used in the $member-match Operation are also defined in the HRex IG. These are:

The Coverage Profile is used to provide data for the CoverageToMatch and the CoverageToLink parameters in the $member-match operation. The CoverageToMatch is the information about the prior coverage. The CoverageToLink is the current coverage for the member at the new/requesting payer.

In the case where a match is confirmed the receiving payer will:

  • Utilize the consent record to evaluate the request from the requesting payer (Payer2) for data about the matched member. For example, is the payer able to respond to a request for only non-sensitive data.
  • Return a Unique Patient Identifier (Patient FHIR ID) in the $member-match Operation Response.

When no match is found, or if multiple matches are found, a 422 Unprocessable entity status code will be returned.

If the receiving payer matches to a unique member but is unable to comply with the consent request, a Patient ID SHALL NOT be returned in the $member-match response and a 422 status code SHALL be returned with an Operation Outcome that indicates that the consent request could not be complied with.

The following guidance is provided for a situation where a member wishes to revoke consent for a previously granted Payer-to-Payer exchange.

As part of Payer-to-Payer Exchange Consent is gathered by the New Payer. Since the New Payer has the current relationship with the member it is proposed that the New Payer manages the Consent Revocation process. This would involve the New Payer cancelling any recurring request to the old payer for new information for the member.

This approach does not preclude the member contacting their old payer and issuing a consent directive to block the release of data to the new payer. However, this is anticipated to be a rare occurrence.

It is recommended that consistent language is used by Payers to present the information to a member when they are being asked to grant consent for a Payer-to-Payer exchange of their health information.

You [the Member] are:

  • Instructing [New Payer] to retrieve your health information from [Old Payer]
  • Instructing the Old Payer to release your health information to [New Payer]
  • Requesting all information is to be retrieved, or sensitive data (such as mental health data) should be excluded from the retrieved health information.
  • Granting consent for [New Payer] to request data from [Old Payer] for a period of up to 90 days after the activation of your health coverage with [New Payer]

Please note that:

  • The scope of data sensitivity is determined by Federal and State regulations that apply in the state in which [Old Payer] operates.
  • If [Old Payer] is unable to identify and exclude sensitive data and you have chosen to exclude sensitive data from the request then [Old Payer] will be unable to comply with your request.
  • In the case where you have active coverage with both [Old Payer] and [New Payer] the end date for the Consent instruction will be the anticipated end date of the health coverage with [New Payer].

The receiving payer MAY store the Consent record for the member. The following minimal content from the Consent record is used to validate a data request:

  • Member Identity is matched
  • Consent Policy (Everything or only Non-Sensitive data) matches the data release segmentation capabilities of the receiving payer
  • Date period for consent is valid
  • Payer requesting retrieval of data is matched.

If a Consent is provided by an Authorized Representative, the person’s demographic details should be included as a contained resource (such as Patient or RelatedPerson) within the consent record. The Authorized Representative should be identified as an actor with an appropriate SecurityRoleType, such as “DPOWATT”, “HPOWATT” or similar value.

The exchange of Consent is being carried out between two covered entities and the content and conditions for an exchange of consent will be governed by a mutually agreed Trust Framework. The Consent resource’s document reference link would be to a document maintained by the requesting payer. The content of the referenced document would NOT be used for any determination as part of the automated $member-match operation. The referenced document’s only purpose is to provide evidence of an appropriate signature of the consenting member/patient.

It is expected that the referenced document url/identifier could be used in an out-of-band audit to determine the validity of a consent request. This would be part of the Trust Framework agreed by the covered entities that are party to the framework rules.

Here are some scenarios that could inform the decision about an appropriate period of validity for a consent to exchange health information:

  • Medicare has an annual enrollment. This can result in beneficiaries signing up for a new health plan up to 3 months before their new health plan goes into effect.
  • When a member’s health plan is terminated it is not uncommon for claims and supporting information to be received by the health plan for a period after the plan terminates.
  • Some plan beneficiaries may have concurrent coverage. For example, a Medicare and a Medicaid plan may be in effect for a beneficiary for the duration of coverage period. In this scenario health plans may need to exchange information about the beneficiary throughout the period of dual plan coverage to coordinate treatment.

It is a member’s option to share their health information with their new health plan. When a member chooses to grant consent for a health plan to retrieve their health data from a prior health plan the proposed period of consent MAY be:

Scenario Consent Start Date Consent End Date
Early Enrollment Date of enrollment 90 days after Plan Start Date
Immediate Enrollment Date of enrollment 90 days after Plan Start Date
Concurrent Plan Coverage Date of enrollment Plan Period End Date (typically 12 months from plan start date)

Data Retrieval Methods

Once Health Plans have completed the Member Access stage of the Exchange the requesting Health Plan SHALL utilize the access token returned from the Member Access step to request/retrieve data using one of the following three methods:

  1. Query all clinical resource individually
  2. $patient-everything operation
  3. Bulk FHIR Asynchronous protocols.

Each of the above methods SHALL support the retrieval of the profiles and resources identified in the table below.

Profile Resource
US Core Allergy Intolerance AllergyIntolerance
US Core CarePlan CarePlan
US Core CareTeam CareTeam
US Core Condition Condition
PDex Device
US Core ImplantableDevice		 Device
US Core DiagnosticReport for Laboratory Results Reporting
US Core DiagnosticReport for Report and Note Exchange		 DiagnosticReport
US Core DocumentReference DocumentReference
US Core Encounter Encounter
US Core Goal Goal
US Core Immunization Immunization
US Core Location Location
US Core Medication Medication
PDex MedicationDispense MedicationDispense
US Core MedicationRequest MedicationRequest
US Core Laboratory Result Observation
US Core Pediatric BMI for Age Observation
US Core Pediatric Head Occipital-frontal Circumference Observation
US Core Pediatric Weight for Height Observation
US Core Pulse Oximetry
US Core Smoking Status Observation
VitalSigns		 Observation
US Core Organization Organization
US Core Patient Patient
US Core Practitioner Practitioner
US Core PractitionerRole PractitionerRole
US Core Procedure Procedure
HRex Coverage Coverage
PDex Prior Authorization Prior Authorization
PDex Provenance
US Core Provenance		 Provenance

Query all clinical resources individually

Health Plans SHALL support search of a member’s clinical data to each USCDI/US Core clinical resource, as identified in the table above. Using the search capability of each resource enables the _revInclude and _include parameters to be used to retrieve the associated Provenance and supporting records.

Constraining Data Based Upon Permissions of the Requestor

The FHIR Server SHALL constrain the data returned from the server to a requester based upon the access permissions of the requester.

For example, if a requester queries for ExplanationOfBenefit resources but they are only allowed to see Prior Authorization records, and not EOB Claims, the FHIR Server shall filter the data accordingly.

This Constraining condition may be required in implementations where multiple types of data are being served up by a single FHIR Server. The condition is particularly relevant when implementing Operations such as $everything or $export. See the sections below.

$everything operation

Health Plans SHOULD support the use of the $everything operation. The Patient/{id}/$everything operation is defined in the FHIR R4 specification here: https://www.hl7.org/fhir/operation-patient-everything.html.

As noted in the previous section, $everything SHOULD limit the data retrieved to that which the requester is permitted to access. This might require an implementer to filter records at a more granular level than the resource.

The following resource/profiles relevant to the PDex IG are retrievable using the $everything operation:

Example of _type parameter:

_type= AllergyIntolerance,CarePlan,CareTeam,Condition,Device,DiagnosticReport,DocumentReference,Encounter,
       Goal,Immunization,Medication,MedicationDispense,MedicationRequest,Observation,Patient,Procedure,Provenance

The server SHOULD filter the ExplanationOfBenefit resource to include only PDex Prior Authorization profiled records. e.g., ExplanationOfBenefit.use does not equal “claim”.

Bulk FHIR Asynchronous protocols

/Patient/$export

Payer-to-Payer Data Exchange SHOULD support the use of Bulk FHIR methods, as defined in the HL7 FHIR Bulk Data Access Implementation Guide. The request/retrieval of data SHOULD use the FHIR Bulk Data Patient Level Export and the Bulk Data Export Operation Request Flow.

The Patient Export Operation for Payer-to-Payer exchange should be constrained to the resources and profiles that the requester is permitted to access, such as the profiles identified in the table in the Data Retrieval Methods section of this page.

The _typeFilter parameter can be used to scope resources using search parameters to exclude resources that are not required, such as non-clinical resources.

Next Page - Data Mapping