Patient financial
Collections agent
Works the AR backlog 24/7 — drafts every collection move, you approve the send.
The Collections agent runs the patient-financial follow-up that staff never have time for: it tracks Promise-to-Pay commitments, reaches at-risk accounts before they age, builds installment plans by ability-to-pay, and escalates through collection tiers. It is recommender-first — the agent drafts the message, the plan, or the escalation; an AR officer accepts, edits, or rejects, and only then does the existing financial and messaging workflow execute. It runs on the Operational plane with zero clinical-chart access and logs every decision under its named identity.
▸ AN 69-002148 · claim batch → invoice · ฿18,420
▸ AN 69-001990 · REP returned C-204 · ลำดับสิทธิ re-route
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.
AR ledger & aging
Watches account_receivable balances, settlementLedger postings, age-in-days and paidAmount against each SalesOrder / encounter.
Promise-to-Pay tracker
Reads open promise_to_pay rows for approaching and broken commitments — fires follow-up when a promise_date passes unpaid.
Collection tier state
Reads collection_account_state (risk band, current_tier, last_outreach_at) against data-driven collection_tier_rule predicates per scheme and facility.
Payor & scheme context
Reads payorPlan / payorSchema and scheme caps so installment terms and outreach honor each fund's rules (NHSO, SSO, PhilHealth, self-pay).
Capacity-to-pay basis
Reads aggregate, consented capacity_basis (income band, dependents, scheme) to size a plan a patient can actually meet.
Outreach history
Reads crm_interactions and last_outreach_at to dedupe, respect quiet-hours, and honor do-not-contact before drafting anything.
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.
Promise-to-Pay outreach
Draft an SMS to a HIGH-risk account: balance ฿4,200, age 47 days — "reply YES to confirm payment by Jun 20" — tracked as a promise_to_pay row on accept.
Capacity-based installment plan
Propose a 6-month plan on a ฿18,000 self-pay balance — ฿3,000/mo, first due Jul 1 — sized to 30% of stated monthly capacity and within scheme caps.
Tier escalation routing
Account aged 92 days, two broken promises — recommend moving from T2 (human call) to T3 (agency) with an SLA chip and the full outreach trail attached.
Broken-promise follow-up
A promise_date lapsed unpaid yesterday — draft a second-touch reminder on the consented channel and re-set follow_up_at for 3 days out.
The loop
Sense → propose → approve → execute
Sense
A nightly cron sweep recomputes collection_account_state — risk, age, and tier — and emits an ar_event for every account crossing a collection_tier_rule predicate or an approaching/broken Promise-to-Pay.
Propose
The agent reads the account, runs the risk scorer and installment generator, and drafts a Promise-to-Pay message, a plan, or a tier escalation as a cowork_proposals envelope with its reasoning trace and confidence.
Approve
The proposal lands in the AR officer's Acknowledgement Inbox alongside the Collections Tier Board — they accept, edit the wording or terms, or reject; the disposition is logged as the training label.
Execute
On accept, cowork-proposal-decide dispatches the write_action through the same endpoints staff use — messaging.send for outreach, financial.installmentPlans.create for a plan, an AR note for a tracked promise.
Capabilities
What it can do
Promise-to-Pay lifecycle
Captures a payment commitment as a tracked row with amount, date, and channel, then auto-fires the follow-up reminder when it approaches or breaks — no manual tickler list.
Pre-delinquency outreach
Scores each account by age, balance, and pay-history into LOW/MEDIUM/HIGH risk and reaches the drifting ones before they age past a recoverable window.
Capacity-based installment plans
Generates a header-plus-schedule plan from aggregate ability-to-pay, choosing the shortest term that fits within 30% of income and the payor's scheme cap.
Tiered escalation engine
Drives a data-driven T1 auto-reminder → T2 human call → T3 agency → T4 legal state machine; tier rules are config rows per country and scheme, not code.
Approved-send drafting
Drafts the actual SMS, email, or call script with its reasoning and confidence; nothing leaves the building until a human accepts in the inbox.
Consent & quiet-hours discipline
Honors marketing_consents per channel, do-not-contact, and facility working hours, and dedupes against prior interactions so a patient is never over-messaged.
Self-sharpening from dispositions
Every accept, edit, and reject becomes the training signal — the agent's risk thresholds and message drafts improve from the team's real decisions.
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.
Operational plane only
Scoped to AR and financial-operational data with zero grant on clinical tables — the agent literally cannot read a chart, enforced at the database grant level.
No autonomous payment capture
Installment creation and any escalation to agency or legal always require a human accept; payment captures can never run hands-free, statically barred from auto mode.
Consent-gated outreach
Every message respects purpose-bound marketing_consents per channel, do-not-contact, quiet-hours, and dedupe against last_outreach_at — only consented reminder SMS is eligible for auto.
Audited per decision
Every proposal and disposition is written to llm_audit_log under the agent's named identity with its full runner trace; references only catalog-validated scheme and account ids, never hallucinated ones.
Data plane
Runs on the Operational plane: it can read AR, financial, and outreach data but holds zero grant on clinical tables, enforced at the database-grant level so it cannot read a patient chart.
Operating characteristics
What changes when it runs
Always-on backlog
Works aging accounts overnight; your team works the exceptions
Reaches accounts before they age
Risk-scored outreach inside the recoverable window
Human gate on every plan & escalation
Only consented reminders are auto-eligible
Full reasoning-trace audit
Named agent identity logged on every proposal
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 send a message or charge a card on its own?
No. It drafts; a human accepts in the inbox before anything sends. Payment captures and plan creation can never run hands-free — that is enforced statically, not by policy. Only a consented reminder SMS can be configured for auto, and even that routes through the same approval audit trail.
How does it decide who to contact and what to offer?
A deterministic risk scorer ranks accounts by age, balance, and pay-history into LOW/MEDIUM/HIGH, and an installment generator sizes a plan to aggregate ability-to-pay within the payor's scheme cap. The thresholds and tier rules are config rows per country and scheme — no per-country code fork.
Does it touch patient clinical data?
Never. It runs on the Operational plane with zero grant on clinical tables. It reads AR balances, payor context, and outreach history — not charts, diagnoses, or notes. The isolation is enforced at the database grant, so it cannot read a chart even if asked.
Where does the AI run — does PHI leave the building?
Inference can run on-box via Ollama on your own hardware, so financial PHI stays in the building and air-gapped deployments are supported. Outreach content is consent-gated and dedupe-checked before any draft is even written.
How does it learn?
From your team's decisions. Every accept, edit, and reject on a proposal is the training label, logged under the agent's identity. There is no silent background learning — the audit trail is the learning signal.
What does it actually execute on accept?
The same workflow endpoints your AR staff already use — messaging.send for an approved message, financial.installmentPlans.create for a plan, an AR note for a tracked Promise-to-Pay. There is no shadow write path and no second source of truth.
Put Collections agent on your floor
See it draft real work against your own workflows — every action under human sign-off.