Developing an algorithm capable of recognizing a lesion, segmenting an organ, or automatically extracting a measurement from a diagnostic image is a major milestone. However, it doesn’t yet mean you’ve built a product ready for use in a hospital, within a medical platform, or as a component of a diagnostic device.
In medical imaging, the gap between an experimental model and an operational solution is often much wider than it appears during the early stages of a project.
An AI pipeline might work perfectly on a curated dataset inside a notebook or a controlled development environment. It can take a batch of images, complete inference, and output a segmentation, a probability, or a JSON file. However, when that same technology needs to step into a real clinical workflow, completely different challenges arise.
Where do the images come from? How is the correct series identified? What happens when a study is incomplete? How do you manage multiple algorithms at the same time? In what format should the output be delivered? How is it displayed to the physician? How can you trace, months later, which model version produced a specific analysis?
Industrializing AI in medical imaging means answering these questions and turning an algorithm into a reliable, integrable, traceable, and monitorable system.
A good AI model is not yet a medical product
One of the most common misconceptions in radiology-focused AI projects is equating the quality of the algorithm with the overall maturity of the solution.
The metrics achieved during model validation are certainly fundamental. Sensitivity, specificity, accuracy, Dice score, and generalization capability describe how the algorithm performs against the problem it was developed to solve. They do not, however, describe everything needed to use that model within an operational workflow.
First and foremost, a product must be able to receive data without requiring manual intervention every time. It needs to understand which images to process, check that they are compatible, run the correct model, and handle any anomalies. Furthermore, it must return the output in a format that can be archived, displayed, and interpreted by the other systems involved.
The AI model is therefore a central component, but it remains just one part of the whole.
Around it, services for integration, orchestration, security, visualization, and monitoring must be built. It is this infrastructure that determines whether the algorithm remains a proof of concept or evolves into a truly adoptable solution.
The workflow begins before inference
When talking about AI in medical imaging, attention tends to focus on the inference phase. In reality, a significant portion of the complexity lies even before the model is run.
Images can come directly from a diagnostic modality, a PACS, a VNA, local storage, or a cloud platform. Depending on the available infrastructure, integration can use traditional DICOM DIMSE services or the more recent DICOMweb APIs.
In either case, receiving a study isn’t simply a matter of copying a folder of files.
The DICOM information structure must be preserved. Patient, study, series, and individual instances are connected through specific identifiers. Orientation, spacing, frame of reference, transfer syntax, compression, and the handling of multi-frame images can directly impact the processing results.
Two seemingly similar studies can also be produced by different devices, with different protocols, or with inconsistently populated metadata. Even small variations can have significant consequences.
An algorithm developed for an axial CT series with a specific slice thickness may not be suitable for a different reconstruction. A model designed for contrast-enhanced images might generate unreliable results on non-contrast acquisitions. An incomplete series could be technically readable, but insufficient for the intended analysis.
For this reason, the first layer of an AI platform must manage not only data transport, but also its validation and normalization.
Understanding whether a study can be processed
Before running a model, it is necessary to establish whether the received study is actually compatible with its intended use.
A first classification can be made using DICOM metadata. Fields like Modality, Body Part Examined, Study Description, Series Description, Protocol Name, and Slice Thickness can help identify the contents of the study and select the appropriate pipeline.
In practice, however, these values are not always reliable.
Descriptions can change across hospitals, manufacturers, and installations. The same protocol can be named in different ways, while theoretically standardized fields might be left empty or populated with local conventions.
A robust pipeline should therefore not rely exclusively on a single piece of information. It is often necessary to combine deterministic rules, configurable mappings, image geometric features, and, in some cases, additional classification models.
The system must be able to recognize not only compatible studies, but also conditions under which processing should not be started. A study might be incomplete, duplicated, already processed, or composed of non-suitable series. In other cases, it might be necessary to request a human review.
This step is essential because it prevents the model from producing apparently valid results from inputs that do not meet the expected conditions.
Orchestration is the heart of the platform
Once the correct study has been identified, AI workflow orchestration comes into play.
The orchestrator coordinates the entire process, from data preparation to the return of the result. It does not simply start a container or call an endpoint: it must know the execution state, manage dependencies, monitor timeouts, recognize temporary errors, and decide when to retry.
A single study may require multiple consecutive steps. Before inference, it might be necessary to convert images, normalize values, identify an anatomical region, or reconstruct a volume. After executing the model, consistency checks, additional calculations, format conversions, and post-processing operations may be required.
In some cases, multiple algorithms must work on the same study.
A first pipeline can segment an anatomical structure. A second can extract measurements from the segmentation. A third can classify the pathology or generate a three-dimensional model. The overall result therefore depends on the correct execution and combination of multiple components.
The orchestrator must maintain control of this sequence, knowing which step has been completed, which has failed, and which outputs have been produced.
The use of message queues decouples study reception from actual processing. This makes the system more resilient, absorbs load spikes, and simplifies job distribution across different CPU or GPU resources.
Model containerization offers isolation, reproducibility, and more controlled dependency management. Each algorithm can be deployed with its own environment, without forcing the entire platform to use the same libraries or software versions.
Where Agentic AI comes into play
Agentic AI can add an extra layer of flexibility within this scenario.
In a traditional architecture, every step is defined using predetermined rules and workflows. This approach remains essential for processes requiring determinism, predictability, and traceability. However, there are activities in which the sequence of operations may depend on the specific context.
A software agent can analyze the available information, select different tools, and coordinate specialized services.
In medical imaging, an agent could check study completeness, identify the most appropriate pipeline, retrieve clinical information from an external system, and request the execution of multiple models. It could then check that the outputs are consistent, prepare a draft report, and create a task for operator review.
The value of the agentic approach does not lie in replacing the diagnostic model or delegating uncontrolled clinical decisions to a generative system. Rather, it consists in connecting different components together and automating tasks that currently require numerous manual steps.
This flexibility must still be governed.
Every action taken by the agent should be logged. The information used, the tools called, and the conditions that drove a choice must be known. When language models are employed, versions, prompts, and configurations must also be tracked.
Agentic AI can therefore become an intelligent orchestration layer, but it must operate within explicit and controllable boundaries.
The physician must be able to understand and review the result
In many clinical contexts, AI does not replace the operator, but prepares a result that must be verified.
An algorithm can highlight a suspicious region, calculate a measurement, segment a structure, or propose a classification. However, the physician must be able to compare the output with the original images, evaluate its correctness, and modify it if necessary.
For this reason, the viewer is not an optional component of the platform.
The interface must allow viewing images, segmentations, heatmaps, measurements, and three-dimensional models within the same context. If the algorithm produces a mask, the user should be able to correct it. If a measurement is proposed, it should be possible to verify its anatomical landmarks. If a draft report is generated, it must be clear which information comes from the AI and which has been approved by the operator.
The human-in-the-loop workflow makes it possible to maintain clinical control and, at the same time, gather valuable data on system performance.
User corrections can be analyzed to identify recurring errors, problematic protocols, or categories of cases where the model is less reliable. This information can feed quality assurance activities and, through controlled processes, contribute to the creation of new datasets and the improvement of subsequent model versions.
The interaction between AI and operator therefore does not represent merely a safety measure. It is also a structured source of feedback.
The result must fit directly into the clinical workflow
One of the most delicate steps in industrializing AI for medical imaging concerns the delivery of the results.
During development, a segmentation can be saved as a NIfTI file, a prediction can be exported to JSON, and a table can be generated as a CSV. These formats may be perfectly adequate for research or communication between internal components, but they are not always usable by clinical systems.
To be genuinely integrated, the result must maintain the link with the source images and the context of the study.
The DICOM Segmentation Object, or DICOM SEG, allows representing segmentations linked directly to the original images. Beyond the mask geometry, it can include metadata regarding the segmented structure, the method used, and the underlying algorithm that generated the result.
This allows the segmentation to be stored in the PACS and displayed in a compatible viewer while preserving spatial references.
When the algorithm produces measurements, scores, or structured observations, DICOM Structured Reporting can represent this information much more richly than plain text. Measurements and results can be directly linked to images, coordinates, and specific anatomical regions.
In other scenarios, generating a DICOM Secondary Capture may be sufficient, for example to archive a derived image or a graphical representation. This is generally a simple solution to integrate, but it is less structured and less reusable compared to DICOM SEG and DICOM SR.
FHIR, on the other hand, can be used to bring the result into the broader clinical context. Resources such as DiagnosticReport, Observation, ImagingStudy, and Task make it possible to connect the processing output to reports, orders, application workflows, and information systems.
DICOM and FHIR do not necessarily perform the same function. DICOM remains central to images and geometric data, while FHIR can facilitate the integration of results with the rest of the healthcare ecosystem.
Format selection should not be driven merely by developer convenience. It must depend on how the result will be used, stored, visualized, and exchanged.
Deployment is not the end of the project
Once integration is completed and the system goes live, a new phase begins: monitoring.
The infrastructure must be observable. It is essential to know whether services are available, how much time each processing task requires, what resources are being utilized, and whether queues are growing. Network errors, temporary PACS unavailability, or GPU access issues must be detected before they compromise the workflow.
Alongside technical monitoring, there must also be operational monitoring.
The platform should show how many studies were received, how many were successfully processed, and how many were rejected. It is useful to track the average job duration, the number of retries, the breakdown by modality, and the most common causes of error.
The most complex level, however, concerns the model’s behavior over time.
An algorithm validated on a specific population can run into difficulties when used in a new hospital, on different devices, or with different acquisition protocols. Even a modality software update or a change in the reconstruction algorithm can alter the input distribution.
For this reason, it is important to observe the quality of incoming images, the distribution of results, the confidence levels, and the corrections made by operators. Significant variations may indicate the presence of data drift or performance drift.
Monitoring a model does not necessarily mean immediately knowing the clinical truth for every single case. It means building indicators that make it possible to recognize changes and anomalies before they become systematic issues.
Versioning and auditing make the system reproducible
Every result produced by the platform should be capable of being reconstructed.
It is not enough to know the name of the algorithm. It is necessary to know which model version was used, with which configuration, which preprocessing operations were applied, and which software version managed the workflow.
Post-processing can also change the final result. Thresholds, filtering rules, geometric conversions, and the terminologies used must therefore be versioned together with the model.
In the case of Agentic AI, traceability must also include the instructions provided to the system, the tools used, and the decisions made during execution.
A comprehensive audit log makes it possible to understand who initiated a process, which system the study came from, which checks were performed, what errors occurred, and who reviewed the result.
This information is essential during validation, maintenance, and quality assurance activities. It becomes even more important when the model is updated, as it allows for comparing the behavior of different versions on the same data.
Reproducibility is not merely a technical requirement. It is what allows us to explain how a result was obtained and to systematically investigate any anomalies.
Security: images are data, but also software input
Medical imaging files must be treated as input coming from external systems.
A DICOM object can contain complex sequences, compressed data, private fields, and structures generated by different implementations. The libraries used to read, decode, and convert this data form part of the platform’s attack surface.
An industrialized solution must therefore validate inputs, apply size limits, enforce timeouts, and isolate the most exposed processes. Dependencies, particularly native ones, must be monitored and updated.
AI models should also be executed in isolated environments, with access strictly limited to necessary data and services.
Connecting to PACS, VNA, and hospital systems must follow the exact same principle. Every component should only be able to perform the operations required by its specific role, avoiding broad permissions or shared credentials.
To this are added encryption, access control, secrets management, environment segregation, and event logging.
Security cannot simply be added at the end of the project. It must be built into the architecture right from the earliest phases.
A possible AI architecture for medical imaging
A comprehensive platform can be divided into several levels, each with clear responsibilities.
At the base are the diagnostic modalities, PACS, VNA, RIS, and other clinical systems. The integration layer receives images and information via DICOM, DICOMweb, HL7, FHIR, or proprietary APIs.
Studies are then validated, classified, and sent to the orchestrator. The latter coordinates jobs, manages priorities, and selects the available models.
Inference is executed by isolated, often containerized services that can utilize CPU or GPU resources. The outputs are gathered by a result management layer, which is responsible for converting them into DICOM SEG, DICOM SR, Secondary Capture, FHIR, or other formats.
The viewer enables visual display and clinical review, while monitoring systems collect metrics, logs, versions, and audit information.
Modalities / PACS / VNA / RIS / EHR
|
v
Integration & DICOM Gateway
|
v
Workflow Orchestrator
|
v
AI Execution Services
|
v
Results Management
|
v
Viewer and clinical validation
|
v
Monitoring, audit e governance
The separation between these levels makes the architecture more modular.
A new model can be added without necessarily modifying the DICOM gateway or the viewer. Similarly, integration with a new PACS can be handled without intervening on the algorithm.
This modularity is what enables the platform to evolve over time without turning into a fragile collection of ad hoc integrations.
Build everything internally or use existing components?
Companies developing AI algorithms often face a strategic decision: build the entire platform internally or integrate already available technologies.
Building all components from scratch requires skills that go far beyond machine learning. It requires knowledge of DICOM and PACS, backend development, cloud and on-premise infrastructure, medical visualization, cybersecurity, interoperability, and operational management of models.
The risk is that a significant portion of resources gets absorbed by infrastructure tasks, distracting focus from the algorithm and the specific clinical value of the project.
On the other hand, excessively standardized platforms can prove difficult to adapt to proprietary devices, specialized workflows, or specific clinical processes.
The most effective approach is often hybrid.
Established components can be reused for connectivity, visualization, and basic orchestration. The truly distinctive elements, such as the model, the specialized workflow, or the interaction with a specific device, can instead be custom-built.
The goal should not be to build everything internally, but to maintain control over strategic components and avoid dependencies that limit product evolution.
From proof of concept to a genuinely usable system
Model performance remains a core element, but it is not enough to determine the success of an AI solution in medical imaging.
A usable system must be capable of integrating with existing infrastructure, handling real-world data, coping with errors and variations, returning interoperable results, and supporting the operator’s workflow.
It must also be observable, updatable, and traceable.
The true transition from prototype to product occurs when the algorithm ceases to be an isolated pipeline and becomes part of a broader workflow.
Competitive advantage, therefore, does not consist merely of owning an accurate model. It lies in the ability to deploy, integrate, monitor, and evolve it within real clinical and technological workflows.
In medical imaging, the algorithm is only the beginning.
How D/Vision Lab supports the industrialization of medical AI
D/Vision Lab works alongside medtech companies, device manufacturers, and algorithm developers to transform AI prototypes and models into integrated software platforms.
The work can start with DICOM connectivity and integration with PACS and VNA, extending to pipeline orchestration, model containerization, and the development of web interfaces for 2D and 3D visualization.
Special attention is dedicated to managing results, which can be converted into structured DICOM objects, integrated via FHIR, or made available within viewers and human-in-the-loop workflows.
Depending on the project, the architecture can be deployed in the cloud, on-premise, or through a hybrid model, keeping integration, inference, visualization, and monitoring components separate.
The goal is not simply to run an algorithm.
It is to build the necessary infrastructure around it so that it can become a reliable, scalable, and interoperable component of a real-world medical ecosystem.
