The adoption decision and the evidence stack

Adoption is sometimes reduced to a question about whether a model is accurate enough. That question is necessary, but it is not the decision a hospital is making. The decision concerns a system with a role, an interface, a workflow, people who respond to it, a maintenance process, and an owner. Trust is consequently not one verdict attached to one score. It is a set of scoped claims, each with evidence, a responsible person, and a known limit.

Trust is a stack of scoped claims

The stack below is a teaching synthesis, not a standard or mandatory hierarchy.

The first layer is standalone correctness: a model evaluated on a defined population, preferably with an external test that preserves the intended claim and with calibration considered where probabilities or risk estimates are used. This layer does not establish what happens when a reader sees the output. The second is the reader-plus-AI effect: a comparison with reader-alone performance for the same role, cases, and endpoint. A reader delta does not automatically establish patient benefit or workflow benefit, but it answers a different question from standalone discrimination.

The third layer is integration. The result must be associated with the intended study, returned through the actual technical path, rendered in a usable context, and available at the point where a person is expected to act. A correct result that is late, invisible, or attached to the wrong examination is not evidence of a successful clinical system. The fourth layer is the operating point: the threshold, queue rule, or acceptance rule must be evaluated for the intended population, role, prevalence, workload, calibration, and consequences of error.

The fifth layer is human factors. The evidence must match the interaction being claimed and, where relevant, address attention, alert load, overreliance, override behaviour, and the handling of wrong suggestions. The sixth is staged evaluation: external, shadow, reader, and prospective evidence are not interchangeable because each exposes a different part of the system. The seventh is the lifecycle: monitoring, drift detection, versioned provenance, change control, incident response, and rollback keep the claim open after deployment. A gap at any layer is not filled by the strength of another layer.

The adoption question

Take a constructed example: a segmentation assistant is proposed to support clinical volumetry. Before calling it trustworthy, ask what evidence exists for each layer and which parts remain only promises. The name of a model or tool is not the answer to the question; the intended role, population, workflow, and record produced by the system are.

For standalone correctness, ask whether the model was evaluated on data relevant to the intended use, whether the test was genuinely independent, and whether the reported metric answers the claim being made. For a measurement assistant, a high overlap score may be useful evidence about one property of the mask, but it does not by itself show that a reader’s measurement improves, that the result is usable in the local system, or that treatment decisions or patient outcomes change. The reader-plus-AI layer needs its own comparison and endpoint.

For integration, follow the result from the source study to the reader. Check the identity and timing of the input, the returned object or representation, the link to the source, what the viewer displays, and what happens when a component is unavailable. Technical conformance and successful transport are evidence about specific capabilities and hand-offs; they are not a guarantee that the complete workflow is usable. The operating-point and human-factors layers then ask what the local threshold does to the queue and how readers respond to the output.

Shadow operation and prospective evaluation supply different evidence again. A hidden run can test routing, latency, case mix, alert volume, and local output behaviour before the result guides a reader. It cannot establish a reader benefit while the output is hidden. A visible reader or prospective study can measure interaction, but it must state its design, oversight, and stopping or escalation conditions. Monitoring after the study is what tests whether the observed behaviour persists as the environment changes.

A constructed vendor proposition

Now suppose a vendor presents the following proposition, constructed for this chapter and not a description of a real product or benchmark:

“DeepSect Pro delivers tumour segmentation with excellent AUROC (0.94) and Dice. It is externally validated and CE-marked, integrates seamlessly with your PACS, and reduces reporting time by 30%. EUR120k/year.”

The first response should not be to debate whether 0.94 is a good number. It should be to decompose the claims. What is the labelled intended purpose and which planned workflow role is being proposed? Which population, scanner, protocol, geography, and reference process were represented in the external evaluation? Does the evidence concern standalone segmentation, a reader-plus-AI measurement, or a workflow outcome? The metrics named in the proposition cannot answer all three.

The integration claim needs a site-specific demonstration: which objects or services are exchanged, how the result is associated with the source study, where it is displayed, how many steps a reader takes, and who acts on it. The operating point needs a local rationale and checks for case mix, calibration, alert or edit burden, and error consequences. A reader study needs to expose the intended interaction and report the outcome it claims. If the proposition says that reporting is faster, a workflow endpoint measured in a relevant setting is needed; Dice, AUROC, and external validation are not time measurements.

The governance questions are just as concrete. Who owns the output and its derived measurements? Who receives an incident at night, who can pause the service, and who decides whether a model update is accepted? How is each version recorded, validated, communicated, and rolled back? What happens to historical results when the model or preprocessing changes? Which staff maintain the integration, review monitoring signals, train readers, and investigate overrides? Licence price is only one part of the cost: implementation, compute, training, monitoring, maintenance, and the time of clinical and technical owners also belong in the adoption case.

Privacy and data routing require their own evidence and governance. A technical DICOM confidentiality transformation does not establish legal anonymity, and neither DICOM conformance nor a model metric determines the product’s legal status. The distinction between technical handling, workflow identity, provenance, custody, and jurisdictional legal assessment is carried forward from Chapter 10.

Finally, the claim of realised value must be kept separate from the claim of model correctness. A hospital may decide to measure reporting time, edits, queue delay, unnecessary follow-up, reader agreement, or another local outcome, depending on the role. Such measurements can inform an adoption decision, but they must be designed for that decision. No surrogate model metric alone establishes patient benefit, workflow benefit, safety, health-economic value, or clinical utility.

What an honest recommendation can say

An evidence-backed recommendation has the shape of a ledger, not a slogan. It might say that a frozen model was externally tested for a stated population; that a defined reader study did or did not show a specified reader-plus-AI effect; that local integration was tested for named objects, interfaces, and failure cases; that the operating point was justified for the role and population; that shadow or prospective evaluation answered its stated questions; and that monitoring, versioning, incident response, and rollback have named owners. Each clause points to evidence, a contract, or a governance decision. If a clause appears nowhere, it is an open adoption risk, not an implied property of the model.

A CE mark, where a real product carries one, would need to be understood in relation to the product’s stated intended purpose and the planned use. It is not a universal guarantee of local workflow suitability, reader benefit, or patient outcome. The constructed proposition above is deliberately insufficient until those boundaries are checked. It is also not a legal determination; a real project requires current, jurisdiction-specific regulatory and privacy expertise.

The transferable skill

This stack is the deployment version of the study-reconstruction method from Chapter 9. Enumerate the claims, identify the evidence each claim needs, assign an owner to the remaining work, and keep the conclusion no stronger than its narrowest layer. A model can be accurate while the system is unusable, and a system can be usable while its evidence is too narrow for the proposed claim. Adoption is the decision to accept a particular, bounded set of these facts and responsibilities, with a plan for learning when the world changes.

That is the lifecycle perspective: validation starts with a model, but clinical use requires a role, a human interaction, an operating point, a technical path, staged evidence, governance, and continuing observation. The question is never whether one number grants trust. It is which claims are supported, which are still hypotheses, and who will notice when the answer changes.

The next section examines the boundary between research software and a clinical product.