Skip to main content
Revenue cycle operating intelligence

See the work. See the owner. See the next action.

ASP-RCM turns the back office into a visible operating system. Every eligibility response, authorization risk, denial, payer delay, and follow-up action moves through a named work queue with a traceable outcome.

Request a working-session demo Explore the operating map
  • Synthetic demo data
  • Specialty controls
  • Named ownership
ASP-RCM Reporting Cloud Executive view
ASP-RCM Reporting Cloud revenue cycle dashboard showing collections trend, payer mix, A/R aging bands, and denial categories on demonstration data

Reporting Cloud executive view. The collections trend, payer mix, aging bands, and denial categories on this screen are demonstration data. No client is identified and no patient data appears.

What sits behind the screen

Data in, controls applied, decisions out.

The command center is not another database. It reads what your systems already emit, applies the controls, and produces surfaces a person can act on. Every box below is a real surface, and the honest limits are drawn in.

Exhibit 1 · Command center architectureSources, processing, decision surfaces
Revenue cycle command center architecture Source systems feed a processing layer that normalizes records, applies payer and coding rules, detects exceptions, assigns ownership, and captures evidence. The processing layer produces work queues, exception inboxes, payer intelligence, a leadership scorecard, and an action trail. SOURCES IN PROCESSING LAYER DECISION SURFACES OUT EHR and practice management Demographics, charges, notes Clearinghouse 837, 835, 277, 999 Payer portals and 270/271 Eligibility, status, appeals Bank and lockbox Deposits for cash reconciliation Client files and rosters Providers, contracts, fee schedules Normalize and resolve identity One patient, one claim, one balance Apply payer and coding rules Edits, scrubbing, specialty controls Detect the exception Threshold crossed, conflict, or gap Assign owner and due date Named person, not a shared inbox Capture evidence at every step Work queues Prioritized, owned, dated, closable Exception inboxes Only what a rule could not resolve Payer intelligence Response velocity, denial patterns Leadership scorecard Trend, variance, decisions, commitments Action trail Who did what, when, and the outcome The command center does not replace the source systems. It reads them, applies controls, and hands a person something they can close.
Nothing in this diagram writes clinical content back to a chart. Write-back to a source system happens only where the vendor supports it and the operating agreement authorizes it, and it is scoped in writing before go-live.

The integration surface, drawn honestly

Integration diagrams usually show four clean pipes. Three of these are real interfaces. One of them is a person with a login, and pretending otherwise is how implementation timelines slip.

Exhibit 2 · Integration surface mapConnection type per surface, limits included
Integration surface map for the revenue cycle command center The command center connects to EHR and practice management systems by API or batch file, to the clearinghouse by X12 EDI transactions, to banking by read-only deposit file, and to payer portals through a credentialed human session because most payers expose no API. EHR and practice management Read access, a scheduled extract, or a vendor API where one exists. Write-back is the exception, not the rule, and is scoped in writing. API OR BATCH FILE Clearinghouse Claim submission, acknowledgement, status, and remittance as standard transactions. This is the most standardized surface in the whole stack. X12 837 / 835 / 277 / 999 Payer portals Most payers expose no API for status detail, appeals, or enrollment. That work runs through a credentialed person in a browser, logged by hand. STAFFED PORTAL SESSION Banking and lockbox Deposit and lockbox detail so posted cash can be reconciled against remittance. Access is read only and no payment is initiated from here. READ-ONLY FILE ASP-RCM command center CONTROLS, QUEUES, EVIDENCE Any surface that turns out to be a staffed session rather than an interface is a staffing line in the operating agreement, not a hidden assumption.
Connection types vary by vendor, payer, and contract. The map above describes the categories the command center supports. Which specific interface applies to your systems is confirmed during the Days 1 to 30 baseline, not assumed at proposal.
One connected operating map

Ten stations. One revenue truth.

Each station has an input, a control, an owner, an exception queue, and an output. Leaders can see where revenue is moving and where it is waiting.

01 / FRONT DOOR

Eligibility and VOB

Coverage, benefits, limitations, patient responsibility, and source evidence.

