62.1.1Responding Payer OIDC Client Setup

62.1.1.1Overview

This section walks you through the setup needed for configuring your Smile CDR instance as a Responding (Source) Payer. This involves setting up the System to System Data Exchange module to securely receive and respond to data requests from other (requesting) payer systems. This includes defining how your system will handle incoming requests, match patient records, evaluate consent, and securely export the requested health information.

62.1.2OIDC Configuration

62.1.2.1Create OIDC Client Definition

As per the Smile CDR documentation for federated OAuth2/OIDC setup, create a client definition in your SMART Outbound Security module.

{
  "clientId": "source-payer-p2p-client",
  "clientName": "P2P Source Payer Client",
  "enabled": true,
  "secretRequired": true,
  "allowedGrantTypes": ["CLIENT_CREDENTIALS"],
  "clientSecrets" : [ {
    "pid" : 1,
    "secret" : "***",
    "description" : "s***",
    "expiration" : "2026-05-01T00:00:00.000-04:00",
    "activation" : "2025-01-06T00:00:00.000-05:00"
  } ],
  "scopes": [
    "cdr_all_user_authorities",
    "openid",
    "system/*.read",
    "user/Patient.read", 
    "user/Coverage.read",
    "user/ExplanationOfBenefit.read"
  ]
}

/**
 * P2P Source Payer Authentication Callback Script
 * Processes authentication for P2P data requests
 */
function onAuthenticateSuccess(theOutcome, theOutcomeFactory, theContext) {
    // Extract business identifier for authorization
    theOutcome.addUserData('business-id', 's2sBusId');
    
    // Additional P2P specific authorities can be added here
    theOutcome.addAuthority("ROLE_P2P_SOURCE");
    
    return theOutcome;
}

62.1.3Key Responsibilities as Responding Payer

1. Securely receiving requests from authorized requesting payers.
2. Accurately matching patient records using configurable matching logic.
3. Respecting patient consent and consent-based filtering.
4. Exporting requested health records in a compliant manner.

62.1.4Consent Management

62.1.4.1Consent Policy Types

Members who opt-in to payer-to-payer data exchange may choose two types of Consent policy:

1. Share all records: Consent.policy.uri = http://hl7.org/fhir/us/davinci-hrex/StructureDefinition-hrex-consent.html#regular
2. Share only non-sensitive records: Consent.policy.uri = http://hl7.org/fhir/us/davinci-hrex/StructureDefinition-hrex-consent.html#sensitive

62.1.4.2Consent Evaluation

When there is a successful match, the $bulk-member-match operation will:

1. Evaluate if the system can satisfy the Consent policy based on the policy values.
2. Store the Consent resource for reference, if the system can meet the Consent policy.

62.1.4.3Consent Resource Storage

If there is a single match and the Consent policy can be satisfied, the operation will persist the inbound Consent resource with modifications:

• The Consent.patient field will be normalized to point to resources created by the source payer system
• The Consent.performer fields will be normalized to point to resources created by the source payer system

62.1.5Authorization Methods

62.1.5.1For Single-Member Flows

Primary document linking requester to member's consent is the Consent resource sent as part of $member-match request. In a callback script after successful authentication, reference the Consent to:

• Ensure the member's Consent exists for the requester
• Ensure it is still valid (if an end date is defined)

62.1.5.2For Multi-Member Flows

Two design options:

Token-Based Design:

• Token includes claim declaring relevant business identifier(s)
• Callback script cross-references identifiers with "match" Groups

FHIR Resource-Based Design:

• Organization resource created for requesting payer at registration
• Contains reference to SMART Client Definition in extension
• Callback script cross-references client credentials with Organization resources