Payer-to-Payer (P2P) Bulk Import

The Payer-to-Payer (P2P) Bulk Import supports the import of data (into Orchestrate Server) for members who have opted in to transfer data from a prior/concurrent payer to their new payer. This is part of a FHIR Payer-to-Payer Exchange (bulk) implementation.

Setup

Contact Orchestrate support to set up P2P data exchange. The support team will configure:

• A FHIR connection to the other payer(s). Each connected payer will be identified by a unique ID, which must be provided when initiating a data transfer.
• A shared cloud folder (SFTP, Amazon S3, etc.) utilized in the data transfer. (See Workflow for details.)

Workflow

In the P2P bulk import workflow, there are two payers:

• Requesting/New Payer - The payer (using Orchestrate Server) requesting the data transfer.
• Old Payer - The payer providing the member’s data. Although referred to as the “old” provider, this may also be a concurrent provider.

The transfer process is initiated when the requesting payer places a CSV file in the shared cloud folder. The file contains details about the members who have requested that their data be transferred. Orchestrate Server will then communicate with the old payer to retrieve/import the data.

Compliance and Consent

When requesting a data transfer, CMS-0057-F requires that the requesting system provide an attestation that the member consented to the data exchange. By placing a CSV file in the shared cloud folder and triggering the P2P workflow, the requesting payer legally attests that every member listed in the file:

• Is currently enrolled with the requesting payer (prospective/potential members are prohibited), and
• Has affirmatively opted in to this data exchange.

Orchestrate Server will utilize the submission of this file as authorization to generate the required attestation on the payer’s behalf.

Consent Source

Additionally, the requesting payer must provide a “source of truth” to indicate where the member’s consent has been recorded. This “consent source” will be reported to the old payer via a Consent Profile.

The consent source can be provided in various forms, each with its own column in the CSV file:

• ConsentSourceIdentifier - An identifier from the requesting payer’s system that references the member’s consent.
• ConsentSourceURL - An absolute URL to a file containing the member’s consent, such as a signed document or an audio recording of verbal consent. The URL need not be accessible by the old payer; it is merely for reference. ConsentContentType field identifies the data type.
• ConsentContent - Base64-encoded data containing the member’s consent. This could be a PDF or text document, MP3 audio recording, etc. The ConsentContentType field identifies the data type.

The requesting system must populate at least one of these fields. More than one may be used to provide supplementary information in the Consent Profile. If ConsentSourceIdentifier is provided, it will always be included in the Consent Profile. If both ConsentSourceURL and ConsentContent are provided, ConsentSourceURL will be ignored.

File Format

The file to initiate the transfer must be a Comma-Separated Value (CSV) file (as defined in RFC 4180):

• The CSV file must contain a header line with the following column names.
• Since the columns have headers, they can be in any order.
• Each line in the file describes a member who has opted in for data exchange.

CSV Columns

Required Fields

All fields are required, with the following exceptions:

Handling Concurrent Coverage

Each trigger file is treated as an individual request for a one-time data exchange. It does not set up a persistent data feed. For members with concurrent/overlapping coverage, the requesting payer’s business operations team is responsible for managing the schedule and submitting a new trigger file for concurrent members. The data exchange should be triggered at least quarterly (every 90 days) to comply with CMS regulations, or more frequently if mutually agreed upon with the concurrent payer.

Examples

MemberIdentifier,OldSubscriberId,OldPayerCode,ConsentPolicy,ConsentPeriodStart,ConsentPeriodEnd,ConsentSourceUrl,ConsentContent,ConsentContentType
123456780,hc-demoski,Demo,sensitive,2026-01-01,2028-01-01,,SSBoZXJlYnkgY29uc2VudCB0byBhbnl0aGluZyBhbmQgZXZlcnl0aGluZw==,text/plain

MemberIdentifier,OldSubscriberId,OldPayerCode,ConsentPolicy,ConsentPeriodStart,ConsentPeriodEnd,ConsentSourceIdentifier
123456780,hc-demoski,Demo,sensitive,2026-01-01,2028-01-01,content-101