Da Vinci Payer Data Exchange
2.0.0-ballot - ballot US

This page is part of the Da Vinci Payer Data Exchange (v2.0.0-ballot: STU2 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

Payer-to-Payer Exchange

Previous Page - Handling Data Provenance

TODO: update link to replace build.fhir.org when HRex publishes.

The Exchange of all of a member’s clinical data, as scoped by USCDI version 1 and represented in FHIR by US Core, 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: IDPolicy: all | non-sensitiveConsent Period: start, endThis information will be need to be checkedwhen Access Token is issued in Step 315Return MemberMatch IDThis 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 requestPayer2 receives the MemberMatch ID from Payer1.The MemberMatch 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 MemberMatch IDToken endpoint matches to member usingMemberMatch ID and confirms thatconsent is still valid17Return access tokentoken is scoped to single PatientData RequestsStep 4: Exchange PDex (USCDI) Information via API18Use Patient-scoped access token to access API19Return $everything-pdex 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-pdex operation3.) asynchronous Bulk FHIR methods.

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 $MemberMatch operation
  • The MemberMatch operation uses Patient Demographics and Coverage records to determine if a member is found
  • The $MemberMatch 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 MemberMatch ID is provided to the requesting Payer (Payer2)
  • If a MemberMatch Id is returned from $MemberMatch, a request is made to 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.

The $MemberMatch operation is defined in the Hrex MemberMatch 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 MemberMatch 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 MemberMatch Identifier in the $MemberMatch Operation Response.

If the receiving payer is unable to comply with the consent request a MemberMatch ID is NOT returned in the $MemberMatch response.

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.

Alternate Data Retrieval Flow

Payer2 | New Payer | Requesting PayerPayer2 | New Payer | Requesting PayerPayer1 | Old Payer | Receiving PayerPayer1 | Old Payer | Receiving PayerPayer Directory | Certificate AuthorityPayer Directory | Certificate AuthorityData RequestsStep 3: Request NON-SCOPED Access token16Use OAuth2.0 token endpoint torequest accessClient Credentials used to obtain token.Token is NOT scoped to Patient/Member.17Return access tokenStep 4: Exchange PDex (USCDI) Information via API18Use NON-SCOPED access token to access API19Return $everything-pdex orincremental data as appropriate/supportedby Payer1 Capability StatementWhen a NON-SCOPED access token is provided each query toa resource endpoint will need to perform a consent queryto confirm that access is permitted.This controlcouldbe performed by implementing a custom function.The function would perform the consent validation and then retrievethe relevant data and return to Payer2.

NOTE: Ballot Feedback sought regarding where and hoe the scoping and consent verification steps are performed after a successful MemberMatch.

The choices to perform the scoping and consent verification are:

  1. As part of the OAuth transaction that receives the MemberMatch ID
  2. During the data retrieval for each resource or operation endpoint that is accessed.

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/{id}/$everything-pdex 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
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.

Patient/{id}/$everything-pdex operation

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

However, $everything-pdex limits the data that can be retrieved to the resources and profiles detailed in the table above.

It must be noted that the Patient/{id}/$everything-pdex operation does not support the full range of query parameters available to a regular search request. In cases where Provenance is being requested as part of the $everything-pdex operation this is accomplished by specifying Provenance as one of a list of resources included in the _type parameter of the $everything-pdex operation.

The following resource/profiles are retrievable using the $everything-pdex operation:

Example of _type parameter:

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

The $everything-pdex operation should also return resources that are referenced by clinical resources, but are not directly linked to a patient. These are: Location, Organization, Practitioner and PractitionerRole.

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/{id}/$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 identified in the table at the top of this section.

Next Page - Data Mapping