CMS interoperability & prior authorization rules
US Health IT Policyarticle · 6 मिनट · अपडेट 10 अग॰ 2026

CMS interoperability & prior authorization rules

लेखक Rajendra Sharma, RN, CPC, CPBसमीक्षक Rajendra Sharma, RN, CPC, CPB · 19 जुल॰ 2026

CMS-9115-F built the Patient Access and Provider Directory APIs; CMS-0057-F adds Provider Access, Payer-to-Payer and Prior Authorization APIs with staged compliance dates through 2027.

FHIRUS CoreDa VinciUSCDI

In one line

ASTP/ONC regulates the software; CMS regulates the payers. Two CMS rules — CMS-9115-F (2020) and CMS-0057-F (2024) — are why a US health plan now has to run FHIR APIs at all, and why prior authorization is being dragged out of the fax machine.

Who is "impacted"

Both rules bind the same family of CMS-regulated payers:

  • Medicare Advantage organizations
  • State Medicaid and CHIP fee-for-service programmes
  • Medicaid managed care plans and CHIP managed care entities
  • Qualified Health Plan issuers on the Federally-Facilitated Exchanges

Note what is missing: employer-sponsored commercial plans, standalone Part D, and QHPs on state-based exchanges are outside the rules' direct reach. Many commercial payers build the same APIs anyway, because their delegated Medicare Advantage lines need them.

CMS-9115-F — Interoperability and Patient Access (2020)

Published 1 May 2020. It established four things.

Patient Access API. The payer must expose, through a patient-authorised app, the data it holds: adjudicated claims including cost information, encounters with capitated providers, provider remittances, enrollee cost-sharing, and clinical data as defined in USCDI v1 where the payer maintains it. Data must be available no later than one business day after a claim is adjudicated or the data is received.

Provider Directory API. A public endpoint — explicitly without authentication or authorization protocols — carrying names, addresses, phone numbers and specialties, updated within 30 calendar days of the payer receiving directory information or an update.

Payer-to-payer data exchange. At the patient's request, the payer sends the USCDI v1 clinical data set to the patient's new payer, so coverage changes stop resetting a person's record to zero.

ADT event notifications. Not an API rule at all — a change to the Medicare Conditions of Participation at 42 CFR 482.24(d), 482.61(f) and 485.638(d). Hospitals, psychiatric hospitals and critical access hospitals with a conformant electronic system must send admission, discharge and transfer notifications to the patient's practitioners and post-acute providers. Applicability date: 30 April 2021. Notifications may ride HL7 v2 messages, C-CDA documents, or a FHIR-based API. This is the single most-implemented provision of the rule and the reason so many US hospitals suddenly needed an ADT feed.

Enforcement of the Patient Access and Provider Directory APIs began 1 July 2021 after a period of enforcement discretion.

CMS-0057-F — Interoperability and Prior Authorization (2024)

Published in the Federal Register on 8 February 2024. It keeps the 9115 APIs, expands one, and adds three.

APIWhat it doesHL7 FHIR guide CMS recommends
Patient Access (expanded)Adds prior authorization requests and decisions to the existing patient-facing APICARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button)
Provider Directory (from 9115)Public network and pharmacy directoryDa Vinci PDex Plan Net
Provider AccessLets a provider pull claims, encounters and USCDI data for patients attributed to them; patients may opt outDa Vinci PDex
Payer-to-PayerMoves data between concurrent and former payers; patient opt-inDa Vinci PDex
Prior AuthorizationDiscover whether authorization is needed, gather the documentation, and submit itDa Vinci CRD STU 2.0.1, DTR STU 2.0.0, PAS STU 2.0.1

The implementation guides are recommended, not mandated — the required standards are the FHIR release and security standards named in regulation. In practice, building against the recommended guide is the only sane choice, because that is what every trading partner implemented.

The prior authorization trio is worth understanding as a workflow, not three products:

  1. CRD (Coverage Requirements Discovery) fires from the EHR at ordering time and answers is prior authorization required, and what are the rules?
  2. DTR (Documentation Templates and Rules) pulls the payer's questionnaire into the EHR and pre-populates it from the chart.
  3. PAS (Prior Authorization Support) submits the request — and, under the covers, bridges to the X12 278 transaction the payer's adjudication systems still speak.

The operational rules, which arrive first

The API build is the headline; the process changes hit sooner and are what patients notice.

  • 72 hours for expedited (urgent) prior authorization decisions.
  • 7 calendar days for standard (non-urgent) decisions.
  • A specific reason for denial, regardless of how the request was submitted.
  • Public reporting of prior authorization metrics on the payer's own website, annually, for the previous calendar year: the list of items and services requiring authorization (drugs excluded), the percentage of standard requests approved, denied, and approved after appeal, the percentage extended and then approved, the percentage of expedited requests approved and denied, and turnaround times. The first posting — covering calendar year 2025 — is due by 31 March 2026.

QHP issuers on the FFEs are excluded from the decision-timeframe requirement, and none of these prior authorization policies apply to drugs. Drugs are addressed separately; CMS has since issued a proposed rule (CMS-0062-P) covering interoperability standards and prior authorization for drugs — proposed, not final, so treat it as direction rather than duty.

Compliance dates you must not blur

WhenWhat
1 January 2026Operational prior authorization policies: decision timeframes, specific denial reasons
31 March 2026First public posting of prior authorization metrics (for CY 2025)
1 January 2027The four APIs — Patient Access expansion, Provider Access, Payer-to-Payer, Prior Authorization
CY 2027The Electronic Prior Authorization attestation measure in MIPS Promoting Interoperability and the Medicare Promoting Interoperability Program for hospitals and CAHs

The 2027 API dates are "generally 1 January 2027" and vary by payer type: 1 January 2027 for MA organizations and Medicaid/CHIP FFS; the rating period beginning on or after that date for Medicaid and CHIP managed care; the plan year beginning on or after that date for QHP issuers on the FFEs. If you are writing a project plan, use the payer-specific date, not the headline.

The CY 2027 provider measure is an attestation: the clinician or hospital answers yes/no (or claims an exclusion) to having requested at least one prior authorization electronically via a Prior Authorization API, using data from CEHRT, for a medical item or service — excluding drugs.

Why it matters to a builder

Everything here is FHIR R4 over OAuth-secured endpoints, with US Core underneath and Da Vinci guides on top. If you can read an implementation guide, run a SMART launch and reason about a claim, you can work on any of it. And the deadlines are real budget lines at every US payer right now — which is where the work is.

संदर्भ

  1. CMS — Interoperability and Patient Access final rule (CMS-9115-F) fact sheet
  2. CMS — Interoperability and Prior Authorization final rule (CMS-0057-F) fact sheet
  3. CMS — APIs and relevant standards and implementation guides
  4. CMS — ADT patient event notification Conditions of Participation FAQ

संबंधित entries