CMS proposes extending electronic prior authorization requirements to drugs
CMS-0062-P would bring drug authorizations into a broader interoperability framework while also proposing updated standards and transaction requirements.
Editorial figure by Prior Auth Monitor. Source context: Centers for Medicare & Medicaid Services.
A proposed bridge between medical and drug authorization
CMS-0057-F excluded drugs from its operational and Prior Authorization API requirements. CMS-0062-P proposes to close part of that gap by extending electronic submission, shorter decision timeframes, transparency, and updated technology standards to drug authorization. The proposal also reaches beyond payer API obligations by addressing transaction standards used by HIPAA covered entities.
That does not collapse medical-service and pharmacy authorization into one workflow. Pharmacy electronic prior authorization already relies heavily on NCPDP SCRIPT transactions, while medical-service authorization is shaped by X12 and the HL7 Da Vinci CRD, DTR, and PAS implementation guides. Buyers should expect products to state precisely which benefit, transaction path, and regulatory population they support.
What implementation teams should do now
Because the rule remains proposed, implementation teams should use it for scenario planning rather than record its provisions as settled obligations. A useful readiness review maps current drug authorization channels, data sources, formulary and benefit dependencies, request and response transactions, decision-time reporting, and the owners responsible for maintaining each connection.
Vendors may advertise readiness before a final rule exists. A defensible evaluation separates demonstrated support for named standards from roadmap statements, distinguishes production interfaces from test environments, and records which proposed requirements would still require payer, PBM, EHR, pharmacy, or clearinghouse work outside the product.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Prior Auth Monitor will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.