Skip to main content

278 prior authorization operator playbook

Outcome​

Failed 278 service review requests get re-queued; manually-resolved auths are recorded; the lifecycle from DRAFT → SUBMITTED → APPROVED is observable end to end.

Prerequisites​

Lifecycle in one diagram​

Re-queue a failed 278​

A failed submit leaves the row in DRAFT with an auth.request_failed event on the bus.

  1. Confirm the failure and find the correlation:

    SELECT auth_request_id, status, trace_number, payer_id
    FROM service.authorization_request
    WHERE auth_request_id = :id;

    SELECT edi_tx_id, tx_type, direction, error_details
    FROM billing.edi_transaction
    WHERE correlation_id = :auth_request_id
    ORDER BY created_at DESC
    LIMIT 5;

  2. Identify the root cause from error_details. Common ones:

    error_details excerptCauseFix
    No routing rule foundMissing submission_routing_rule for tx_type='278'Add a 278 routing rule for the payer.
    Control number contentionTransient ISA/GS/ST allocation raceRe-queue; the retry resolves it.
    Payer snapshot incompleteUMO record missing required identifiersFix the payer record per 2.1.

  3. Re-queue through the admin endpoint:

    curl -X POST "$EDI_GATEWAY_URL/edi/admin/auth-requests/$AUTH_REQUEST_ID/requeue"

    The consumer is idempotent by design — a request in SUBMITTED status is not double-submitted; instead the requeue raises an error if the request has moved past DRAFT.

  4. Only flip back to DRAFT if the original interchange was rejected (TA1 / 999 negative). Do not re-DRAFT an accepted but pended request — you'd lose the audit trail and the payer would see a duplicate.

    UPDATE service.authorization_request
    SET status = 'DRAFT', submitted_x12 = NULL, submitted_at = NULL
    WHERE auth_request_id = :id AND status = 'SUBMITTED';
    -- Use this only after confirming TA1/999 rejection.

Close a pended 278 manually​

Payers sometimes pend a request for information and never respond. When the clinical info has been delivered out-of-band (fax / portal / phone) and an approval arrived outside EDI:

  1. Cancel the 278 request through the service (do NOT just flip status — you'd skip audit bookkeeping):

    curl -X POST "$RCM_CORE_URL/api/v1/auth-requests/$AUTH_REQUEST_ID/cancel" \
      -H "Authorization: Bearer $JWT" \
      -H "Content-Type: application/json"

  2. Create the manual auth via REST so downstream scrubbing stages see it:

    curl -X POST "$RCM_CORE_URL/api/v1/authorizations" \
      -H "Authorization: Bearer $JWT" \
      -H "Content-Type: application/json" \
      -d '{
        "memberId": "...",
        "payerId": "...",
        "authorizationNumber": "MANUAL-2026-0001",
        "authorizationType": "UNIT",
        "approvedUnits": 120,
        "unitType": "UNIT",
        "effectiveFrom": "2026-06-01",
        "effectiveTo": "2026-11-30",
        "source": "MANUAL_INTAKE",
        "notes": "Payer approved via portal 2026-05-30; pended 278 cancelled."
      }'

  3. Leave an audit note on the original request describing the manual resolution so future reconciliation sees why no 278 response landed.

Validation​

CheckExpected
service.authorization_request.statusSUBMITTED after requeue, CANCELLED after manual cancel
billing.edi_transaction for the requestNew outbound row after requeue
service.service_authorization rowMaterialized on APPROVED/PARTIAL/MODIFIED, with correct source
Audit logAUTH_REQUEST_REQUEUED or AUTH_REQUEST_CANCELLED entry

Known limits​

  • Batch 278 only. Real-time 278 over CAQH CORE (SOAP/REST) is a payer-specific extension, not yet shipped.
  • No attachment support. 275 / PWK rides its own transaction family — payers requiring clinical documentation alongside the 278 still need manual follow-up via portal or fax.
  • Response-poller not extended. Pended 278 responses do not auto-retry; the 271/277 poller pattern will be applied in a follow-up once operational signals confirm the need.

Cross-references​

Next​

2.5 — Submission routing rules