On this page:
   59.1    Actors, Roles & Data Scope
  • Explanation
  • 59.0 Overview
  • 59.1 Actors, Roles & Data Scope
  • 59.2 Solution Modules & Standards
  • 59.3 Matching Logic
  • 59.4 Data Exchange Patterns
  • 59.5 Security & Privacy Framework
  • 59.6 Glossary of Terms
    • 59.3    Matching Logic   
    Table of Contents

    Solution Modules & Standards

    59.2.1Solution Modules & Standards

     

    The Payer-to-Payer (P2P) solution comprises core Smile CDR features as well as modules and operations designed specifically to support requesting and sharing data in a P2P exchange.

    59.2.1.1System-to-System Data Exchange Module

    The System-to-System Data Exchange (S2S) module supports key operations for requesting and sharing P2P exchange data.

    59.2.1.1.1Key Features

    FeatureDescription
    $sdh.s2s.invoke-exportOrchestrates a data request with another payer (single-member exchange only)
    $member-matchSingle-member matching operation
    $bulk-member-matchMulti-member matching operation
    Data ImportAutomated storage and transformation of retrieved data
    Provenance TrackingCreates audit trail for imported data

    59.2.1.1.2FHIR Bulk Data Format

    All data is exported using the FHIR Bulk Data specification:

    • Format: NDJSON (Newline Delimited JSON)
    • Scope: All resources in the Patient compartment

    59.2.1.1.3Example Export Response

    {
  "transactionTime": "2024-11-13T10:30:00Z",
  "request": "https://example.com/Patient/123/$export",
  "requiresAccessToken": true,
  "output": [
    {
      "type": "Patient",
      "url": "https://example.com/bulkdata/patient-123.ndjson"
    },
    {
      "type": "Condition",
      "url": "https://example.com/bulkdata/condition-123.ndjson"
    }
  ]
}

    59.2.1.2Registration Artifacts

    Payer systems create artifacts in Smile CDR to support P2P exchange:

    59.2.1.2.1OIDC Client and Server Definitions

    ArtifactPurposeCreated By
    OIDC Server DefinitionStore authentication credentials for connecting to Responding PayerRequesting Payer
    OIDC Client DefinitionStore authentication credentials for accepting requests from Requesting PayerResponding Payer

    For details on OIDC registrations, see:

    59.2.1.3Patient Identifier Configuration

    When configuring the System-to-System Data Exchange Module:

    Configuration ItemDescriptionExample
    Reference System used by Target PatientDefines the Patient.identifier.system that Smile CDR uses to identify patients within the local systemhttp://yourhealthplan.example.com/patient-id
    Responder Identifier SystemSystem for the Identifier used to store the original IDs of imported resources from the Responding Payerhttp://sourcehealthplan.example.com/member-id

    59.2.1.4EID Auto-Expand

    Smile's primary strategy for sharing data across all Patient compartments involves a configuration called EID auto expand.

    When a system is configured to recognize Payer-to-Payer requests:

    • It triggers an internal search for all Patient compartments containing the enterprise identifier for the requested Patient.
    • All compartments are shared in the response

    This enables payers to satisfy the requirement to share both pre-existing and previously imported data.

       59.1    Actors, Roles & Data Scope
  • Explanation
  • 59.0 Overview
  • 59.1 Actors, Roles & Data Scope
  • 59.2 Solution Modules & Standards
  • 59.3 Matching Logic
  • 59.4 Data Exchange Patterns
  • 59.5 Security & Privacy Framework
  • 59.6 Glossary of Terms
    • 59.3    Matching Logic