Evidence attached
02 / CONTROL

Authorization

Units, dates, visits, rendering rules, utilization, and renewal lead time.

Burn-down visible
03 / ACCESS

Credentialing

Enrollment status, rosters, effective dates, payer follow-up, and expirables.

Owner assigned
04 / INTAKE

Charge capture

Document-to-charge completeness, coding signals, and missing encounter follow-up.

Exceptions queued
05 / CLEAN CLAIM

Claim edits

Payer-specific rules, scrubber findings, clearinghouse rejections, and corrections.

Rule fired
06 / CASH

Payment posting

ERA and EOB reconciliation, underpayments, takebacks, and unapplied cash.

Variance tracked
07 / DEFENSE

Denials and appeals

Root cause, preventability, appeal evidence, escalation, and feedback to the source.

Cause classified
08 / RECOVERY

A/R follow-up

Payer velocity, claim aging, next-action date, worklog, and outcome evidence.

Action dated
09 / EXPERIENCE

Patient billing

Statements, estimates, inquiries, payment plans, and responsibility changes.

Touchpoint logged
10 / GOVERNANCE

Reporting

CFO scorecard, operating trends, decisions, commitments, and monthly governance.

Decision recorded

Where the claim actually goes, and who touches it

Automation is not evenly distributed across a claim's life. Some stages are pure rule execution. Some are judgment work that should never be automated. The map below marks which is which, and names the exception queue each stage feeds when the control fires.

Exhibit 3 · Claim lifecycle, automation mode and exception queueEight stages from coverage to recovery
Claim lifecycle with automation mode and exception queue per stage Eligibility, charge capture, claim edits, submission, and remittance are rule-driven stages. Authorization is machine-assisted with human review. Coding and denial and A/R work are human-led. Each stage feeds a named exception queue. STAGE MODE EXCEPTION QUEUE Eligibility and VOB Authorization Charge capture Coding Claim edits Submission Remittance Denial and A/R RULE-DRIVEN ASSISTED RULE-DRIVEN HUMAN-LED RULE-DRIVEN RULE-DRIVEN RULE-DRIVEN HUMAN-LED Coverage conflict Units low or expiring Missing encounter Query to provider Edit fails twice Rejected at the gateway Underpaid or takeback No next action set Rule-driven means the control executes and only the failures surface. Assisted means a machine prepares the work and a person decides. Human-led means a person does the work with tooling support. Coding and A/R judgment stay human-led by design, not by lack of capability. MODE IS A DESIGN CHOICE PER CLIENT AND IS SET IN THE OPERATING AGREEMENT
The modes above describe how ASP-RCM configures the stages, not a claim that every client runs every stage the same way. Scope is agreed during the baseline and written into the operating agreement.

What reaches a human, and why it got there

An exception queue that receives everything is a worklist with extra steps. The routing below is what keeps the human inbox small enough to actually clear, and every path out of it is recorded either way.

Exhibit 4 · Exception routingThree gates between a signal and a person
Exception routing from a detected signal to a human queue A detected signal passes three gates. If a deterministic rule covers it the system corrects and logs it with no human touch. If the payer response is ambiguous or conflicting it routes to a named human. If it crosses a dollar or deadline threshold it enters a priority human queue. Anything else stays in a monitored queue. Signal detected THRESHOLD CROSSED NO NO NO YES YES YES Does a deterministic rule cover this with a known fix? GATE 1 Is the payer response ambiguous or conflicting? GATE 2 Does it cross a dollar or a filing deadline threshold? GATE 3 Corrected and logged No human touch. The rule that fired and the result are recorded. Routed to a named human Judgment required. A machine cannot resolve a contradiction. Priority human queue Ranked above routine work by balance at risk or days remaining. EVERY HUMAN-ROUTED ITEM CARRIES The signal that triggered it The evidence already gathered The rules that were tried first A named owner and a due date An escalation path if it stalls AN ALERT WITHOUT THESE IS NOT ROUTED Monitored queue Held under an ageing rule rather than assigned, and escalated if it recurs.
Gate thresholds are configured per client. The structure is fixed: a rule gets first attempt, a contradiction always reaches a person, and nothing sits in a queue without either an owner or an ageing rule attached to it.
Product evidence

