I should say upfront: I run a clinician-side prior authorization automation startup called Artificer Health. We have a commercial interest in some of the outcomes I’m about to discuss, particularly anything that strengthens the position of human-in-the-loop architectures and weakens the position of fully-autonomous “touchless” PA submission. I’ll flag the section where that bias matters when we get there. The rest of this essay is mechanism, not advocacy, and you should be able to read it as a field guide regardless of what you think of my company.
The proposed rule is CMS-0062-P, Interoperability Standards and Prior Authorization for Drugs, published in the Federal Register on April 14, 2026. The comment period closes at 11:59 PM Eastern on June 15. Most of the trade press coverage has framed it as “CMS extends 2024 prior auth rule to drugs,” which is correct in the way that calling a Tesla “an alternator and four wheels” is correct. The seismic move in this rule is two paragraphs deep, in the section on HIPAA Administrative Simplification, and it is going to reshape the architecture of American prior authorization for the rest of this decade.
What HIPAA Administrative Simplification actually does, and why FHIR has not been part of it until now
The Health Insurance Portability and Accountability Act of 1996 has two parts that get conflated in the popular imagination. There’s the privacy and security stuff (the Privacy Rule, the Security Rule, the Breach Notification Rule), which is what most people mean when they say HIPAA. And there’s Administrative Simplification, a less-discussed but more economically consequential piece, which says that certain healthcare transactions — claims, eligibility checks, prior authorization requests, electronic remittance — must be conducted using federally-specified standards. Once a standard is adopted under Administrative Simplification, it becomes mandatory for every “covered entity” in American healthcare: providers, health plans, and clearinghouses.
The standards adopted so far are old. Most of them date from the late 1990s. They were drafted by the Accredited Standards Committee X12, an EDI standards body, in a different technological era. Prior authorization, specifically, has been governed since 2000 by an X12 transaction called the 278. The 278 does what it does: it moves a structured request from a provider to a payer and a structured decision back. It is not designed for clinical attachment exchange, which is why your physician’s office still faxes documentation. It does not do real-time queries. It is not webby in any meaningful sense.
FHIR — Fast Healthcare Interoperability Resources, pronounced “fire” — is the modern alternative. It is an HL7 standard (HL7 being the standards body that, since the 1980s, has owned clinical data exchange in healthcare). FHIR is designed for the API era. It uses RESTful HTTP, JSON or XML payloads, and a resource model that maps cleanly to what software engineers expect from a modern API. Apple Health uses FHIR. Epic exposes FHIR. The 21st Century Cures Act mandated FHIR-based patient access. CMS has been adopting FHIR-based standards in its own rulemaking for several years, including in the 2024 prior authorization final rule (CMS-0057-F) that this rule extends.
But FHIR has never been a HIPAA standard. The 2024 rule made FHIR-based prior auth APIs mandatory for a specific list of CMS-regulated payers (Medicare Advantage, Medicaid managed care, CHIP, federally-facilitated exchange QHPs). It did not make those APIs mandatory under HIPAA. The distinction matters: HIPAA standards apply to every covered entity, not just CMS-regulated payers, and they carry the full enforcement weight of OCR. CMS has direct programmatic leverage over its own beneficiaries’ plans. HIPAA has leverage over everyone.
CMS-0062-P is the rule that closes the gap. Specifically, the Department of Health and Human Services proposes to adopt the HL7 FHIR Da Vinci Coverage Requirements Discovery (CRD) Implementation Guide, the Documentation Templates and Rules (DTR) Implementation Guide, and the Prior Authorization Support (PAS) Implementation Guide as standards under HIPAA Administrative Simplification. It also adopts the Da Vinci Clinical Data Exchange (CDex) Implementation Guide for prior authorization attachments. If the rule is finalized as proposed, these become the first FHIR-based standards ever adopted under HIPAA. The compliance target is October 1, 2027.
I want to dwell on why this matters, because the technical-sounding nature of the move obscures the size of it. Once an interoperability standard is mandatory under HIPAA, three things happen. First, it applies universally — not just to CMS-regulated payers but to every commercial plan, every clearinghouse, every provider organization that submits prior auths electronically. Second, it gets enforcement teeth: HHS can investigate non-compliance, the Office for Civil Rights can pursue penalties, and the legal durability of the standard is qualitatively different from “CMS encourages.” Third, it locks in the architecture: once the X12 ecosystem has been displaced for a transaction class, it does not come back. The current X12 278 transaction continues to exist, and the proposed rule preserves its use during a transition period, but its primacy is over.
The honest summary is that this is not a rule about prior authorization for drugs. It is a rule that makes FHIR the lingua franca of American administrative healthcare. The drug-PA scope is the vehicle. The standard is the cargo.
What the four Implementation Guides actually do
Da Vinci is a multi-stakeholder project under HL7, started in 2018, that produces Implementation Guides describing how FHIR resources should be combined to accomplish specific clinical-administrative workflows. Four of the Da Vinci IGs are at the heart of CMS-0062-P. Here’s what each one is for, in plain terms.
CRD, Coverage Requirements Discovery. The clinician orders a service or prescribes a drug. The EHR queries the payer in real time and asks: does this patient need prior authorization for this order? If yes, what are the specific coverage requirements? The payer responds with a structured answer the EHR can act on. CRD is the front door. Without it, the clinician guesses or relies on stale formulary data. With it, the clinician knows at the moment of ordering whether they’re about to enter a prior authorization workflow, and the workflow gets configured with the actual rules the payer is going to apply.
DTR, Documentation Templates and Rules. Once the clinician knows that prior authorization is required and what coverage criteria apply, DTR is the mechanism by which the payer publishes a structured questionnaire — technically a FHIR Questionnaire resource — describing exactly what documentation is needed. The clinician’s EHR pre-populates the questionnaire from the patient record where it can, surfaces the gaps for the clinician to fill, and produces a payer-specific submission that maps cleanly to the payer’s medical-necessity review criteria. DTR is what turns “every payer wants different documentation” from a manual research project into a software problem.
PAS, Prior Authorization Support. PAS is the actual submission. It carries the DTR-generated documentation, the clinical attachments (handled by CDex, below), and any required forms, and routes them to the payer’s adjudication system using FHIR. Where necessary, it maps to the legacy X12 278 at the boundary. The clinician submits, the payer decides, and the decision flows back through the same channel.
CDex, Clinical Data Exchange. CDex specifies how to exchange supporting clinical documents — clinic notes, lab reports, imaging reports, treatment plans, prior therapy records — alongside a prior auth submission. CDex supports C-CDA documents, PDF, plain text, and a few other formats. It is what turns the back half of a prior authorization submission from a fax problem into a software problem.
These IGs are not new. They have been in development for years and “strongly recommended” by CMS in prior rules, which is a phrase that means almost nothing in practice. Sophisticated payers implemented them. Less sophisticated payers did not. The variation produced exactly the asymmetry you would predict: clinician-side software has had to handle every combination of “this payer supports CRD, this one doesn’t, this one supports DTR but with a non-conformant questionnaire structure, this one supports PAS only via a clearinghouse intermediary.” Mandatory adoption under HIPAA collapses that variation. By October 2027, every covered entity is supposed to support all four IGs in their conformant form. That is the architectural shift the rule produces.
The unresolved problem the rule does not solve: medical benefit versus pharmacy benefit
The proposed rule maintains a split that has existed in American healthcare since Medicare Part D was created in 2003. Drug prior authorization runs on parallel tracks: FHIR-based Da Vinci PAS handles medical-benefit drugs (administered in clinical settings, billed under Medicare Part B and equivalent benefits), and NCPDP SCRIPT handles pharmacy-benefit drugs (Medicare Part D and equivalent). NCPDP is a separate standards body, with its own implementation guides, its own ecosystem, its own technology stack. The dual-track architecture is correct in the sense that medical-benefit and pharmacy-benefit drugs travel through different payer adjudication systems, and trying to unify them would produce worse outcomes than leaving them parallel.
What the rule does not address is how the clinician, at point of order, knows which track applies. This sounds esoteric. It is not. A 60-mg dose of methotrexate for rheumatoid arthritis can be either medical or pharmacy benefit depending on whether it’s administered in clinic or self-injected at home. A GLP-1 receptor agonist can be medical or pharmacy depending on indication and plan design. A monoclonal antibody can be medical or pharmacy depending on site of care. The same drug, for the same patient, at the same point in care, may be covered through one channel for one indication and the other channel for another indication.
Existing standards do not solve this. The CRD CoverageInformation extension is close but was not designed for the routing question specifically. NCPDP RTPB knows about pharmacy-benefit coverage but not about medical-benefit alternatives. NCPDP Formulary & Benefit (F&B) is a formulary standard, not a benefit-determination standard.
The fix, in my view, is to require payers to publish a machine-readable benefit-determination signal at the patient-and-drug level, retrievable by clinician-side tools at the point of order. This is not technically complicated to specify. It does require CMS to specify it, because no payer will voluntarily build the infrastructure if no peer payer is also doing so — the classic coordination problem that regulation exists to solve. This is the single highest-leverage change a comment could produce in the technical content of the final rule. Without it, dual-track standardization shifts complexity from payers (who can absorb it) to clinicians (who cannot).
The political fight: the certification tiers RFI
The rule includes five formal Requests for Information — sections where CMS has not yet decided and is asking the public. Most of them are operationally interesting; one of them is going to produce the loudest fight in the comment record, and it deserves a real treatment.
The agency proposes three escalating tiers of oversight for payer API technology. Tier 1 is mandatory conformance testing using ONC’s Inferno framework, an open-source FHIR testing tool, with results either published or reported to CMS. Tier 2 is mandatory sandbox environments maintained by payers, where third-party developers can verify behavior before production deployment. Tier 3 is full certification of payer API technology under the ONC Health IT Certification Program — the same regime that currently governs EHR vendors.
Tier 3 is the seismic one. Payers and their technology vendors currently sit outside the information-blocking enforcement regime created by the 21st Century Cures Act. EHR vendors are subject to it; payer-side vendors are not. ONC certification of payer API technology would pull payer vendors inside the regime. Information blocking carries OIG civil monetary penalty authority — up to $1 million per violation. The comment period is going to see substantial pushback from payer trade associations and from the technology vendors that build for them. There is an argument to be had about whether ONC’s authority under HITECH actually extends to payer-side technology; the post-Chevron deference environment makes that argument more interesting than it would have been three years ago.
Before continuing the regulatory argument: a useful empirical aside. We at Artificer run a CMS-0057-F compliance pipeline that builds a payer universe out of CMS Medicare Advantage enrollment data, healthcare.gov QHP landscape data, medicaid.gov MCO enrollment data, and the ONC Lantern payer endpoint catalog, then probes the payer-side FHIR Patient Access APIs that the 2024 rule already made mandatory. As of our June 12, 2026 scan — under seven months out from the January 2027 CMS-0057-F API deadline — we probed 134 publicly-discoverable payer-side endpoints. Seventy-three returned a capability statement; the rest returned errors or were unreachable. Of the seventy-three live endpoints, zero achieved full Da Vinci Prior Authorization Support conformance. Thirty-five declared a partial Da Vinci profile — universally PDex and US Core only, with no CRD, DTR, or PAS. The remaining thirty-eight live endpoints exposed only baseline FHIR resources.
There is a finer-grained finding worth surfacing. Twenty-nine of those endpoints — all brands within one large payer family — have served the DSTU2-era Conformance resource on their /api/fhir/ path intermittently across our scans: present on May 10, absent on May 13 and May 17, present again on June 9 and June 12 — the same twenty-nine endpoints each time, with the dated scan logs on file. DSTU2 is two major FHIR revisions behind the R4 that CMS has already mandated; serving it at all under a mandated interface is a conformance defect, and serving it intermittently is the worse failure mode — an integrator who tests once and passes can be silently broken the following week. The parallel /api/fhir-r4/ paths serve R4 throughout. The underlying conformance picture — zero full Da Vinci PAS across the 134 endpoints — did not move on any scan date.
That is the case for Tier 1 in one paragraph. Mandatory Inferno conformance testing — run on a schedule, with published scores — is the cheapest regulatory intervention available. A point-in-time test that happened to run during the May 13–17 window would have missed the DSTU2 regression that was present on May 10 and present again on June 9 and June 12. Conformance that changes week to week is exactly what continuous, published scoring catches and one-time attestation cannot see — and the variation is provable from the small-scale natural experiment we just ran.
CMS asks commenters to “define the trigger so we can pull it later” — which is the agency saying, in regulatory-speak, “we want certification to be a tool we can use, but we don’t want to deploy it in version one of the rule.” That is a reasonable regulatory posture and the right place for the comment community to engage. My read: Tier 1 is a free win and should be the floor for everyone, with conformance scores published rather than just reported. Tier 2 is correct but needs a shared-infrastructure path for small and regional payers that lack engineering capacity for individual sandboxes. Tier 3 is correct in principle but should be triggered by 12 months of measured, persistent payer non-compliance with Tier 1 and Tier 2, not imposed at general roll-out. The trigger conditions worth proposing: an Inferno conformance score below a published threshold for two consecutive measurement periods, or a documented pattern of partner-developer integration failures filed with CMS above a threshold count.
If you build software that integrates with payer FHIR APIs and have observed conformance failures in production, this is the comment to file. Bring data. The numbers above are what one small clinician-side startup can produce with publicly-available registries in a weekend; the comment record needs more of this, from more vantage points.
The other RFIs, briefly
Two of the remaining four RFIs are worth a short note.
Step therapy. The agency proposes routing prior step-therapy determinations between payers via the Payer-to-Payer API, so that a patient who has already failed step one and step two under a prior plan does not have to repeat those failures under a new plan. The clinical literature on step-therapy redundancy is unambiguous about the harm — most acutely in oncology, rheumatology, behavioral health, and obesity medicine — and the operational fix is straightforward. The fight will be over whether receiving payers must honor prior determinations or merely consider them. The right comment is the one that pushes for a clinical safeguard: any receiving payer who chooses to re-impose step therapy should have to document, at the patient level, the specific clinical change that justifies re-evaluation. Without that safeguard the routing benefit is realized only when payers voluntarily honor it.
Lab and DMEPOS scope. The 2024 final rule excluded laboratory testing and durable medical equipment / prosthetics / orthotics / supplies. Both categories have, predictably, become areas of disproportionate clinician burden — specialty lab in oncology genomics, autoimmune panels, and hormone panels; DMEPOS in orthopedics, pain management, and post-surgical care. Most EHR PA modules don’t handle these workflows at all. The right comment supports phased extension: labs in year one of any final rule, DMEPOS in year two.
The remaining two RFIs (electronic event notifications for value-based care, and healthcare resiliency) are worth substantive comment if your operations touch them. They will not be the source of the major fights in this rule.
The clinician-authority question (where my commercial bias is loudest)
Here is the section where my commercial position matters most, so I’m going to be explicit about it before I make the argument.
Prior authorization is a medical-legal act. The clinician who signs a PA submission is asserting that, in their professional judgment, the requested service or therapy is medically necessary for the patient. That assertion has malpractice implications, fraud-and-abuse implications, and clinical-responsibility implications. The question that no court, state legislature, or licensing board has resolved is who is responsible when an AI tool, acting autonomously, submits a prior authorization on a clinician’s behalf and the submission turns out to have been clinically wrong, fraudulently characterized, or causally linked to a patient adverse outcome. The honest answer is nobody knows. There is no case law. There is no statutory clarity.
Two architectural responses to that uncertainty exist. The first is to build for autonomous submission: AI submits PA packages without clinician review, the practice gets faster cycle times, and everyone hopes the unresolved liability question doesn’t bite. The second is to build for human-in-the-loop submission: every package is reviewed and signed by the treating clinician before transmission, the practice gets slower cycle times than the autonomous version but faster than manual, and the liability boundary stays where it has always been — with the licensed clinician.
My company runs the second architecture. Read what follows with that in mind.
I think the final rule should clarify, in the preamble and where appropriate in regulatory text, that nothing in CRD, DTR, PAS, or CDex removes the treating clinician’s responsibility for clinical determinations submitted on prior authorization packages. This is not a mandate of human-in-the-loop — clinicians and practices remain free to choose what architecture they trust — but it is a regulatory acknowledgment that the medical-legal authority for what is asserted on a PA submission belongs to the licensed clinician, regardless of how the package was assembled. Without that clarification, the testing regime and the certification framework risk creating implicit incentives toward autonomous submission, which is a policy outcome the agency probably does not intend and which patients have not benefited from in any deployed AI-in-healthcare context I am aware of.
There are reasonable people who will argue the other side. They will say HITL preserves clinician burden the rule is trying to eliminate, that AI is reliable enough to handle PA submission autonomously, that the liability question is a paper tiger. These are defensible positions and I think they are wrong on the merits, but the comment period is where the merits get debated.
What to do, and how to do it usefully
Comments are filed via regulations.gov under docket CMS-2026-0062. The deadline is 11:59 PM Eastern on June 15, 2026. Comments are public and permanent — they become part of the searchable regulatory record, read by the agency in the construction of the final rule and (increasingly) by investors, analysts, trade press, and lawyers tracking the space.
Useful comments share two properties: specificity and operational data.
If you operate a payer-side FHIR implementation and have produced friction with partner developers, file on the certification-tiers RFI with your specific friction patterns — what failed, where, and how often. Anonymized data is fine; aggregated data is fine; vendor-named data is better.
If you are a clinician in a step-therapy-heavy specialty (rheumatology, oncology, behavioral health, obesity medicine, dermatology), file on the step-therapy RFI with the specific patient population you’ve seen harmed by step-therapy redundancy. Patient narratives — anonymized — are the rare currency in regulatory comment records.
If you build clinician-side software that touches the medical-versus-pharmacy benefit problem, file on Section VIII with proposed signal structures.
If you operate in the lab or DMEPOS PA workflow today, file on that RFI with the specific manual workarounds you’ve built and what they cost.
If you have an opinion on the certification tiers, file with a specific trigger condition you’d defend.
The comment record is small. The agency reads carefully. Specific is better than general. Operational data is better than hypothesis. Two pages with real friction patterns will be read more carefully than ten pages of position-paper prose.
A calmer summary, for readers who skipped to the bottom
CMS-0062-P proposes to adopt FHIR as a HIPAA Administrative Simplification standard for prior authorization, which is the first time FHIR has ever been a HIPAA standard. The compliance target is October 1, 2027. The rule does several other consequential things — extending prior auth reform to drugs, requiring four Da Vinci Implementation Guides, creating the first regulatory framework for Payer-to-Payer step-therapy routing — but the HIPAA move is the spine. If finalized as proposed, the architecture of American prior authorization stops being primarily an X12 clearinghouse problem and starts being primarily a FHIR software problem. Software problems are tractable in ways clearinghouse problems have not been.
The “if finalized as proposed” does a lot of work in the previous paragraph. Comment periods are where rules change. This one closes June 15.
Bobby Kuzma is the founder and CEO of Artificer Health, a clinician-side prior authorization automation company. Artificer’s product is built on a human-in-the-loop architecture, which shapes the position taken in the clinician-authority section above. The operational data cited in the certification-tiers section comes from Artificer’s CMS-0057-F payer-FHIR compliance pipeline; the methodology and the per-payer scorecard are public at artificerhealth.com. Artificer filed a public comment on CMS-0062-P on June 14, 2026, available on the public record at regulations.gov under docket CMS-2026-0062. Bobby can be reached at [email protected].