Every AI pilot in a hospital produces a slide of encouraging numbers. Logins are up. Users say they like it. A survey shows time saved. Then the pilot ends, the budget review comes, and the CFO asks the only question that decides renewal: did it change anything we pay for?
We decided to design for that question from the start, not after it.
Pick the number before you start
For a product that works on discharge and placement, the outcome hospitals pay for is length of stay, and in particular the excess days patients spend waiting after they no longer need hospital care. Those days cost money, take beds from the next patient and aren't good for the patient either.
So before any hospital goes live, the measures and their definitions are written down:
- Length of stay on the pilot units, compared with the same units before Aurifex.
- Excess patient days, meaning days beyond what each patient's condition called for.
- Acceptance into acute inpatient rehab, because better referrals should lead to more acceptances.
- Referral prep time and use, to understand how the results happened.
Fixing the definitions in advance matters. It's easy to find a good number after the fact. It's harder, and more honest, to commit to one before you've seen the data.
Adjust for case mix, or the number lies
A unit's length of stay moves for reasons that have nothing to do with your product. A month with more strokes and fewer cellulitis admissions will look worse. A healthier month will look better.
We compare each stay with its expected length of stay from the DRG's geometric mean length of stay, and measure each unit against its own baseline. That's case-mix adjustment, and without it, results are noise that happens to point in a direction.
We agree that yardstick before go-live, so the result is read the same way at the end as it was defined at the start.
Keep adoption next to outcomes
Use still matters. But it belongs beside the outcomes, not instead of them. Adoption tells you whether people used the product. Outcomes tell you whether using it helped. You need both to know whether a result will hold when you expand.
Label projections as projections
Savings are a projection: fewer excess days, valued at a cost per patient day and carried over a year. It isn't money in the bank, it's cost avoided rather than cash, and we never present it any other way.
This sounds like a small point of wording. It isn't. A leader who takes an inflated number to the board pays for it at the next review. A projected number, clearly labeled with its method attached, holds up, and it's the one leaders can actually use.
What this changed about the product
Designing for the buyer's outcome from day one shaped what we built. It's why the unit view tracks avoidable days by reason code, why the outcomes dashboard prints its method on every page and why savings carry a dashed border and a label until a finance team confirms them.
If you're building for hospitals, find out what the buyer pays for and measure that, honestly, from the start. Everything else is a proxy.