Home / Platform / Task Management

Module 09 · Unified work queues

The operational nervous system of the practice.

Every denial, renewal, co-sign, and payer call lands as a FHIR Task in one queue — with an SLA, an owner, and a next step. Nothing falls through.

The signature mechanic

One inbox in. Skills-based routing out. SLA lanes underneath.

Every follow-up event — from any module — becomes a FHIR Task, then routes by required skill to the right worker and drops into a priority lane with its own SLA clock. A task that ages out doesn't get lost; it escalates with an audit-logged event.

Unified FHIR Task queue with skills-based routing and SLA priority lanes Work events from several modules feed one unified FHIR Task intake, which routes by required skill to four workers, and each task lands in one of three SLA priority lanes — urgent, standard, and routine — with a clock. Overdue tasks escalate to the practice manager. WORK EVENTS (every module) Denial (835 posting) Rx renewal Referral co-sign ePA decision Patient message FHIR Task status · priority · owner · period SKILLS-BASED ROUTING → WORKER Senior biller — appealsskill: medical-necessity, workers-comp Front-desk lead — renewalsskill: standing-order refills Dr. M — co-sign / ePAskill: prescriber authority RN triage — messagesskill: clinical triage SLA PRIORITY LANES URGENT Medical-necessity denial · appeal window 14d STANDARD RxRenewal · SLA 2 business hours ROUTINE Non-urgent patient message · SLA 1 business day Aged past SLA → auto-escalate to practice manager Overdue badge · SMS alert · escalation written to TaskStatusHistory — the appeal window never closes silently 100% of denials become a FHIR Task within one minute of remittance posting. For CMS-0057-F payers, the same Task model consumes the Provider Access API — replacing manual portal logins.

Tasks are FHIR R4 Task resources — status, intent, priority, owner, period — and the AI next-best-action engine weighs task type, denial reason, the payer's historical appeal-success rate, and elapsed time before suggesting “file appeal,” “request peer-to-peer,” or “collect records.”

The problem

Billing follow-up runs on spreadsheets, sticky notes, and one person's memory.

Denials sit until someone remembers them. Payer calls go undocumented — no record of who was spoken to or what was promised. When the one person who knows the Blue Cross appeals process takes a vacation, that queue stalls. Appeal windows close silently, and the revenue is gone for good.

Every action gets a task. Every task gets a clock.

A denied claim becomes a FHIR Task within one minute of the 835 posting — carrying the CARC/RARC reason code, the appeal-window deadline, and an AI-suggested next action. Tasks that age past their SLA auto-escalate to the practice manager with an audit-logged escalation event. Structured process replaces tribal knowledge.

AI that knows the payer's habits

The next-best-action engine weighs the task type, the denial reason, the payer's historical appeal-success rates, and elapsed time. “Request peer-to-peer review — this payer overturns 68% of CARC 29 denials on peer review.” The biller accepts, modifies, or dismisses; either way, the decision is logged and the model learns.

Key capabilities

One queue. Every follow-up. Zero tribal knowledge.

Unified work queue

Denials, follow-ups, co-signs, renewals, referral authorizations, and PA decisions in a single surface with role, type, priority, SLA, and assignee views. Loads in under two seconds.

SLA auto-escalation

Tasks exceeding 30 days in an active state escalate to the practice manager with an Overdue badge and an SMS alert. Rules configurable per task type; every escalation audited.

AI next-best-action

File appeal, call payer, request peer-to-peer, collect records — suggested per task from the denial code, payer history, and elapsed time.

FHIR Task native

Tasks are FHIR R4 Task resources — status, intent, priority, owner, period — enabling payer interoperability through the CMS-0057-F Provider Access API.

Skills-based routing

The workers'-comp denial goes to the biller tagged with that skill; complex appeals reach senior staff; routine follow-ups land on whoever's available.

Appeal macros

Letter templates auto-populated with diagnosis codes, the procedure in question, clinical rationale from the chart, and the payer's own coverage criteria. Twenty minutes of drafting becomes three.

Payer call logging

Outbound calls log automatically with caller ID, duration, and outcome summary; SMS and email follow-ups capture with timestamps. No more undocumented payer interactions.

Provider Access API consumer

For CMS-0057-F-compliant payers, PA status and adjudication details pull through the API — replacing manual portal logins and status-check calls.

Time tracking & analytics

Time per task, per biller, per task type — feeding a real-time dashboard of queue depth, SLA compliance, aging, and AI acceptance rates.

Workflow

A denial's path through the queue.

835 posts; the task exists

Within a minute, the denial is a FHIR Task with its CARC code, appeal deadline, and a suggested action.

Routed by skill

It's a medical-necessity denial requiring clinical narrative — routing sends it to the biller with that specialty, not the general pile.

Macro drafts the appeal

The Level II appeal letter pre-populates with diagnosis codes, clinical rationale from the chart, and the payer's own coverage criteria. Review, send.

The payer call is logged

The status-check call records caller, duration, and outcome on the task. The payer asks for more documents — a sub-task spawns for collection.

Resolved — or escalated, never lost

First-appeal resolution target is 65%. Anything aging out escalates with a full audit trail. The appeal window never closes silently.

Who benefits

Billing manager

Owns the denial queue with SLA compliance, escalations, and payer logs in one dashboard — and macros for the letters.

Prescriber

Co-signs, renewals, and PA decisions arrive in the same queue as everything else — one-click resolution from the chart or the queue.

RN / MA

Renewal processing under standing orders, referral follow-ups, and record collection for appeals — filtered to “my tasks only.”

Practice manager

Sees queue depth, aging, and productivity in real time; receives escalations before deadlines, not after write-offs.

100% of denials become tasks within one minute of remittance posting. Unworked denials are silent revenue loss — in rev.health, “silent” isn't possible.

Performance targets

The numbers this module is built to hit.

MetricTarget
Denials creating a FHIR Task within 1 minute of posting100%
Tasks resolved within SLA≥ 95%
Outbound payer calls / emails / SMS logged on the task100% — zero tolerance
AI next-best-action acceptance≥ 60%
Appeal letters generated via macro≥ 70%
Auto-escalations accepted by the practice manager≥ 90%
Routed tasks accepted without reassignment≥ 85%
Full work-queue load time, any role≤ 2 seconds

Standards & interoperability

A queue payers can talk to.

FHIR R4 Task CMS-0057-F Provider Access API CARC / RARC denial codes Skills-based routing SLA priority lanes TaskStatusHistory audit Surescripts renewal write-back

Because tasks are standard FHIR Task resources, the queue interoperates with CMS-0057-F payer APIs rather than living in a proprietary silo — prior-auth status and adjudication detail pull through the Provider Access API instead of a manual portal login.

Nothing falls through. Ever.

SLA clocks, auto-escalation, and AI guidance on every piece of follow-up work.

Join the waitlist