The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) set out specific requirements for payer interoperability: Patient Access APIs, Provider Access APIs, Payer-to-Payer APIs, and Prior Authorization APIs, each with specific data content requirements, performance standards, and implementation deadlines. The rule finalized what had been proposed for years. Compliance is mandatory for applicable payers.
The industry is dividing into two approaches. The first — compliance minimum — treats the rule as a regulatory project: build the APIs to the specification, pass the compliance audits, and keep the infrastructure at the minimum viable level. The second — strategic platform — recognizes that the same APIs that satisfy compliance can serve as the backbone for operational capabilities the plan would otherwise be building separately. The strategic platform approach costs more initially but produces substantial additional value.
Which approach a plan takes isn't just a technology decision. It reflects whether the organization sees interoperability as regulatory overhead or as operational infrastructure. That framing tends to be persistent; plans that start with compliance-minimum rarely upgrade later.
What the rule actually requires
The rule's core requirements, in summary:
| API | Required data | Who accesses |
|---|---|---|
| Patient Access API | Claims, encounter, clinical, formulary, remittance, prior auth data | Members, via third-party apps they authorize |
| Provider Access API | Similar data scope as patient access, for attributed members | Providers, for members they treat |
| Payer-to-Payer API | Clinical, claims, prior auth data for transitioning members | Other payers, with member consent |
| Prior Authorization API | Requirements, decisions, documentation | Providers initiating or checking authorization |
| Provider Directory API | Network provider information | Public, no authentication required |
The data content standards reference HL7 FHIR, with specific implementation guides (Da Vinci, CARIN) providing detail. Performance standards include specific response time requirements and availability expectations. Applicability varies by plan type with specific dates for different categories.
The compliance-minimum approach
The compliance-minimum approach treats the rule as a regulatory project with a defined scope and budget. The characteristics:
- Scope limited to required APIs. Build only what's required, not what might be useful.
- Data mapping to minimum required elements. Map source data to FHIR minimum requirements, not comprehensive representation.
- Performance targeting minimum standards. Meet response time and availability requirements, not exceed them.
- Separate from operational systems. The APIs run as a separate compliance stack, not integrated with operational systems.
- Minimal governance. Data quality, ongoing monitoring, and continuous improvement at the compliance minimum.
- Vendor-dependent. Often delivered primarily through vendor solutions configured for compliance scope.
- Cost-optimized. Total investment sized to the compliance requirement, not the operational opportunity.
This approach produces compliance but limited additional value. When other parts of the plan later need clinical data integration, member data access, or provider data services, they build separate infrastructure.
The strategic platform approach
The strategic platform approach recognizes that the APIs required by the rule are also the APIs the plan needs for operational use cases. Rather than building for compliance and again for operations, build once as infrastructure.
- FHIR as internal data exchange standard. Internal systems that exchange clinical and administrative data use FHIR as the format, which means the compliance APIs are natural extensions of internal infrastructure.
- Comprehensive data modeling. Beyond minimum required elements, complete representation of claims, clinical, and operational data in FHIR-compliant form.
- Performance well above standards. Response time and availability significantly above minimum, enabling operational use cases that compliance use cases don't require.
- Integration with operational systems. Care management, member services, quality operations, and provider relations all consume the same API infrastructure.
- Active governance. Data quality, completeness, and freshness managed as operational priorities, not compliance checkboxes.
- Strategic vendor relationships. Technology choices made for platform value, not just compliance delivery.
- Investment reflects strategic value. Total investment sized to operational opportunity, typically 2-3x compliance minimum but producing multiples of that in operational value.
Where the strategic approach captures value
Clinical data integration for quality measurement — the same FHIR infrastructure that serves patient access API supports internal HEDIS and Stars operations
Care management clinical context — care managers see complete member clinical information without separate integration work
Provider data services — the provider access API infrastructure supports provider portals and provider-facing analytics
Risk adjustment documentation — clinical data flows support risk adjustment coding and documentation
Member engagement — personalized digital experiences rely on comprehensive member data
Payer-to-payer transitions — the API infrastructure supports both sides of member movement
External partnerships — health data partnerships (research, care coordination, analytics) use the same infrastructure
Each of these is an operational need that exists regardless of the interoperability rule. Building separate infrastructure for each produces significant cost and integration complexity.
The FHIR capability question
FHIR capability is not binary. It spans from basic ability to produce FHIR responses to sophisticated use of FHIR as an internal data model. The maturity levels matter:
- Level 1: FHIR at the edge. FHIR responses generated by translation layers over existing systems. Works for compliance; limited utility beyond.
- Level 2: FHIR data store. Dedicated FHIR repositories that store clinical and administrative data in FHIR format, supporting both external APIs and internal consumers.
- Level 3: FHIR-native systems. Operational systems that use FHIR as their native data model, eliminating translation entirely for certain use cases.
- Level 4: FHIR ecosystem. FHIR as the dominant data exchange standard across the organization and with external partners, with sophisticated governance, quality, and operations.
- Level 5: FHIR-enabled differentiation. FHIR capability as a source of competitive differentiation — faster integration, better partner experiences, novel member services enabled by data access.
Most plans are operating at Levels 1-2. The plans that reach Levels 3-4 are finding that the capability affects how they can operate, not just what compliance requires.
The data quality dimension
FHIR APIs expose data. If the data has quality issues — missing elements, inconsistent coding, outdated information — the APIs expose the quality issues too. The compliance minimum approach often doesn't surface these issues until third-party apps, members, or providers start consuming the APIs and complaining about what they find.
The quality issues most commonly surfaced by interoperability:
- Incomplete claims data. Procedure codes, diagnosis codes, and provider identifiers with gaps or inconsistencies that didn't matter internally but do matter in external APIs.
- Provider directory accuracy. Provider directories exposed via API get scrutinized at a level internal directories don't, and accuracy issues become visible.
- Clinical data sparsity. For plans with limited clinical data integration, the clinical data returned by patient access APIs feels thin to members and apps that have seen richer data elsewhere.
- Authorization data incompleteness. Prior authorization history may not have been maintained in queryable form internally, requiring substantial work to expose.
- Historical data gaps. Data from periods before current systems may not be readily accessible in FHIR form.
The payer-to-payer dimension specifically
The payer-to-payer API is perhaps the most operationally significant piece. When a member moves between plans, the new plan receives the member's clinical and claims history from the prior plan. This solves one of the longstanding problems of fragmented coverage — the new plan starts with visibility into the member's care patterns.
For the receiving plan, this data enables:
- Better onboarding (as discussed in the onboarding article) — proactive identification of coverage issues, medication continuations, network considerations
- More accurate risk adjustment from day one
- Better care management targeting
- Informed network design decisions based on member utilization patterns
For the sending plan, the obligations are providing the data accurately and in timely fashion. Plans with strong data infrastructure do this well; plans without struggle.
The implementation timeline reality
The rule has specific implementation deadlines that vary by plan type and API. Plans that started implementation planning early, with appropriate investment level, generally meet deadlines without crisis. Plans that delayed or under-invested face crunches that can damage both compliance outcomes and operational integration.
The realistic timeline for strategic platform implementation: 18-24 months from start to production capability, with ongoing refinement for 12+ months beyond that. The compliance-minimum timeline can be compressed to 12-18 months but produces infrastructure that has to be revisited for operational use cases.
The competitive dimension
Interoperability capability is becoming a competitive dimension in several ways:
- Provider relationships. Providers prefer plans with usable APIs and data services. In competitive provider markets, API quality matters.
- Member experience. Digital experiences that rely on data access are better in plans with strong FHIR infrastructure.
- Partnership attractiveness. Health tech partners, digital health vendors, and other collaborators work more easily with plans that have mature API infrastructure.
- Regulatory trajectory. Interoperability requirements are expanding, not contracting. Plans with strong foundation are better positioned for future requirements.
- Operational agility. The plans with FHIR-based internal infrastructure can build new capabilities faster than plans that treat data access as a per-project integration.
CMS-0057 and the broader interoperability regulatory direction represent one of the most significant infrastructure shifts in health plan history. The minimum compliance approach satisfies the rule at lowest cost but produces infrastructure that doesn't contribute to operational capability. The strategic platform approach costs more but produces foundation that supports operations, partnerships, and competitive differentiation for years. The window for making this choice well is now, before the infrastructure is built and the pattern is set. For leadership teams assessing where interoperability, data infrastructure, and FHIR capabilities fit within the broader health plan operating model, the Health Insurance Capability Model maps the capabilities — API infrastructure, FHIR operations, data governance, partner integration — that determine whether interoperability becomes a regulatory overhead or an operational asset.