RCM & insurance

Configure queue ownership and complete a local case follow-up

Use actual work-queue readbacks with supported API creation, owner changes and task completion while preserving unsourced silence-window and unsupported routing limits.

15 min read · Source baseline f6e9f05f

Verification and applicability

Normal queue create201/update200 and case task create/complete200, independent database records, actual wide UI and guarded400/409 outcomes

Check your installed version, permissions and local configuration.

Before you begin

All records are explicitly fictional local training. Current Work Queues UI displays governance and review items but has no queue-create/edit or manual-task form; those writes require an authorized supported API handoff.
Exact facility, existing named owner, established aging instrument/basis, escalation and outage procedures must be supplied. The photographed local five-day example is arbitrary authored training, not a regulated or payer deadline.

1. Read the queue’s four operational responsibilities

Open Revenue Cycle → Work Queues → Queues. Match queue key, then read named owner, aging policy, escalation path and behavior when upstream is unavailable. The actual example is kb_fictional_local_followup, with existing Synthetic Clinic Administrator and coding role. Its displayed aging instrument explicitly says authored arbitrary local teaching window, not regulatory/payer. Read5calendar days from receipt of claims literally; this is not a no-response or appeal window. Refresh re-reads current configuration.

**Read saved named owner, local aging, escalation and outage plan · 2026-10-18**Recorded baseline screen · 1728 × 921
Capture details
Actual original wide Chrome capture; local fictional queue. Normal API creation and PATCH saved this explicitly fictional nonprotocol queue. Actual UI shows Synthetic Clinic Administrator, coding role, a separately named authored arbitrary5calendar-day rule, ordered escalation and retained-item outage instructions. No real regulated window or external protocol is asserted.
**Exact queue**: Match key and purpose.
**Named owner**: Existing Clinic administrator, plus coding role.
**Fictional aging basis**: 5calendar days from receipt of claims; authored local example only.
**Ordered escalation**: Two local steps.
**Outage instruction**: Retain item; no automated resend/deletion.
**Refresh**: Re-read saved server context.

2. Create and update a complete local queue through the supported API

An authorized administrator POSTs /api/v1/facility/{facilityId}/rcm/work_queues/ with queue_key, display_name, owner_role and/or owner_user, aging_policy_key, ordered escalation_path, documented outage_behaviour and the explicit protocol tri-states. The actual normal POST returned201 for this separate local queue with protocol_mandated=no and delete_on_read=no. A normal PATCH to its exact ID returned200 changing the person to the existing Clinic administrator and retaining the local owner role and outage instructions. This is ordinary queue configuration, not source-rule approval or publication. The current UI has no corresponding authoring controls.

3. Keep owner and raw-persistence refusals visible

Actual incomplete creation returned400 work_queue_incomplete naming missing owner, aging, escalation and outage procedure. Clearing both owner_role and owner_user returned400 and did not clear the saved owner. Setting delete_on_read=yes with persists_raw_payload_before_parse=no returned400. A delete-on-read queue needs durable raw payload retention before parsing; merely naming a queue does not implement that persistence. The photographed saved card remained unchanged after both refused PATCH requests. API refusal bodies are retained separately, not illustrated by invented UI dialogs.

4. Create a local follow-up for the exact case and save its completion

For an authorized case task, POST /api/v1/facility/{facilityId}/revenue_cycle/{caseId}/work_item/ with title, stage, work_type, priority, description and a genuine agreed due_at when known. Our normal request created a uniquely titled fictional follow-up and returned200 with its new ID. To complete that exact task, POST the same endpoint with id, status=completed and resolution containing the retained finding. Independent database readback confirmed completed_at, updated actor, exact resolution and the original task. Task creation has no idempotency key here: if the result is ambiguous, GET the exact case work_items before retrying. Do not create another task blindly.

**Distinguish selected queue from local manual case tasks · 2026-10-18**Recorded baseline screen · 1728 × 921
Capture details
Actual original wide Chrome capture; local fictional queue. Actual Review items shows no open items for the selected fictional queue. A separate ordinary case follow-up was created and completed through supported APIs, but current case task endpoint cannot set work_queue_key or assigned_to, so that manual task is not claimed as routed/assigned here.
**Review items**: Queue-scoped open-item readback.
**Exact selected queue**: Different queues have separate results.
**No open review items**: Not proof every case task is done.
**Routed reviews only**: Manual case task lacks supported queue routing input.

5. Do not confuse manual task completion with queue routing or case closure

The pinned case work_item create endpoint has no work_queue_key or assigned_to input and its update branch only changes status/resolution. The manual follow-up therefore remained unassigned and unbound to this queue; its completion is API/record evidence, not a claimed card in Review items. This current tab only lists open items routed to its chosen queue. A normal case transition to closed refused400 because back-office claim/remittance/denial/collection controls remained incomplete. Closing the checklist item did not close the case, adjudicate claims or settle money.

6. Handle the missing external silence window without inventing a ticket

Open Stuck transactions. Actual UI states The silence window is not established; the normal API returns409 because NphiesConfiguration.no_response_window_days is unresolved and no facility NPHIES configuration is recorded. No transaction can be called stuck until its real sourced window and state are established. Raising the regulated manual support ticket also requires genuine retained original bundle identity and the supported terminal policy; this exercise fabricated none. Keep external transport disabled and route the missing prerequisite to the responsible IT/configuration owner.

**Preserve the unestablished external silence-window guard · 2026-10-18**Recorded baseline screen · 1728 × 921
Capture details
Actual original wide Chrome capture; local fictional queue. Actual Stuck transactions tab refuses to classify anything as stuck because no sourced NPHIES no-response window is established. The ordinary API returns409 unresolved_value. No period, platform acknowledgement or ticket was fabricated.
**Stuck transactions tab**: Separate from local queue governance.
**Window unestablished**: No configured regulated period.
**No inferred default**: Stop and obtain actual source/configuration; no fake ticket.

Source evidence

References are pinned to the private MANSOQ source repository. Repository access is required to open these links.