The question driving architecture conversations at about 91 days out from January 1, 2027 is sharper than it sounds: should the pharmacy-benefit side of prior authorization get treated as part of this sprint, or as the next one? CMS-0062-P proposes electronic prior-authorization requirements for drugs through two pathways: FHIR-based requirements for medical-benefit drug workflows and NCPDP standards for pharmacy-benefit drug workflows. The comment period closed June 15, 2026 without CMS publishing a final rule. Some implementation teams are treating that as a green light to ignore CMS-0062-P until it is final. Others are designing for it now on the theory that retrofitting later is more expensive than abstracting the interface today.

The answer is not to choose one over the other. It is to understand precisely which pieces are compliance-required by January 1, 2027, which are architecture-relevant, and which remain genuinely uncertain.

The CMS-0057-F Compliance Layer: What to Freeze Now

CMS-0057-F is not a proposal. It is a final rule. For Medicare Advantage organizations and state Medicaid and CHIP fee-for-service programs, the principal API requirements apply January 1, 2027. For Medicaid managed care plans and CHIP managed care entities, they apply to rating periods beginning on or after January 1, 2027. For federally facilitated exchange QHP issuers, they apply to plan years beginning on or after January 1, 2027.

The four API requirements in scope for each of these payer types are: the Prior Authorization API, updates to the Patient Access API to include PA information, the Provider Access API, and the Payer-to-Payer API. CMS recommends Da Vinci implementation guides -- including PDex, HRex, CRD, DTR, and PAS -- to support implementation of these APIs. Those guides are not independently mandatory under CMS-0057-F. Whether your implementation tracks the recommended Da Vinci IGs or takes a different conformant path is an architecture and interoperability decision, not a compliance binary, provided the payer still meets the rule's required API functionality, data, and technical-standard requirements. The ONC FY2027 IPPS final rule adopted newer versions of several relevant implementation guides, so the version landscape is actively moving; teams relying on specific IG versions should verify they are tracking the currently required versions before freezing dependencies.

What to freeze: the required API surface, authentication and authorization design, required data elements and response and status handling, audit trail, attribution and consent logic, and response-time controls (72 hours for expedited decisions, seven calendar days for standard decisions). These are not moving.

The CMS-0062-P Layer: What to Keep Modular

CMS-0062-P proposes to extend electronic prior authorization requirements to drugs via two parallel pathways depending on how a drug is classified by the plan.

For drugs a payer classifies as covered under the medical benefit -- often including clinician-administered or facility-billed drugs -- the proposal would extend the relevant CMS-0057-F FHIR API requirements to the associated drug PA workflows. The payer set matches CMS-0057-F. The proposed effective date is October 1, 2027.

For drugs covered under the pharmacy benefit, the proposal creates a separate pathway using NCPDP SCRIPT, the Formulary and Benefit standard, and Real-Time Prescription Benefit standards. The payer set for this pathway is different from the medical-benefit side: state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and federally facilitated exchange QHP issuers. CMS did not propose to impose this new NCPDP pathway on MA organizations, whose prescription-drug coverage is generally administered through Part D arrangements subject to separate Part D requirements.

Neither pathway is final. CMS-0062-P remains a proposed rule. But the architecture decision it forces is real regardless of finalization timeline: the routing between these two pathways can depend on payer benefit design, formulation, route and site of administration, claim type, and payer-specific coverage rules -- not merely on a medication's name or NDC. A clinician-administered biologic may be billed under a medical benefit in one setting and dispensed through a pharmacy benefit in another, creating different PA pathways for what clinicians may regard as the same therapy. CMS-0062-P proposes the two benefit-based pathways, but organizations will still need operational rules for classifying and routing drugs that can be covered differently across plans or settings. The final rule may clarify some of those issues, but architects should not assume CMS will prescribe a universal routing algorithm.

That ambiguity is not a CMS architecture failure -- it reflects a genuine characteristic of how commercial and government pharmacy benefits are structured. But it does mean that treating the routing as a problem to be solved once, definitionally, before you build the interface, is a mistake. The interface needs to accommodate a drug being processed on either pathway depending on plan context, and the routing logic needs to be exposed as a configurable operational decision rather than hard-coded.

How to Think About NCPDP

NCPDP SCRIPT, the Formulary and Benefit standard, and the Real-Time Prescription Benefit standard are not new infrastructure. They are already in production across e-prescribing and pharmacy-transaction workflows, including pharmacy networks, pharmacy benefit management systems, and the vendor ecosystems that support NCPDP-based transactions. NCPDP maintains these standards independently; they are used across networks and vendors well beyond any single network operator. For most payer-side architects, the implementation question is not whether you can reach NCPDP-capable endpoints -- it is whether your PA workflow logic and formulary management systems can support the proposed transaction types, data elements, and response times in a way that could meet CMS requirements if finalized. [verify: whether your current PBM or PA vendor contract covers CMS-0062-P NCPDP pathway obligations if finalized on the proposed timeline]

The architecture-relevant read on CMS-0062-P is therefore not that you can finalize the pharmacy-benefit side of your PA implementation today. It is that you should build the CMS-0057-F FHIR prior-authorization infrastructure required for non-drug items and services in a way that can be extended to medical-benefit drugs if CMS-0062-P is finalized. That means: interfaces between your PA decision engine and the transport layer rather than hard-coded pathway assumptions, benefit-classification logic exposed as a configurable and auditable decision point, and vendor contracts that allocate responsibility for supporting future CMS-0062-P requirements if the final rule adopts a comparable scope and timeline.

The Watch Item for the Final Rule

The most important thing to watch in a final rule is whether CMS changes the proposed split between medical-benefit FHIR and pharmacy-benefit NCPDP workflows, adds a required benefit-classification indicator, specifies a routing convention, or leaves classification to payer operations. Any of those outcomes affects interface design, auditability, and vendor responsibility.

Design for configurable routing and auditable benefit-classification logic. If the final rule adds a deterministic federal convention, it becomes a configuration update rather than an architecture rewrite.

For now: the CMS-0057-F APIs are the compliance sprint. CMS-0062-P is architecture-relevant but not compliance-final. Build the required layer clean and fast. Build the optional layer with the right interfaces. And monitor what CMS actually publishes, because the routing question is the one part of this implementation that cannot be fully resolved ahead of the final rule.