Requesting Payer OIDC Server Setup

 

Overview

This section walks you through the setup needed when Smile CDR is playing the role of the Requesting payer (Target), meaning it's the one reaching out to other payers to get member data. Getting this setup right means Smile can securely connect to other payers, find the right member records, and bring that data into your system.

OIDC Configuration

 

Add OIDC Server Definition

Following the Smile CDR documentation for setting up OIDC server definitions, create a server definition for each Source Payer you'll be connecting to.

Navigation Path

  • In the Web Admin Console, navigate to Users & Authorization → OpenID Connect Servers
  • Select the desired system_to_system_data_exchange Target module for P2P
  • Add Server

Server Definition Configuration

Configure the server definition with the following key fields:

FieldDescriptionExample/Value
Server NameIdentifier for the serverp2p-server
IssuerExact Issuer URL of Source Payer's OIDChttps://source-payer.com/
Client IDClient ID Smile will use to auth to the serverp2p-client-jwt
Authentication MethodHow Smile authenticates to the serverCLIENT_SECRET_BASIC or PRIVATE_KEY_JWT
Client SecretClient Secret presented to the server***
Client Auth Keystore IDUsed when using PRIVATE_KEY_JWTdefault-keystore
Well-Known Configuration URlOptional. OpenID Connect configuration URLhttps://source-payer/smartauth_p2p/.well-known/openid-configuration
Request ScopesScopes to requestopenid cdr_all_user_authorities
FHIR Base URLSource Payer's FHIR endpointhttps://source-payer.com/fhir
Token EndpointOptional. OAuth2 token endpointhttps://source-payer.com/oauth/token
Custom Token ParametersCustomized token parameters for this OIDC serverPatient
Response TypeExpected response formatcode id_token token
Organization IDIdentification code to specify an org or businessOrganizaton/org1

Example

{
  "nodeId" : "Master",
  "moduleId" : "system_to_system_data_exchange_target",
  "issuer" : "http://localhost:9300/smartauth_p2p",
  "name" : "p2p-server",
  "audience" : "",
  "authWellKnownConfigUrl" : "http://localhost:9300/smartauth_p2p/.well-known/openid-configuration",
  "clientAuthenticationKeystoreId" : "default-keystore",
  "clientAuthenticationMethod" : "PRIVATE_KEY_JWT",
  "customTokenParams" : "Patient",
  "federationRegistrationId" : "4754414d-b0d5-46c1-810a-bd52e3f0892c",
  "federationRequestScopes" : "openid cdr_all_user_authorities",
  "federationTokenUrl" : "http://localhost:9300/smartauth_p2p/oauth/token",
  "fhirEndpointUrl" : "http://localhost:8004/payer-source-fhir",
  "notes" : "",
  "organizationId" : "Organization/org1",
  "responseType" : "code id_token token",
  "tokenIntrospectionClientId" : "p2p-client-jwt",
  "tokenIntrospectionClientSecret" : "",
  "validationJwkFile" : "",
  "validationJwkText" : ""
}

The example above populates both federationTokenUrl (Token Endpoint) and authWellKnownConfigUrl (Well-Known Configuration URl), but only one of them is needed. Smile CDR resolves the token endpoint for outbound requests in this order:

  1. federationTokenUrl, when set, is used as the token endpoint directly, and no .well-known discovery request is made.
  2. Otherwise authWellKnownConfigUrl, when set, is fetched exactly as configured, including any query string, and its token_endpoint is used.
  3. If neither is set, {fhirEndpointUrl}/.well-known/smart-configuration is fetched and its token_endpoint is used. fhirEndpointUrl (FHIR Base URL) is always required.

Authentication Script

Create an authorization script as per Smile CDR's federated OAuth2/OIDC documentation:

/**
 * P2P Target Payer Authorization Script
 * Handles authorization for outbound P2P requests
 */
function onAuthenticateSuccess(theOutcome) {
    // Extract user information from the token
    // Set the user ID from the token
}

Executing P2P Exchanges

 

For more details on executing P2P exchanges, see P2P Execute Exchange.

Prerequisites for $invoke-export

Before invoking P2P operations, ensure:

  1. The source payer server has been registered.
  2. The member has opted-in and Consent has been captured.
  3. The member has a local Patient resource with a member identifier (to support data integration).