On April 10, 2026, the Centers for Medicare & Medicaid Services published a proposed rule — the 2026 CMS Interoperability Standards and Prior Authorization for Drugs Proposed Rule, known as CMS-0062-P — and the public comment period closes on June 15, 2026. For any healthcare organization that has been treating “interoperability” as a future problem, the window to weigh in is days away, and the direction of travel is unmistakable: prior authorization is moving onto standardized FHIR APIs, and for the first time the requirement reaches prescription drugs.
What CMS-0062-P actually proposes
The 2024 final rule, CMS-0057-F, already pushed impacted payers toward a set of FHIR-based APIs — a Patient Access API, a Provider Access API, a Payer-to-Payer API, and an electronic Prior Authorization API — but it carved out drugs. CMS-0062-P closes that gap. It extends the electronic prior authorization framework to cover prior authorizations for drugs, and proposes that impacted payers support electronic prior authorization for all drugs beginning October 1, 2027.
The rule draws a functional line between drugs billed under the medical benefit — typically administered in a clinical setting and processed through medical claims — which would fall under the FHIR-based Prior Authorization API, and retail or self-administered drugs under the pharmacy benefit, which continue to use the established NCPDP SCRIPT standards. CMS also proposes that payers report their API endpoints to a centralized directory so providers and patients can actually find them.
The standards you will be building against
CMS-0062-P names specific HL7 FHIR implementation guides from the Da Vinci project, so this is not an abstract aspiration — it is a concrete technical target. The proposal adopts the Coverage Requirements Discovery (CRD) Implementation Guide version 2.2.1, the Documentation Templates and Rules (DTR) Implementation Guide version 2.2.0, and the Prior Authorization Support (PAS) Implementation Guide version 2.2.1.
In practice those three guides describe a chain: CRD lets a provider’s system learn, at the point of ordering, whether prior authorization is required and what the payer’s rules are; DTR gathers the required documentation, often by running payer-supplied questionnaires against data already in the chart; and PAS packages and submits the request, returning a decision over a FHIR interface rather than a fax line. Pinning exact versions matters because conformance is tested against them — a portal built loosely “to FHIR” is not the same as one that implements PAS 2.2.1.
Why this matters beyond payers
It is easy to read “impacted payers” and assume this is a health-plan problem. It is not. Every clinic, specialty practice, and digital-health vendor that sits on the other side of these transactions has to send and receive FHIR messages too. A practice whose scheduling and intake software cannot consume a CRD response will keep doing prior authorization by phone while competitors get near-real-time answers. A patient-facing portal that cannot read the Patient Access API cannot show people whether their medication was approved.
For patients, the payoff is concrete: fewer days lost to faxed forms and hold music, and visibility into authorization status from the same portal or mobile app where they already book visits and read results. For providers, it is administrative time recovered. But those benefits only materialize if the software on each end actually speaks the standard — and most older portals and homegrown intake tools do not.
A short readiness checklist
You do not need to wait for the final rule to find out where you stand. A few questions surface most of the gaps:
- Can your patient portal or mobile app read a payer’s Patient Access API and show coverage and authorization status, or does it only display data you enter by hand?
- Does your scheduling and intake flow have any hook for a CRD check at the point of ordering, or is prior authorization a separate manual step?
- If a payer published a FHIR endpoint tomorrow, is there an integration layer that could consume it — or is every connection hard-coded?
- Are your integrations pinned to specific implementation-guide versions, so a payer’s update is a planned change rather than a surprise outage?
How Vadimages helps
Vadimages is a web and mobile app development studio, and this is squarely a software problem. For healthcare clients we build the patient-facing and provider-facing layers that sit on top of these APIs: patient portals and companion mobile apps that read the Patient Access API to surface authorization and coverage status, scheduling and intake web apps that trigger CRD checks and DTR questionnaires at the right moment, and clean integration layers that connect your existing systems to a payer’s FHIR endpoints without rebuilding everything underneath. Because the rule pins specific Da Vinci versions, we design these integrations against the named guides and keep them version-aware, so a payer updating its API does not silently break your intake flow. If your current portal or booking tool predates FHIR, the practical first step is a focused integration project rather than a rip-and-replace — and that is the kind of build we scope every day.
Bottom line
CMS-0062-P signals that FHIR-based prior authorization is becoming the default, with drugs explicitly in scope and a proposed 2027 deadline for payers. The comment period closes June 15, 2026, so the policy is still moving — but the technical direction is set. Healthcare organizations should look now at whether their patient portals, mobile apps, and intake tools can read and write these APIs, and plan the integration work before the deadline becomes a scramble.
This article is for general information only and is not legal, compliance, or medical advice.