If you run technology at a health plan, three federal rules define your next 24 months. This card is the one-page version.

CMS-9115-F (2020) set the floor. Patient Access API and payer directory requirements — most plans met it with a thin compliance layer. It established the pattern: member data, exposed over FHIR, to apps the member chooses.

CMS-0057-F is the one with teeth. The operational provisions are already live (since January 2026): prior-auth decisions in 72 hours for urgent and 7 calendar days for standard requests, with specific denial reasons required. The API provisions land January 1, 2027 (Medicare Advantage and Medicaid/CHIP FFS; managed-care and QHP variants follow by rating/plan year): an upgraded Patient Access API that includes prior-auth status, a Provider Access API, a Payer-to-Payer API (member history follows the member between plans), and the Prior Authorization API — the CRD/DTR/PAS workflow that lets a provider discover requirements, fill documentation, and submit an auth request without a fax machine. Public reporting of prior-auth metrics starts 2027.

CMS-0053-F just added attachments. Finalized March 24, 2026: HIPAA standards for claims attachments and electronic signatures — X12 275/277 (v6020) for transport, HL7 C-CDA and the HL7 Attachments IG for clinical content. Compliance by May 26, 2028. If you just built prior-auth documentation flows for 0057, attachments is the same muscle applied to claims.

The strategic read: these rules share one architecture — clinical and administrative data as FHIR, requested by the party who needs it, when they need it. Plans that treat each rule as a separate compliance project will build the plumbing three times. Plans that treat it as one data platform build once and comply thrice.

Where ImOnFHIR fits: this lab exercises exactly these workflows — payer-realistic member/coverage scenarios, PAS/DTR payload validation, and test data that behaves like production without containing anyone real.