The five-year history transfer is the data-heaviest part of Payer-to-Payer Data Exchange. The CMS-0057-F requirement assumes the prior payer can produce five years of clinical and claims data for a single member, package it as a clean FHIR Bundle, and deliver it within one business day of the formal request. Plans that have not invested in data integration ahead of time often discover they cannot meet this bar without significant effort. Here are best practices for the inter-payer transfer reference on this site.
1. Inventory Five Years of Data Before You Need It
The first practice is the simplest and most often skipped. Build an inventory of where five years of data actually lives for a randomly selected member. Claims data is usually in the claims platform but may have been archived. Clinical data may live in claims-attached documents, in HIE feeds, in care management systems, or in CDA documents that have not been parsed into FHIR.
Plans that do this inventory before the first transfer request discover the gaps in time to address them. Plans that wait discover gaps under deadline pressure.
2. Build the FHIR Conversion Layer as Part of CMS-9115-F Work
For payers running CMS-9115-F since 2021, the Patient Access API already required some claims-to-FHIR conversion. Plans that extended this conversion to cover the broader CARIN BB profiles, PDex profiles, and the Bulk Data export pattern have a head start on Payer-to-Payer.
Plans that built the CMS-9115-F Patient Access conversion narrowly (just enough for the API) typically need additional work to support the five-year history scope.
3. Exclude Denied PAs and Cost-Sharing Detail Explicitly
The IG specifically excludes denied PAs and cost-sharing detail from the transfer. Implementations that pull broadly and filter at the end risk leaking excluded data. Implementations that scope the query to include only the required data at retrieval time produce cleaner output and audit cleanly.
The exclusion logic is straightforward in the IG but requires deliberate implementation. Plans that treat it as a post-processing filter sometimes find edge cases where excluded data leaks.
4. Handle the One-Business-Day Window With Async Processing
The one-business-day window from request to data delivery is realistic when the export pattern is async. Implementations that try to deliver synchronously often miss the window when the history is large or the data layer is slow.
The standard pattern uses FHIR Bulk Data async export: the receiving payer requests the export, gets a job identifier, and polls or subscribes for completion. The data is delivered as NDJSON file URLs once the export completes. Most plans target completion in 4 to 12 hours, which leaves margin against the one-business-day window.
5. Sequence the Bundle by Resource Type for Consumer Efficiency
The five-year history is delivered as multiple FHIR Bundles, typically chunked by resource type or by date range. Consumer-side ingestion is much smoother when the Bundles arrive in an order that lets the receiving payer process foundational resources first (Patient, Coverage, Practitioner) before consuming the larger clinical resources (Observation, Condition, Procedure).
Implementations that sequence Bundles thoughtfully reduce consumer-side complications. Implementations that emit Bundles in arbitrary order force the consumer to handle deferred resolution and re-processing.
6. Test Against Realistic Member Profiles
A useful pre-production test is to run the full five-year history export for a synthetic member with realistic data volume (200,000 to 500,000 resources is typical for a member with chronic conditions and active care). The export time, output integrity, and consumer-side ingestion all surface issues at this scale that small test profiles miss.
How This Fits the Broader Payer-to-Payer Architecture
The five-year history transfer is the data-heaviest step in a flow that also includes Member Match, Consent, and concurrent coverage handling. The pieces have to work together cleanly; a fast history export paired with a slow Consent flow does not actually deliver the data on time.
For the concurrent coverage handling that often complicates the transfer, the Top 6 ways to handle concurrent coverage in Payer-to-Payer exchange covers the patterns. For the member-facing opt-in flow that triggers the transfer, the 5 educational material patterns for Payer-to-Payer member opt-in covers the consent side.