FHIR Compliance for EHR Development: What CMS-0057-F Actually Requires

CMS-0057-F is the regulation that made FHIR compliance a real business requirement, not just a technical aspiration, for US EHR vendors and health plans. The rule requires four FHIR APIs — Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization — each with specific conformance expectations.

Patient Access API. Payers must expose enrolled patient data via FHIR. The endpoint must support US Core profile-conformant reads for Patient, Coverage, ExplanationOfBenefit, and the Da Vinci Member Data profiles. Rate limiting must accommodate SMART-launched apps, and the SMART launch spec must be supported.

Provider Access API. Payer-to-provider data sharing at the point of care. Providers request patient data via FHIR queries, payers respond. The tricky part: providers must be authenticated as themselves, not on behalf of patients, which uses SMART's system launch mode rather than patient launch.

Payer-to-Payer API. Cross-payer member data exchange for members who switch coverage. Bulk data on FHIR is the natural fit; the Bulk Data Access IG covers the transport. Timing is regulated — receiving payer must have data available within days of member enrollment.

Prior Authorization API. The most complex of the four. Uses the Da Vinci PAS (Prior Authorization Support) IG for request-response flows, and the CRD (Coverage Requirements Discovery) IG for decision-support. Vendors that treat this as a simple form submission will fail conformance testing.

Conformance testing

Inferno is the ONC-blessed FHIR conformance tester. For CMS-0057, Inferno's Payer/Provider/Payer-to-Payer test suites verify each API's compliance. Run them in CI on every deploy.

Common compliance gaps

CMS-0057 compliance is a substantial engineering project — not a checkbox on a feature list. Teams that plan for it as such get through Inferno testing on first pass; teams that treat it as a marketing requirement typically need a re-implementation cycle.