Configure Requesting Payer

Prerequisite: License key for System-to-System Data Exchange is installed.

This section describes the setup required when Smile CDR acts as the Requesting Payer (Target).

Add the System to System Data Exchange Module

This module provides the FHIR operations ($sdh.s2s.invoke-export, $member-match) and underlying logic required for the Payer-to-Payer data exchange workflow. It acts as the orchestrator for all outbound data requests.

1. In the Web Admin Console, navigate to Overview.
   • E.g., https://<host>/web-admin/signin
2. Select and add System to System Data Exchange from dropdown list.
   • Enter a Module ID (e.g., s2s_requesting)
3. Configure Patient Identifier defining how Smile will recognize and link patients in the local system (Target Payer) and identify imported resources from external systems (Source Payer).
   • Set the Reference System used by Target Patient property.
     • This value defines the FHIR Patient identifier that Smile will use to identify patients within your own local system.
     • E.g., urn:uri:payer-org-target:eid
   • Set the Responder Identifier System property.
     • This is the system for the Identifier that will be used to store the original IDs of the imported resources from the Responder (Source) server.
     • E.g., urn:uri:imported-id-2
4. Add FHIR Storage Module Dependency
   • Add a FHIR Storage module dependency associated with the System to System Data Exchange module.
5. Save and Start the module.

Configure the FHIR Endpoint Module for Security

1. In the Web Admin Console, navigate to your FHIR Endpoint to expose your FHIR API.
2. Enable OpenID Connect Security
3. Add the SMART_OUT_SECURITY module as the OpenID Connect Authentication dependency.
4. Save and Restart the module.

Note: Enable Auto-Create Placeholder Reference Targets to allow automatic creation of placeholder resources during data exchange. This feature comes with unintended consequences if persisting resources without validating that all references exist prior to storage. Use with caution!

Note: If the target Storage module uses the PATIENT_ID Partition Selection Mode, its Server ID Strategy must be UUID. In this mode a Patient's partition is derived from its resource ID, and ingested Patients are created without a client-assigned ID, so the server must be able to assign one before the write. See Patient ID Partitioning.

Configure OIDC Server as part of a registration workflow

• Registration and Authentication for Overview details.
• Register Requesting Payer the configuration steps.
• For general information on OIDC Server see Setting up OIDC Server definition