CMS-0057-F: Why APIs are the easy part

Guest blog written by Nate Hecker, CISO at HIKE HEALTH 

Most payers are approaching CMS-0057-F with a familiar question: “Which FHIR platform should we buy, and how fast can we turn on the APIs?” That thinking will get you to technical compliance, but it will not give you a sustainable program or unlock the business value this rule can enable. 

From an enterprise architect’s perspective, CMS-0057-F is less about APIs and more about operational transformation: identity, consent, data quality, governance, and the new business capabilities that sit on top. 

In this post, I’ll walk through the difference between being “FHIR-ready” and truly “operationally ready,” highlight the pitfalls we’ve seen in real implementations, and explain why getting the architecture right up front is non‑negotiable.

Compliance vs. sustainability: FHIR-ready is not enough 

In many executive suites, CMS-0057-F and CMS-9115 are still framed as an API mandate: stand up Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs using FHIR and Da Vinci guides, pass certification, and you’re done. On paper, that looks like a straightforward IT project: 

• Deploy a FHIR server
• Configure OAuth and SMART-on-FHIR
• Wire endpoints to existing data sources
• Implement CRD, DTR, and PAS workflows for prior authorization

If you do that, you become FHIR-ready. But a sustainable CMS-0057-F program demands something more: operational readiness.

That means: 

• Identity confidence established for members and providers across systems
• Consent rules encoded as system logic, not just policy documents
• Terminology and knowledge artifacts governed and versioned over time
• Data ingestion and normalization pipelines in place
• Compliance reporting is automated and reliable
• Clear operational ownership and governance

You can be FHIR-ready and still fail in production: providers get inconsistent data, members see outdated information, prior authorization decisions don’t align with policies, and compliance reports can’t be generated without heroic manual work. The lesson is blunt: APIs are necessary, but they are not sufficient. 

The hidden work vendors don’t talk about 

Most vendor conversations focus on infrastructure: FHIR servers, API gateways, and conformance to CMS-0057-F and Da Vinci implementation guides. That matters, but it’s not where programs stall. The real effort sits in the operational layer.

Identity resolution: The foundation of trust 

Provider Access and Payer-to-Payer exchange live or die on identity accuracy. If you can’t reliably match members and providers across enrollment, claims, care management, and external sources, no amount of FHIR conformance will save you. 

Typical challenges we see during implementations include:   

• Conflicting member demographics and IDs across systems
• Provider hierarchies that don’t align (NPIs, groups, facilities)
• Attribution logic that is unclear or inconsistent

The APIs may return data, but if you can’t trust that it’s the right data for the right member and provider, you’ve created a liability, not an asset. Identity resolution is not a “nice to have”. It is a first-class architectural concern and a bigger challenge than many anticipate.

Consent and data governance: From policy to system logic 

CMS-0057-F requires payers to share more data, but within strict legal and regulatory boundaries, including federal rules, state privacy laws, and contractual obligations. Many organizations have detailed consent policies on paper, but they stop there. 

To operationalize consent, you must answer:   

• What data may be released for which use cases (e.g., treatment, payment, operations)?  
• Under what conditions and for which populations or products?  
• How do state-specific regulations and special protections (e.g., behavioral health, reproductive care) apply?  
• How are opt-in/opt-out choices recorded, honored, and audited over time? 

Those decisions must become system logic in your APIs and workflows, not just text in a policy binder. Without that, CMS-0057-F puts you on the wrong side of either compliance risk or under-sharing that frustrates providers and members.

Terminology and knowledge management: Living assets 

CRD, DTR, and PAS workflows are powered by value sets, coverage rules, and other knowledge artifacts that change constantly. Benefit designs evolve, medical policies are updated, coding systems are revised, and clinical guidelines shift over time. 

If you treat terminology as a one-time build instead of a continuous capability, your implementation will slowly diverge from reality:   

• Prior auth decisions won’t reflect current policies
• CRD and DTR suggestions won’t align with what the plan will pay for
• Measures and reports may be calculated with outdated definitions

Terminology and knowledge management need clear stewardship, versioning, testing, and rollback paths, the same rigor you apply to core configuration or code releases.

Data ingestion and normalization: APIs don’t fix data 

FHIR APIs expose data; they don’t fix it. For CMS-0057-F, that data comes from a web of systems: claims, clinical feeds, care management, utilization management, provider directories, and more. 

Common pitfalls include:   

• Legacy data structures that don’t map cleanly to FHIR resources
• Inconsistent coding and value sets across source systems
• Bulk FHIR performance issues when moving large volumes of historical data

The quality of your APIs will never exceed the quality and consistency of the underlying data. Sustainable programs invest in robust ingestion, normalization, and reconciliation pipelines as part of the architecture, not as late-stage enhancements.

External connectivity and trust: Expanding the perimeter 

CMS-0057-F expands your connectivity beyond internal systems to other payers, providers, QHINs, and third-party applications. That brings with it a new trust surface: 

• Certificate and key management for external connections 
• Organizational validation and ongoing trust frameworks
• Monitoring and logging for external data access and behavior

This is operational work that persists long after go-live; it’s closer to running a health information network service than standing up a one-time integration. 

These domains: identity, consent, terminology, data, trust are where CMS-0057-F programs stall when they are discovered late. They require enterprise architecture and operational design, not just product configuration.

Why architecture up front changes everything 

Across multiple implementations, a consistent pattern emerges: 

• Months 1–2: Platform selected, contracts signed, key teams assembled
• Months 3–4: FHIR APIs deployed, authentication working, endpoints passing basic tests
• Months 5–6: Identity mismatches, consent ambiguities, and terminology gaps surface in integration and UAT
• Months 7–9: Reporting requirements and operational governance gaps become visible
• Month 10+: Program timeline slows or resets while teams scramble to build capabilities that should have been designed at the start

This is not a technology failure — it’s an architecture failure. The industry has largely solved API deployment. What we haven’t solved is designing the operational layer of interoperability deliberately, before committing to platforms and timelines.

Good CMS-0057-F architecture must answer: 

• Who owns consent and data governance, and how are those rules implemented consistently across channels? 
• What is our identity confidence model, and how does it extend across internal and external sources? 
• How are knowledge artifacts authored, versioned, and retired? 
• How will we generate CMS-required reporting and internal monitoring metrics without brittle, manual processes? 
• What is our approach to external network trust, including QHINs and partner payers? 

Crucially, the architecture must treat FHIR as a capability layer that orchestrates and exposes existing assets — not as an excuse to rip and replace every legacy system. That’s how you reduce risk and set yourself up to expand capabilities over time instead of being boxed into the first use case you implement. 

When these questions are answered up front, CMS-0057-F becomes a vehicle for modernizing interoperability operations instead of a never-ending compliance fire drill.

Want to see how this plays out in practice? 

On March 31, Firely and HIKE HEALTH are hosting a live webinar expanding on these topics. Our speakers have delivered CMS-0057-F implementations across the US and will share what the architecture actually looks like in production — the decisions that prevent costly rework, the phased roadmap through 2027, and the questions your team should be asking now. 

Save your spot: CMS-0057-F compliance to scalable FHIR: A practical playbook — March 31, 2026.