# Scaling CareFix from two hospitals to the full base

What has to be true at each stage, what breaks first, and what onboarding actually costs. Numbers are derived from the design in this build; replace them with measured figures once the pilot runs.

## Waves

| Wave | Hospitals | Purpose | Gate to the next wave |
|---|---|---|---|
| Pilot | 2 | Prove diagnosis quality and the approval flow | 40+ tickets closed, no rollback caused by a wrong fix, median time to close cut by half |
| Wave 1 | 20 | Prove it survives variety: different HIS versions, customisations, on-prem and cloud | Under 10% of tickets need engineer hints beyond the ticket text; playbook library covering the top 20 issue types |
| Wave 2 | 100 | Prove the operating model: approvals at volume, regional leads, onboarding at pace | Approval turnaround inside targets without leads being swamped; onboarding down to half a day per hospital |
| Base | 1,000+ | Standard part of AMC | — |

Sequence hospitals by HIS version, newest first. A hospital on an old version with heavy customisation costs three times the onboarding effort of a standard one, and teaches you less.

## Onboarding cost per hospital

| Step | Who | Effort |
|---|---|---|
| Addendum signed | Account manager | 1–3 days elapsed, 30 min work |
| DBA script run, logins created | Hospital DBA with Caresoft support | 30 min |
| Allow-list agreed | Support lead with hospital IT | 1–2 hours, the real work |
| Agent installed (on-prem only) | Hospital IT | 30 min |
| Connection saved, tested, schema captured | Caresoft admin | 15 min |
| Engineers assigned, first ticket watched | Support lead | 1 hour |

About **half a day of Caresoft time** per standard hospital, plus elapsed time for the paperwork. At 1,000 hospitals that is roughly 500 person-days, so it cannot be done one at a time by one team. Three things make it affordable:

1. **A standard allow-list per HIS version.** Agree it once with the product team, then present it to each hospital as the default rather than designing it fresh. This is the single biggest saving.
2. **A pre-signed addendum in the AMC renewal pack**, so CareFix arrives with a renewal rather than as a separate negotiation.
3. **A packaged, signed agent installer** that a hospital's own IT can run unattended with a config file.

## What breaks first, in order

**1. Agent polling, at roughly 100 on-prem hospitals.** Each connected agent long-polls the server, and the server checks the job table twice a second while holding a request open. At 500 agents that is around 1,000 queries a second against `CF_AGENT_JOB`, on one control database. The idle back-off is now built in: an agent is checked every half second for the first five seconds of each poll and every two seconds after that, which cuts the load about fourfold. Beyond roughly 500 agents, move the wait to a push channel (SignalR or WebSocket) so idle agents cost nothing.

**2. Control database growth.** A ticket stores its AI transcript, query results and row snapshots: roughly half a megabyte. At 1,500 tickets a month that is about **9 GB a year**, and it grows with the base, not with time. The nightly housekeeping job enforces the retention periods in `CareFix:Retention`, so set those to whatever the signed addendum promises. Keep snapshots at least as long as anyone might ask for a rollback; the default is 180 days. `CF_AUDIT` is deliberately never purged.

**3. Approval load on leads.** At 1,500 tickets a month with 60% Low risk, leads approve around 900 fixes a month, roughly 45 a working day. That is manageable for a team of leads, tight for one. Two levers: regional leads with hospitals assigned to them, and Phase 4 auto-approval for playbook-matched Low-risk fixes with a clean track record. Do not switch on auto-approval before you have at least six months of data showing those fixes were never rolled back.

**4. Schema snapshots.** About 30,000 columns per hospital means around 30 million rows across the base. SQL Server handles that. Housekeeping recaptures up to 25 stale snapshots a night, which covers the base at a 30-day refresh; raise the nightly limit or shorten `SchemaRecaptureDays` if HIS upgrades come in bursts.

**5. One server.** Everything runs on one node today: AI workers, the agent hub, the webhook dispatcher and the background jobs. It is comfortable to a few hundred hospitals. Beyond that, split the agent hub onto its own node first, because it carries the most connections. Nothing in the design prevents running several API nodes, since state lives in the database, but the background services would need a leader election so jobs don't run twice.

## Operating model at scale

- **Regional support leads**, each owning a set of hospitals, approving Low and Medium risk for them. Keeps four-eyes real rather than one person rubber-stamping.
- **One product owner on rota** for the second Medium-risk approval, so tickets don't wait on a single person's calendar.
- **The Support Head stays the only approver for High risk.** Do not delegate this as volume grows; it is the control that makes the hospital consent meaningful.
- **A weekly playbook review**, 30 minutes. Every repeated fix becomes a playbook. This is what makes the AI cheaper and faster over time, and it is the work most likely to be skipped when the team is busy.

## Cost at scale

AI cost is per ticket, not per hospital, so it tracks ticket volume rather than the size of the base. At current rates, the whole base generating 1,500 database tickets a month runs roughly **$150 to $300 a month**. Server cost is one VM. Neither is the constraint; Caresoft's own time is.

## What would make CareFix a product rather than a tool

The pilot will answer whether hospitals value seeing their own change log and audit report. If they do, there are two routes worth weighing after Wave 1:

- **Bundled with AMC** as a service-level promise: data issues corrected within X hours, with an audit report each quarter. Strengthens renewals and is the easier sale.
- **Separately licensed** to hospitals with in-house IT teams who want to run corrections themselves under the same controls. That is a bigger change: it needs hospital-side user management and a different support model.

Decide this with pilot evidence, not before.