A workbench for the signal that needs action.

Switch views to see how the same operating model adapts across reporting, ABA, HCC, verification, credentialing, and A/R execution.

Reporting CloudExecutive control
Revenue cycle KPI dashboard showing collections, payer performance, A/R aging, and denial trend panels on demonstration data

Reporting Cloud, executive control viewThe panels shown are collections trend, payer scorecard, A/R aging distribution, and denial category mix. Values are demonstration data. No client is identified.

From metrics to decisions

See revenue, A/R, payer, denial, and productivity signals in the same governance view.

  1. Trend by payer, location, provider, and service line
  2. Connect every metric to an accountable work queue
  3. Carry decisions and commitments into monthly governance

All six product views above are real screens from the ASP-RCM platform, populated with demonstration data. No client is identified, no patient data appears, and the exact layout varies by configuration.

Specialty control maps

Every specialty has a different money map.

A generic dashboard cannot explain where specialty revenue is created, delayed, reduced, or denied. The command center follows the real control chain.

ABAApplied behavior analysis

Authorization integrity

Rendered care stays aligned to approved units, documentation, supervision, and billed services.

Primary revenue exception

A session exists, but the authorization, note, or billed units do not agree.

  1. 01 / INPUTApproved units
  2. 02 / EVIDENCESession and note
  3. 03 / CONTROLThree-way match
  4. 04 / OUTPUTClean claim
BH + SUDBehavioral health and SUD

Level-of-care control

Clinical status, utilization review, authorization, confidentiality, and payer rules move together.

Primary revenue exception

The level of care or authorized days change before billing and review data are aligned.

  1. 01 / INPUTAssessment
  2. 02 / CLINICALLevel of care
  3. 03 / CONTROLUR and authorization
  4. 04 / OUTPUTClaim evidence
HospiceHospice revenue cycle

Election-to-payment chain

Election, notice, certification, level of care, location, and benefit period shape the claim.

Primary revenue exception

A date, setting, certification, or notice breaks the Medicare claim sequence.

  1. 01 / INTAKEElection and NOE
  2. 02 / EVIDENCECertification
  3. 03 / CONTROLLevel of care
  4. 04 / OUTPUTClaim and cap
DentalDental revenue cycle

Production-to-cash bridge

Procedure, benefit, fee schedule, downgrade, adjustment, claim, and collection stay reconciled.

Primary revenue exception

Production appears strong while contractual adjustments and payer downgrades erode net revenue.

  1. 01 / INPUTProduction
  2. 02 / CONTRACTPPO rules
  3. 03 / CONTROLAdjustments
  4. 04 / OUTPUTNet cash
HCCRisk adjustment

Evidence governance

Source evidence, extraction, diagnosis mapping, model-year logic, and human review remain traceable.

Primary evidence exception

A suspected condition lacks sufficient source evidence or reviewer approval.

  1. 01 / INPUTSource record
  2. 02 / MODELExtraction
  3. 03 / CONTROLHuman review
  4. 04 / OUTPUTAudit trail
PT / OT / SLPRehabilitation therapy

Plan-of-care alignment

Evaluation, plan of care, timed units, modifiers, certification, and billed services stay connected.

Primary revenue exception

Documentation time, plan status, and units do not support the submitted service.

  1. 01 / INPUTEvaluation
  2. 02 / EVIDENCEPlan of care
  3. 03 / CONTROLTimed units
  4. 04 / OUTPUTClean claim
Closed-loop intelligence

A dashboard should trigger work.

The operating loop converts a signal into a dated action, records the outcome, and pushes the lesson back to the source. That is how recurring denials become preventable controls.

01 / DETECTSignalA metric, denial, payer delay, authorization risk, or data conflict crosses its control threshold.
02 / DECIDEPriorityBusiness value, age, recurrence, deadline, and preventability determine the queue position.
03 / ACTWorklogA named owner receives the next action, evidence requirement, due date, and escalation path.
04 / LEARNControlThe outcome updates the rule, training, payer matrix, workflow, or client-side input process.
Metric model and data honesty

