Revenue cycle
Revenue-integrity sentinel
Catches what leaks — uncharged supplies, under-coded encounters, denial risk — pre-bill.
The revenue-integrity sentinel watches every encounter as it moves through the RCM pipeline and finds the money that quietly drops out: a supply consumed but never charged, a diagnosis specific enough to recover adjRW but left under-coded, a claim that will bounce at the payor. It drafts the exact correction — a line item, a code, a fix — and hands it to a coder to accept, edit or reject. It never posts a charge or mutates a code on its own; every proposal is advisory by construction and logged with its full reasoning trace.
append-only · 34,205 SKUs · resolve_menu_price()
What it senses
The signals it watches for you
It reads across the systems you already run — on the medOS event substrate — and surfaces the issue while there is still time to act.
billable_ledger vs stock movements
Reconciles STOCK_ISSUE / STOCK_CONSUMPTION against billable_ledger via inventory_charge_leakage_v — supplies issued to a ward or consumed in OR that produced no charge line.
Coding worklist & CC/MCC capture
Reads coding_worklist and the coding-rules-engine output for encounters where a more specific ICD-10 or a captured complication would lift the DRG / adjRW.
Pre-bill validation alerts
Watches the validation stage for BLOCK and WARN flags from the rules engine before the claim batches — the denial that hasn't happened yet.
REP results & denial queue
Parses returned REP responses (D-case / P-case) and the denial queue to learn which charge lines and code patterns get rejected, then flags new claims that match.
Eligibility & authen codes
Cross-checks scheme eligibility and HIPData authen-code status per encounter — a missing or expired authen code that will sink an otherwise-clean claim.
No-show & lapsed bookings
Surfaces booked slots trending toward no-show so the yield can be recalled or backfilled before it is lost.
What it proposes
Drafted work, never an autonomous act
Each item lands in the Acknowledgement Inbox with its reasoning and a confidence score. Nothing is sent, charged or changed until a human accepts.
Charge-leakage correction
Add missing supply line — 2× arterial cannula (฿840) consumed on AN 24-0117, never charged; resolve_menu_price returns ฿420/unit.
Under-coding recovery
Re-specify principal Dx from I21.9 to I21.4 with documented STEMI; captures CC, lifts DRG and ~0.42 adjRW.
Pre-bill denial fix
Encounter VN 24-8842 will deny — authen code expired; verify via HIPData before the batch closes.
No-show yield recovery
3 cardiology slots Thu AM show no-show pattern (score 0.79) — propose recall outreach to backfill.
The loop
Sense → propose → approve → execute
Sense
Streams the RCM pipeline — billable_ledger, coding_worklist, validation alerts, REP/denial queue, eligibility — and reconciles consumption against captured charges.
Propose
Drafts the precise correction — a missing line, a specific code, an authen-code check — with a priced amount, a recoverable-value estimate, a confidence score and the reasoning behind it.
Approve
The proposal lands in the coder's Acknowledgement Inbox alongside the encounter; a human accepts, edits or rejects — and that disposition is logged as the training signal.
Execute
On accept, the correction posts through the same coder and charge-capture endpoints staff already use — into the ledger and onto the claim, no shadow write path.
Capabilities
What it can do
Charge-leakage detection
Joins consumption to the chargemaster through resolve_menu_price() and inventory_charge_leakage_v to find every consumed-but-uncharged item, priced and ready to post.
Under-coding recovery
Compares assigned codes against documentation and CC/MCC capture rules to draft a more specific, better-reimbursing code — advisory, never an auto-mutation.
Pre-bill denial prevention
Reads validation BLOCK/WARN alerts and prior REP denial patterns to flag a claim likely to be rejected while a coder can still fix it, not after.
Eligibility & authen-code guard
Verifies scheme eligibility and authen-code status per encounter so claims don't batch with a defect that guarantees a denial.
No-show yield protection
Scores bookings drifting toward no-show and proposes recall or backfill so the slot's revenue is recovered in time.
Revenue-at-risk triage
Ranks the backlog by recoverable amount so coders work the highest-value corrections first instead of the queue top-down.
Learns from every disposition
Each accept, edit or reject is the training signal — what coders fix, override or ignore tunes which leaks the agent surfaces next.
Not a black box
Why it is safe to run
Autonomy without guardrails is a liability in a hospital. These are the constraints that make this agent safe to put to work.
Advisory by construction
The optimization engine suggests; it never auto-changes a code or posts a charge. Per the engine's own design rule, all corrections route to the coder for accept/reject — there is no hands-free path.
Operational plane only
The sentinel reads ledgers, codes, claims and queues — financial and operational data. It is scoped at the database-grant level; it does not author or alter the clinical record.
Audited per decision
Every proposal and disposition is written to rcm_ai_suggestion_log / the audit log under a named agent identity with its full reasoning trace — fully reconstructable at claim-review time.
On-box inference optional
Code and charge reasoning can run on Ollama on your own hardware, so PHI in encounter and claim data never has to leave the building, including air-gapped sites.
Data plane
It runs on the Operational plane — ledgers, codes, claims and queues only — with isolation enforced at the database grant level, so it can reconcile charges and recover codes but cannot author or alter the clinical chart.
Operating characteristics
What changes when it runs
Catches leakage before the claim
Flags the missing line and the denial risk while a coder can still fix it
Always-on backlog
Works the coding and reconciliation queue continuously; staff work exceptions
No hands-free charge or code change
Every correction is accept/edit/reject by a human coder
Charge-level reconciliation
Reasons at the individual ledger line, not just statement totals
Works on your stack
Reads and writes where you already work
On accept, it calls the very same endpoints your staff use — no shadow write path, no second source of truth.
Questions
Frequently asked
Can it change a code or post a charge on its own?
No. By design the engine only suggests — corrections route to a coder who accepts, edits or rejects. There is no autonomous write path for codes or charges.
How does it know a supply was never charged?
It reconciles stock-movement events (STOCK_ISSUE, STOCK_CONSUMPTION) against the billable_ledger through inventory_charge_leakage_v, then prices the missing line with resolve_menu_price() so the proposal is post-ready.
Does it touch the clinical record?
No. It runs on the operational/financial plane — ledgers, codes, claims, queues — scoped at the database grant. It reads documentation to justify a code suggestion but never authors or alters the chart.
Where does inference run — does PHI leave the building?
Inference can run on Ollama on your own hardware. Encounter and claim data stay on-box, including air-gapped deployments. No PHI has to leave your environment.
How does it improve over time?
Every accept, edit and reject is the training signal. What coders fix, override or dismiss tunes which leaks and which code recoveries the agent surfaces next.
What does it actually post when a coder accepts?
The same path staff use — the correction goes through the coder and charge-capture endpoints into the ledger and onto the claim. No parallel system, one source of truth.
Put Revenue-integrity sentinel on your floor
See it draft real work against your own workflows — every action under human sign-off.