Technically correct, clinically invisible

Predictive performance alone is insufficient to establish usefulness in the intended workflow; model performance, system integration, and clinical impact are separate questions. The object can be well formed and stored while the reading workstation cannot retrieve it, the result can be linked to the wrong study, or the workflow can receive it after the relevant decision has already been made. These are informatics failure modes, not reasons to infer that the model is wrong.

A diagnostic catalogue

When a result appears to have no effect, keep several failure classes separate:

• Input or grid mismatch. A service may silently resample or choose a series whose geometry or acquisition context differs from the one the reader expects. The output can be internally consistent while referring to a measurement basis the reader cannot inspect.
• Identity mismatch. A derived object may be attached to the wrong patient, study, or series, or may carry identifiers that prevent the viewer from linking it to the study being read.
• Worklist or timing failure. The result may not be routed to the relevant worklist, or may arrive after the report or decision is effectively complete.
• Retrieval or display failure. The archive may contain the SEG, SR, or other object while the workstation cannot query it, decode it, or render it in the current viewer context.
• Lost provenance. The system may not retain which inputs, model version, and processing event produced the result, making a discrepancy difficult to trace.
• Missing audit trail. The system may lack a recoverable record of the events needed to reconstruct who or what handled an object and when.
• Confidentiality leakage. A supposedly de-identified export may still contain identity-bearing metadata, free text, pixels, or linkable context.

The list is a diagnostic model, not an exhaustive taxonomy or a ranking of prevalence. Its purpose is to prevent a single vague diagnosis such as “the AI was ignored” from collapsing object identity, transport, workflow, capability, provenance, and confidentiality into one problem.

A bounded diagnosis before changing the model

Consider a constructed situation in which a vendor demonstration worked, offline metrics remain unchanged, and readers later say that they never see the result. Before retraining the model, trace one examination through four questions.

First, can the intended workstation retrieve and render the object type? A transfer success does not prove viewer capability. Second, is the object linked to the correct study and series, and did the routing rule select the intended source? Third, did the result arrive while it could still enter the reading workflow? Fourth, can the site reconstruct the inputs, model version, and processing event well enough for a reader to understand and trust the result?

These checks are an efficient investigation order, not a universal protocol. The answer may require examining archive queries, DICOM references, worklist state, viewer capability, timestamps, and audit records together. A result that passes all four still needs evidence about how readers use it and what claim is being made; technical visibility is not the same as clinical benefit.

The distinction sets a boundary for interpreting deployment studies. An offline performance number can support a claim about the tested model and evaluation data. Neither offline performance nor technical visibility by itself establishes that a system changed clinical decisions or benefited patients. Evidence designs for an impact claim must match the intended clinical question; the clinical deployment chapter develops that boundary further. Chapter 10 does not add reader-study evidence to that claim.

Failure after go-live

The failure surface can also change over time. A model update can alter provenance requirements, a viewer update can change supported object types, and a merger of systems can change identifier or routing assumptions. A deployment that worked in one configuration therefore needs a way to inspect its current object, workflow, and custody contracts rather than relying on the original demonstration.

Interoperability profiles can help make some of those contracts explicit, but a profile name is not a substitute for end-to-end testing. The next section treats IHE profiles as workflow recipes: combinations of underlying standards that make particular hand-offs more explicit without eliminating local implementation choices.