Three CMS rules stack into one architecture. This card is the timeline and how the layers sit on top of each other; the dated compliance milestones live on the watch-list, which we review monthly.
CMS-9115-F (2020) — the floor. The Interoperability and Patient Access rule stood up the Patient Access API and payer directory requirements. Most plans met it with a thin compliance layer, but it set the pattern: member data exposed over FHIR to apps the member chooses.
CMS-0057-F — the operational layer. Prior-auth decision-timing and denial-reason provisions are already live; the four API surfaces (Patient Access with prior-auth status, Provider Access, Payer-to-Payer, and the CRD/DTR/PAS Prior Authorization API) land on the 2027 runway. The cms-0057-four-apis card is the surface-by-surface breakdown.
CMS-0053-F — the attachments layer. Finalized March 2026, it adopts HIPAA standards for claims attachments and electronic signatures: X12N 275/277 (v6020) for the transaction, with HL7 C-CDA and the HL7 Attachments IG for clinical content. It applies the same evidence-exchange muscle to claims that 0057 applied to prior auth. Its FHIR cousin — the CDex $submit-attachment path — is the cdex-attachments card.
The layers share one shape: clinical and administrative data as FHIR (or its X12 cousin), requested by the party who needs it, when they need it. A plan that treats each rule as a separate project builds the plumbing three times; a plan that treats them as one platform builds once and complies thrice.
What ImOnFHIR does with it: we use the three CMS pages as the comply-track spine — "here are your layered mandates, in order" — and the watch-list carries the dated milestones so no date is restated in two places. We name the transaction sets (275/277 v6020) and point, don't host: no licensed X12 TR3, C-CDA, or CPT bytes live in this repo.