Underwrite two different propositions
A technology can perform a task well without producing a strong enterprise investment. I separate the capability proposition—whether the system improves a bounded job—from the value-capture proposition—whether the organization can turn that improvement into better access, quality, experience or economics.
The two require different evidence. A task benchmark tests performance under defined conditions. An operating evaluation tests adoption, review, exceptions, downstream effects and the cost of changing how people work. A contract then determines who pays and who benefits.
Interpret the research at its actual scale
That finding does not price a health system’s AI return. It tells a buyer to measure adoption and product-specific effects rather than apply one productivity assumption to an entire workforce. Saved time may become less after-hours work, more time with patients or additional capacity. Those are different benefits and should not all be counted as cash savings.
The economic case needs a feasible conversion mechanism. Additional capacity creates incremental contribution only when clinically appropriate demand, scheduling, staffing and payment align. Improved clinician experience may be valuable even when no labor cost is removed. It should be measured on its own terms.
Design the value-capture contract
| Party | Potential benefit | Potential hidden cost |
|---|---|---|
| Patient or member | Faster access, clearer navigation, less repeated information. | Additional verification work, inaccessible channels or a more difficult appeal. |
| Clinician or staff | Less repetitive work and more useful context. | Review, correction, alert volume and responsibility for exceptions. |
| Provider or payer | Better throughput, payment accuracy or operating reliability. | Integration, governance, rework, vendor fees and transferred burden. |
| Technology vendor | Recurring revenue and a reusable implementation. | Customization, support, liability allocation and unpriced service work. |
I would agree the baseline, eligible work, adoption denominator and review burden before negotiating an outcome-linked claim. The buyer and vendor must also decide who owns the data, which actions require approval, how errors are corrected and what happens when the product changes.
Pricing against theoretical hours released can reward a vendor for an improvement the buyer cannot monetize. Pricing only against cash savings can exclude worthwhile access or workforce benefits. The solution is an explicit outcome set and a payment structure aligned to what can actually be established.
A viable contract has to work on both sides.
View full-size exhibit ↗
Source & method. My proposed conceptual model of contract feasibility, not an estimated market price or a claim that every use case has a viable range. Circle areas and overlap are not quantitative. Clinical quality, lawful authority and safety remain independent requirements.
Own the exception path
The strategically important work often begins when automation cannot complete the task. A missing authorization, conflicting clinical fact, disputed payment or uncertain identity needs a route to someone with authority to act. An exception queue without capacity simply relocates the bottleneck.
My preferred architecture separates observation, recommendation and action. Each has a defined scope, source context, confidence requirement and accountable owner. Consequential clinical or payment decisions require the relevant professional and organizational authority. Automation should make escalation faster and more legible, not hide uncertainty behind a completed status.
NIST’s AI Risk Management Framework organizes risk management as continuing governance, mapping, measurement and management. I apply that lifecycle view to the operating and economic case as well as to model performance. [2]
Move from a pilot to a portfolio
A portfolio view prevents the organization from funding a collection of disconnected demonstrations. I would compare use cases on value at stake, implementation dependence, required authority, failure consequences and the reuse of common capabilities.
A low-risk administrative workflow may be the right first investment if it establishes identity, audit, integration and review capabilities needed elsewhere. A spectacular demonstration can be a poor first choice if it requires every unresolved dependency at once. The objective is a sequence of useful operating capabilities, not the largest number of pilots.
Decide which constraint the next investment resolves
Expansion requires evidence that benefit survives actual use, total ownership cost and downstream effects. If the value case fails, leadership should be able to distinguish insufficient adoption, a weak product, poor workflow fit, an unpriced exception burden or an absent path to capture value.
That diagnosis determines the response: redesign the workflow, change the vendor or contract, narrow the use case, build a missing capability or stop. AI strategy becomes executive work when those choices govern capital and accountability.
Use the existing value-realization ledger ↗Sources & analytical basis
The strategic recommendations are my interpretation of the attributed evidence. I distinguish published findings, company observations and illustrative scenarios throughout the analysis.