Ask a radiology department why a promising AI pilot never went live and you will rarely hear that the model was inaccurate. You will hear that it lived in a separate web portal, that results arrived twenty minutes after the study was read, or that nobody could tell which software version produced the overlay on that report.
Radiology AI does not have an accuracy problem. It has a last-mile problem, and the last mile is PACS.
The workflow the model has to join
A radiologist's day is organised around a worklist. Studies arrive from modalities, land in PACS, and are read in an order the department controls. Any AI that wants to be used has to insert itself into that sequence without asking the radiologist to leave it.
In practice that means speaking the existing protocols rather than inventing new ones:
- DICOM C-STORE / C-FIND to receive studies and query prior imaging.
- DICOM SR for structured results the reporting system can actually consume.
- DICOM Secondary Capture or GSPS for overlays that render in the native viewer.
- HL7 ORU / FHIR
DiagnosticReportto push findings toward the reporting and HIS side.
A model that returns JSON to a bespoke dashboard has not integrated with anything. A model that writes a DICOM SR object back to the same study has.
Prefetch, latency and the reading order
The most underrated constraint in radiology AI is time. If the model finishes after the radiologist opens the study, the result is worthless no matter how good it is — it will simply be scrolled past.
That pushes the work upstream. Inference should be triggered by the study arriving in PACS, not by a human clicking a button. For triage use cases the whole point is to reorder the worklist before anyone looks at it, which means the pipeline has minutes, not hours.
If your result lands after the radiologist has already formed an opinion, you have not built decision support. You have built an audit.
Overlays that a radiologist can dismiss
Explainability in imaging is concrete: it is a heatmap or a region marker sitting on the pixels that produced it. Two rules matter more than the visualisation technique.
First, the overlay must be separable. It belongs in its own series or presentation state so the radiologist can toggle it off and read the original pixels. An overlay burned into the diagnostic image is a serious problem, not a feature.
Second, the overlay must be attributable. Model name, version, and run timestamp belong in the DICOM metadata. When a case is reviewed a year later, "which version of the software drew this box?" has to have an answer.
Governance is a PACS question too
Regulatory and legal review will ask where the images went, who could see them, and what happened to them afterwards. Those are architectural questions, and they get much easier if the model runs on-premise against the institution's own PACS, with de-identification at the boundary and audit logging on every retrieval.
The pattern that works in Turkish hospitals is usually the least exciting one: an on-premise inference node beside PACS, DICOM in and DICOM SR out, no patient pixels leaving the institution's network, and every action logged.
It is not the part of the system anyone demos. It is the part that decides whether the demo ever becomes a deployment.