Manual-pending workflow

Outcome

Authorizations for payers that do not accept electronic 278 are tracked in the platform end-to-end — staff capture the payer's portal decision in the same UI as electronic auths, with the same audit trail and the same materialization into service_authorization.

Prerequisites

A program configured with authorizationWorkflow = MANUAL_PENDING (set on the rcm-app side under Configuration → Payers → Programs). When set, new auth requests for the program are not submitted via 278; they park in a manual queue.

Why this exists

Many state Medicaid auth pathways still require a portal upload or a phone call. Forcing a 278 attempt against such a payer produces noise on both sides — the payer rejects with 999 IK3 or returns HCR01 = CT, and the operator has to chase the same auth through the portal anyway. MANUAL_PENDING skips the doomed 278 and routes the work straight to the manual queue.

Lifecycle

The status names align with the electronic 278 path so reports unify.

Where the work lives

The rcm-app /authorizations list filters by status; selecting MANUAL_PENDING produces the queue. From the EDI side, no /transactions rows are created for these auths — they exist only in the rcm-core auth tables.

Steps to work a manual auth

1. Open /authorizations?status=MANUAL_PENDING in the rcm-app. The queue shows auths waiting for portal submission, sorted by created-at ascending (oldest first).

2. Open the auth's detail page. The page shows what the clinician requested (codes, units, window, diagnosis) and prompts you with the right payer portal URL.

3. Submit through the payer portal with the auth's parameters. Capture the portal's confirmation reference.

4. Click Mark as portal-submitted on the auth detail. The dialog takes the portal reference, the date submitted, and (if the portal gave it) the immediate decision. Status moves to PORTAL_SUBMITTED.

5. When the payer returns a decision, click Record response. The dialog captures:

   • Decision: APPROVED / DENIED / PENDED.
   • Certification number (when approved).
   • Approved units / visits / window (when approved).
   • Reason / pend code (when denied or pended).
   • Any uploaded documents.

6. Status flips to match. The audit trail captures every step with operator + timestamp.

Why no 278 traffic

Programs in MANUAL_PENDING produce zero EDI traffic on the auth side. If you see an auth in MANUAL_PENDING with associated tx_type = 278 records, something is wrong:

• Most likely cause: program config was changed mid-flight, but the auth had already been routed to 278 before the change.
• Less likely: an incorrect routing rule is overriding the program- level workflow. Check the routing rules editor.

Steps to convert a program from MANUAL_PENDING to AUTOMATIC_278

When a payer adds 278 capability:

1. Confirm with the payer that 278 is in production for the program — not just available in test.

2. Add 278 outbound and 278 inbound capabilities on the relevant trading partner (2.4 — Capabilities).

3. Bind any companion guide the payer published for 278 (7.1).

4. Add a routing rule mapping tx_type = 278 + payer / program to the trading partner.

5. Run an end-to-end test with usageIndicator = T for one auth.

6. Switch the program's authorizationWorkflow to AUTOMATIC_278. New auth requests will route to 278; existing MANUAL_PENDING auths finish on the manual track.

Validation

Check	Expected
Auth in MANUAL_PENDING shows portal URL prompt	Yes.
Status flips on Record response	Yes.
Approved units land on service_authorization rows	Yes.
No tx_type = 278 records created for the auth	Correct.

Troubleshooting

Symptom	Cause	Fix
Manual queue is unexpectedly large	Program flipped to MANUAL_PENDING accidentally, or 278 partner went down and routing rules cascaded	Check program config; check routing rule history.
Mark as portal-submitted is greyed	Missing scope (clinical.authorization.write) or auth is not in MANUAL_PENDING	Check status; check scopes.
Operator submitted to portal but cannot find the auth in the queue later	Filter excludes PORTAL_SUBMITTED	Toggle the status filter.
Re-submitted to portal after a PENDED returns no new decision	Payer's pend window is long	Set a follow-up reminder; the status stays PORTAL_SUBMITTED.

Next

6.1 — 835 inbound