Which number moves when a queue gets cleared.

A scorecard is only useful if a leader can trace a headline number down to the work that changes it. These two exhibits show the rollup, and then show how fresh each input actually is before anyone reads it.

Exhibit 5 · KPI hierarchy and rollupHeadline metric to operating driver
KPI hierarchy showing which operating metrics roll up into which headline metric Net revenue realized rolls up from clean claim rate, denial and appeal yield, and A/R velocity. Each of those rolls up from three operating drivers that a work queue can move directly. Net revenue realized THE ONLY NUMBER THAT CLOSES THE LOOP Clean claim rate GETS PAID THE FIRST TIME Denial and appeal yield RECOVERS WHAT WAS REFUSED A/R velocity HOW LONG CASH SITS OUT Eligibility verified before service Authorization on file and not expired Coding and scrubber edit pass rate First-pass denial rate by payer Appeal overturn rate by denial cause Share of denials classed preventable Days in A/R Percent of A/R aged over 90 days Payer response days, measured not quoted The bottom row is the only row a work queue can move directly. Everything above it is arithmetic on the bottom row, which is why a scorecard with no drill-down is a scorecard nobody can act on.
Metric definitions are agreed in writing during the Days 1 to 30 baseline, because the same metric name means different things in different practice management systems. A definition that changes mid-engagement invalidates the trend.

How fresh the numbers on the screen actually are

Refresh cadence is bounded by the slowest thing upstream, not by how often a dashboard redraws. A screen that repaints every minute on a feed that lands once a day looks live without being current.

Exhibit 6 · Data freshness by feedLatency is set by the source, not the dashboard
Data freshness and refresh cadence by feed Eligibility checks return on request in near real time. Claim submission follows the clearinghouse batch window. Claim status and remittance arrive on payer and clearinghouse schedules. Payer portal status requires a staffed pull. Dashboards rebuild only after the last upstream feed lands. FEED TYPICAL LATENCY WINDOW CADENCE real time intraday daily on delivery Eligibility check, 270 and 271 ON REQUEST Claim submission, 837 BATCH WINDOW Claim status, 277 PAYER DEFINED Payer portal status, no EDI available STAFFED PULL Remittance, 835 AS RELEASED Bank and lockbox deposit file PER BANK FILE Dashboards and scorecards AFTER LAST FEED Bar positions show the window a feed typically lands in, not a guaranteed service level. Every view carries the timestamp of the data behind it, so a reader can tell how old the screen in front of them is.
Actual cadence is a property of your payers, clearinghouse, bank, and source-system vendor. It is measured during the baseline and stated as a fact in the operating agreement rather than promised in advance.
Operating contract

Clear ownership before go-live.

The command center reflects the operating agreement. Every task has a party, handoff, due date, escalation route, and evidence requirement.

ASP-RCM owns

  • Revenue-cycle work queues and daily execution
  • Claim edits, denial classification, appeals, and A/R action trails
  • Payer follow-up evidence and escalation discipline
  • Monthly performance narrative, decisions, and commitments

Your team enables

  • Timely access to source systems and payer portals
  • Complete demographic, clinical, and provider inputs
  • Named decision owners for policy and clinical questions
  • Fast resolution of exceptions that require provider action
Controlled transition

A visible 30-60-90 day path to control.

Implementation is an operating transition with checkpoints. Baseline first, then controlled execution, then written steady-state governance.

Baseline and map

Confirm inventory, payer access, interfaces, current A/R, denial taxonomy, specialty controls, ownership, and reporting definitions.

Run and reconcile

Activate priority work queues, validate outputs, reconcile cash and exceptions, and establish operating cadence with visible actions.

Govern and improve

Move to written service levels, CFO scorecards, root-cause controls, monthly governance, and an agreed improvement backlog.

Bring one payer problem. Leave with an operating map.

In a focused working session, we will map the signal, owner, evidence, next action, and leadership view for one real revenue-cycle constraint.

Book the working session