Sending a prior authorization request does not finish the work. A payer may approve it, request more information, leave it pending for review, or deny it. The operational challenge is to turn each response into the right next action while preserving the exact decision, its source, and the link to the original request. This guide focuses on medical items and services within the scope of CMS-0057-F and on the response patterns described by HL7 Da Vinci PAS.

Read the response before assigning a case status

CMS describes three outcomes for responses through the Prior Authorization API: approval with the date or circumstance under which authorization ends, denial with a specific reason, or a request for additional information. PAS also describes responses that are pended while a payer completes review. An intake system should preserve the payer's actual response and then map it to an internal work state; a local queue label must not replace the source message.

Keep the request identifier, payer response identifier, patient and coverage context, requested service items, received timestamp, communication channel, and raw response together. Record decisions at the item level when a request contains multiple services. A single case-level 'approved' flag can conceal an item that remains unresolved.

  • Approved: record the authorized item, any payer reference, and the authorization end date or circumstance.
  • More information requested: capture each requested item, owner, due date, and approved submission channel.
  • Pended: retain the payer reference and schedule a status check without treating the case as approved.
  • Denied: preserve the specific reason and route it to a qualified reviewer for the appropriate next step.

Treat pended work as a monitored state

The current PAS implementation guide describes monitoring a pended request until a final decision is available. It includes a subscription mechanism and an inquiry operation for retrieving information about a prior submission. The practical design choice is to identify which system owns monitoring and how a later response reaches the ordering and performing teams.

A monitoring record should include the last status check, next check time, responsible team, payer contact or transaction reference, and any outstanding documentation. When a response changes, reconcile it to the original case before notifying users. If a notification cannot be matched safely, send it to an exception queue rather than creating a second apparent authorization.

Make additional-information requests specific

A request for more information should become a list of concrete evidence tasks, not a generic 'send records' reminder. Capture the payer's wording and classify the requested document or fact, such as a report, treatment history, or attestation. Link each candidate source in the chart to the task so a reviewer can confirm that it answers the question before release.

PAS identifies structured clinical data, attestation, and less-structured documents such as notes and diagnostic reports as possible supporting information. Record what was sent, by whom, when, and through which channel. If a requested fact is unavailable or contradictory, keep that uncertainty visible and escalate it to the right clinical or authorization owner.

Keep a denial reason intact and actionable

Under CMS-0057-F, beginning in 2026 impacted payers must provide a specific reason for a denied prior authorization decision for medical items and services, regardless of whether the request came through an API, portal, fax, phone, or another channel. The rule's prior authorization process provisions exclude drugs. CMS states that the Prior Authorization API requirements generally begin in 2027; teams should verify the current compliance date and payer applicability for their own context.

Store the reason as received, including any code and explanatory text. Then allow a reviewer to categorize the operational issue: missing information, policy mismatch, eligibility problem, or another payer-stated basis. Do not infer an appeal right, resubmission path, or clinical conclusion from a code alone. The next action depends on the actual notice, payer process, and qualified review.

  • Does the response identify the correct patient, plan, service, and request?
  • Is the denial reason specific enough to identify an evidence gap or policy question?
  • Is additional documentation available, and has an appropriate reviewer verified it?
  • Who owns communication with the ordering team and any performing provider?

Reconcile across channels and measure closure

Many organizations will receive decisions through more than one channel while electronic workflows mature. Use stable payer and local identifiers, record the channel and receipt time, and define a rule for conflicting or duplicate responses. Preserve the original messages and an event history so a later correction does not erase what users saw earlier.

A useful pilot measure is the share of submitted cases that reach a verified final state with a matched payer response. Also track time spent pended, aging of information requests, unmatched messages, and cases where a denial reason required manual clarification. These measures reveal whether the response workflow actually closes the loop for the care team.

Primary references