59.1.1Actors and Roles

59.1.1.1Exchange Actors

There are two parties for each exchange:

All exchanges are initiated by the Requesting Payer.

59.1.2Exchange Modes

The PDex Implementation Guide supports two modes for data exchange:

59.1.2.1Single-Member Exchange

Requesting data for a single member via the following request methods:

59.1.2.2Multi-Member Exchange

Group-based exchange, also referred to as "bulk" exchange:

59.1.3Phases of the Exchange

Here is a short overview of the key activities part of any transaction and where Smile fits in. Implementation details for each are explored in other sections of this guide.

59.1.3.1Where Smile CDR Fits

59.1.3.2Out-of-Band Activities

These activities occur largely outside of Smile:

• Registration vetting processes - Developer portals, legal review
• Member opt-in process - Member portals, education materials
• Consent capture - User interface for collecting member authorization

59.1.4Key Activities Overview

59.1.4.1Registration

Prior to any exchange, two payer actors register their P2P applications with the primary objective of establishing secure authentication credentials. Payers may choose to create vetting processes through developer portals for processing applications.

While this process occurs largely outside of Smile CDR, registration artifacts may need to be created in Smile CDR software, such as OIDC client/server definitions and FHIR Organization resources.

59.1.4.2Opt-in

Members trigger the exchange by giving consent to the Requesting Payer to retrieve their health records. This opt-in process, including delivering education materials, occurs outside of Smile CDR. Information gathered from the member about the other payer feeds into the next phase of the transaction.

59.1.4.3Requesting Data

Requesting Payers initiate exchanges via the $sdh.s2s.invoke-export operation, which automates the request and retrieval of data from the Responding Payer.

Note: This operation is currently supported only for single-member exchange.

59.1.4.4Authentication and Authorization

• Requesting Payer side: The $sdh.s2s.invoke-export operation inserts the necessary security credentials to request access to server-side resources.
• Responding Payer side: Smile CDR is configured to ensure requesters have access to appropriate resources defined by both CMS and business policies.

59.1.4.5Patient Matching

• Requesting Payer side: The $sdh.s2s.invoke-export operation submits patient and coverage information to facilitate record location in the source server.
• Responding Payer side: Configure $member-match (for single member) and $bulk-member-match (for multi member) operations to return matching patient record locations.

59.1.5Storing Imported Records

59.1.5.1Data Export

Successful member match allows the requester to initiate a data export using the returned patient IDs. The $sdh.s2s.invoke-export operation makes a request on the bulk $export endpoint.

The Responding Payer configures Smile CDR to define the scope of resources to share, using the CMS mandate as its primary guide.

59.1.5.2Data Storage

Once retrieved, records are stored in the repository through several stages:

1. Original records are stored unaltered and embedded in DocumentReference resources for auditing purposes.
2. Provenance records are created to link imported resources to the data transmitter.
3. Imported FHIR records undergo minimal transformation and are stored in a separate Patient compartment from pre-existing data in the CDR. Both compartments are linked via a patient business identifier (enterprise member ID).

This separation into distinct Patient compartments supports querying for only pre-existing data or collating pre-existing and imported records when other payers request member data.

59.1.5.3Resource Tagging

A tag of "migrated" is added to imported resources to clearly identify them as originating from an external payer system.

{
  "meta": {
    "tag": [
      {
        "system": "http://smilecdr.com/fhir/tags",
        "code": "migrated",
        "display": "Resource imported from external payer"
      }
    ]
  }
}