An illustrative proposal, with made-up numbers: a vendor offers a 300-bed hospital an AI deterioration alert for $400,000 a year. The deck shows outcome improvements at other hospitals. The CFO asks one question. What will it do here, and how would we know?
A clinical decision support (CDS) business case built from the vendor's results and national statistics cannot answer that, because neither describes this hospital. This article sets out how to build a case that can answer it: one use case, a value chain with every link stated, your own baseline, a full cost line, and a decision rule that allows "don't invest."
It covers the financial case. Evaluating the vendor and its model is a separate step, and the business case should not start until you know the model's performance on your own patients.
Start with one decision, not a portfolio
A business case for "AI clinical decision support" is a business case for nothing in particular. Sepsis alerts, ambient documentation, coding assistance, and imaging triage have different users, different costs, and different ways of creating value. Bundled together, a strong case for one hides a weak case for another.
Write the decision as one sentence: Should we deploy this deterioration alert on our medical-surgical units for two years at this price? Name the users, the units, the duration, and the alternative, which is usually "keep doing what we do now." Everything that follows is evidence for or against that sentence.
Write the value chain, link by link
A CDS tool creates value only through a chain of events. The alert fires. A clinician sees it in time. The clinician acts differently than they would have. The patient's course changes. That change saves cost or earns revenue. Each link is a number, and the case is the product of all of them.
Continuing the illustrative example, with made-up numbers:
- The hospital has 20,000 admissions a year.
- 3 percent have the deterioration event the tool targets: 600 patients.
- On a retrospective extract of the hospital's own data, the model flags 60 percent of them early enough to matter: 360.
- Clinicians act on the alert in time for half of those: 180.
- Earlier action avoids an ICU transfer for 15 percent of those patients: 27.
- Each avoided transfer saves $15,000 in this hospital's cost accounting: $405,000 a year.
Laid out this way, the case shows where it is weak. The 60 percent comes from a test on local data, so it is the firmest number. The 50 percent action rate and the 15 percent effect are guesses until the tool is live. The $15,000 should come from your finance team's cost data, not from a published average.
Write a source next to every number: measured here, measured elsewhere, or assumed. A CFO will trust a case with three assumed numbers that are labelled more than one with three assumed numbers that are not.
Replace borrowed numbers with your own
CDS business cases often lean on national figures. Two common ones show the problem.
Diagnostic error is often sized at about 12 million U.S. adults a year. That estimate comes from Singh and colleagues in BMJ Quality & Safety (2014), who estimated an outpatient diagnostic error rate of about 5 percent. It is sometimes attributed to the National Academy of Medicine, whose 2015 report Improving Diagnosis in Health Care is a different source. Either way, a national prevalence figure says how big the problem is. It says nothing about how many errors a specific tool would prevent in your hospital.
Physician turnover is often costed at $500,000 to $1 million per physician. Shanafelt, Goh, and Sinsky cite that range in "The Business Case for Investing in Physician Well-being" (JAMA Internal Medicine, 2017), from one organization's own analysis at Atrius Health. It is a reasonable prompt to calculate your own figure. It is not your figure, and a documentation tool's case needs a link from "less documentation time" to "fewer physicians leaving" that you can defend before the replacement cost applies at all.
The rule for both: use a borrowed number to decide whether a problem is worth investigating. Use your own number to decide whether to pay for a solution.
Put every cost on the page
The license is the easiest cost to find and rarely the largest over the life of the contract. List each of these with an owner and an estimate:
- License or subscription, on the vendor's pricing basis (per bed, per provider, per encounter, or enterprise).
- Integration: data feeds, EHR build, testing, and the informatics staff time behind them.
- Workflow redesign and training: deciding who receives the alert, what they do with it, and teaching them.
- Clinician response time. In the illustrative example, if 15 percent of alerts are true positives, the 360 detected events come with about 2,400 alerts a year, roughly six or seven a day. At 10 minutes each, that is 400 hours of nursing time a year. Show it, even if you do not put a dollar figure on it.
- Monitoring and revalidation: checking that performance holds as patients, documentation, and protocols change.
In the example, a year-one cost of $400,000 for the license plus an assumed $250,000 for integration and training is $650,000, against $405,000 of modeled value. On those assumptions, year one loses money, and later years roughly break even on the license alone. That is a legitimate finding. It may be the right answer.
Find the assumption that decides the answer
Change one link at a time and watch the result. In the example:
- If clinicians act on 70 percent of alerts instead of 50 percent, modeled value rises to $567,000 a year.
- If the model flags 40 percent of events on local data instead of 60 percent, it falls to $270,000.
The action rate and local performance move the answer more than the license price does. That tells you where to spend effort before signing: a local validation that pins down detection, and a workflow design that makes acting on an alert the easy path. It also tells you what to negotiate. A contract that ties fees to measured local performance shifts some of that risk back to the vendor.
Present the result as a range with the weakest assumptions named. In the example, that reads: "In year two, between a loss of about $130,000 and a gain of about $167,000 against the license, before monitoring costs, depending mainly on the action rate and local detection." A board can act on that sentence. A single payback date hides the same uncertainty.
Decide in advance what result means stop
Before go-live, write down what you will measure and what each result means. For the example tool:
- Measure: alerts per 100 admissions, positive predictive value, the share of alerts acted on within the agreed window, and the rate of the target outcome, compared with the same units before go-live or with units not yet live.
- Expand if the action rate and outcome rate meet the levels the case assumed after six months.
- Revise if detection holds but the action rate is low. That is a workflow problem, and fixable.
- Stop if local detection falls below the level that makes the case positive at any plausible action rate.
Writing "stop" into the plan does two things. It protects the budget, and it makes the case more credible, because it shows the people asking for money have said what would prove them wrong.
Questions for your advisers
Some inputs to the case are not financial, and they belong with qualified advisers rather than in a spreadsheet. Ask your regulatory adviser whether the tool's intended use requires FDA clearance and what its current status is for that use. Ask counsel how AI involvement in clinical decisions should be documented for liability purposes in your jurisdiction. Ask your clinical leaders whether the action the alert prompts is one they would endorse. Each answer can change the case.
Your next step
Take the one CDS proposal currently in front of you and write its value chain as a list, as in the example above, with a source next to every number. Mark each one measured here, measured elsewhere, or assumed. If more than half are assumed, the next spend is a local validation, not a contract.
GradeCircle builds and runs six products of its own: AfroSynergy, CallerBridge, HealthSquire, Heyzl, Lexfora, and LukeAPI, two of them in beta. The assumptions in our models come from operating those systems, not from a framework. See what we run.
If you have a specific decision in front of you, scope it in five questions and see the engagement, price band, and timeline before sharing contact details.
