Prior authorization between provider and payer agents

How it works today

United States

A clinician orders an item or service. Someone on staff checks whether the patient’s plan needs prior authorization, what documentation it wants, and how to submit. Submission happens through a payer portal, by fax or phone, or as an X12 278 (Health Care Services Review Information), which is the HIPAA-adopted standard for referral certification and authorization, version 5010. The payer may pend the request for more records, then approves or denies.

The CMS Interoperability and Prior Authorization final rule (CMS-0057-F) changes this for a defined set of payers. CMS released it on 17 January 2024, and it was published in the Federal Register on 8 February 2024. It applies to Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the federally facilitated exchanges. Its dates, as CMS states them:

Requirement	Compliance date (generally)
Decisions within 72 hours for expedited and 7 calendar days for standard requests (not QHP issuers on the exchanges)	1 January 2026
A specific reason for every denial	1 January 2026
Public reporting of prior authorization metrics	Annually; first set due 31 March 2026
Prior Authorization API (FHIR) for items and services, excluding drugs	1 January 2027
Provider Access API and Payer-to-Payer API	1 January 2027

The Prior Authorization API must list covered items and services, identify documentation requirements, accept a request, and return approval (with its end date or circumstance), denial (with a specific reason) or a request for more information. CMS recommends three HL7 Da Vinci implementation guides:

• Coverage Requirements Discovery (CRD) lets the payer tell the provider, at the point of care, whether an order is covered and needs prior authorization. It runs as a CDS Hooks service on hooks including order-sign, order-select, order-dispatch, appointment-book, encounter-start and encounter-discharge.
• Documentation Templates and Rules (DTR) expresses the payer’s documentation rules as FHIR Questionnaires with CQL logic, pre-filled from the EHR in a SMART app or natively, and saved as a QuestionnaireResponse.
• Prior Authorization Support (PAS) submits the request from the EHR with $submit, checks status with $inquire, supports pended responses and subscriptions, and maps to the X12 278 through an intermediary that converts between FHIR and X12.

CMS announced HIPAA enforcement discretion for the X12 278 when a payer implements an all-FHIR Prior Authorization API. The current published guides are CRD 2.2.1, DTR 2.2.0 and PAS 2.2.1, all dated 27 March 2026. The rule itself recommends CRD 2.0.1, DTR 2.0.0 and PAS 2.0.1.

On 10 April 2026 CMS released a proposed rule, CMS-0062-P. It would bring drugs covered under a medical benefit into the Prior Authorization API, require Medicaid, CHIP and exchange QHP issuers to support the NCPDP SCRIPT, Formulary and Benefit, and Real-Time Prescription Benefit standards for pharmacy-benefit drugs, and shorten drug decision timeframes, with a proposed compliance date of 1 October 2027. As of 26 September 2026, CMS lists it as a proposed rule.

Canada

The Canada Health Act lists insured services as medically necessary hospital, physician and certain surgical-dental services, and ties federal Canada Health Transfer payments to provinces and territories meeting its conditions. Public drug coverage outside those services is provincial, so prior approval rules differ by province. Ontario’s Exceptional Access Program, which covers drugs not funded on the Ontario Drug Benefit Formulary, is a typical example. Physicians and nurse practitioners submit requests for unfunded drugs through the SADIE online portal, by fax, by mail, or for selected drugs through a Telephone Request Service. Each request carries patient, prescriber, drug and clinical details. Ontario publishes target turnaround times by priority and notes that fax and mail take longer than SADIE.

The agent-to-agent version

The FHIR APIs are the regulated channel in the US, so a provider’s agent would use CRD, DTR and PAS as tools. Agent-to-agent messaging sits around them: status, pended requests, missing documents and scheduling a peer-to-peer review.

Illustrative. A payer’s agent answers a provider’s agent about a pended request, in A2A v1.0 shapes:

{
  "id": "task-pa-20931",
  "contextId": "ctx-case-4471",
  "status": {
    "state": "TASK_STATE_INPUT_REQUIRED",
    "timestamp": "2026-10-07T15:12:00Z",
    "message": {
      "messageId": "msg-pa-20931-03",
      "taskId": "task-pa-20931",
      "contextId": "ctx-case-4471",
      "role": "ROLE_AGENT",
      "parts": [
        { "text": "Request pended. Please send the imaging report and the dates of the completed physical therapy course." },
        {
          "data": {
            "priorAuthRequestId": "PA-20931",
            "decision": "pended",
            "documentationNeeded": ["imaging-report", "therapy-dates"]
          },
          "mediaType": "application/json"
        }
      ]
    }
  }
}

The provider’s agent gathers the records, a staff member or clinician confirms them, and the agent replies on the same taskId. The payer’s agent completes the task with the decision as an artifact: approval with its end date, or denial with the specific reason CMS now requires.

What has to be true

Identity. The payer must know which provider organization the agent represents and that it has a treatment relationship with the patient. The provider must know it reached the payer’s real agent before sending health information.

Authority. An agent can assemble documentation. Clinical statements still belong to a clinician, and DTR is built around clinicians supplying the information the EHR cannot fill in. The agent’s credential should be scoped to one case. A2A signals the need for more authority with TASK_STATE_AUTH_REQUIRED but leaves the credential undefined (section 7.6.4).

Privacy. Under HIPAA, a vendor that handles protected health information for a provider or payer is a business associate and needs a contract with the provisions HHS lists, including safeguards, breach reporting and subcontractor flow-down. In Ontario, the Personal Health Information Protection Act already defines an “agent” as someone acting for a health information custodian with its authorization, and the custodian stays responsible for what its agents do.

Record. Timeframes, denial reasons and published metrics all depend on accurate timestamps and a complete exchange history on both sides.

Where Emissar fits

None of Emissar’s modules is built for health data today. Any use with protected health information would need a business associate agreement first. The concepts that would apply:

• Verify (In development): confirming which organization’s agent is calling.
• Mandate (Spec in progress): a credential scoped to one case and one action.
• Ledger (Spec in progress): a signed record of each request, pend and decision.
• Handoff (In development): routing peer-to-peer reviews and clinical questions to people.

Open questions

• Will payers publish A2A agents beside their FHIR Prior Authorization APIs, or will provider agents only call the FHIR APIs?
• How should retries and pended requests be recorded so both sides agree when the 72-hour or 7-day clock started?
• Which DTR answers must a clinician confirm personally before an agent submits them?
• What will the final version of CMS-0062-P require for drugs, and when?
• Would provincial programs such as Ontario’s accept structured submissions from agents, and under what agent rules in their health privacy laws?