AI analysis of MRI: where the image flow breaks in the clinic
The queue of studies grows not because of a shortage of scanners, but because of the gap between acquisition speed and review speed.
One scanner per shift outputs more series than a radiologist can physically read: a series of several hundred slices takes 10–15 minutes, and almost all of this time is routine review, not pathology search.
The queue of studies accumulates in the image archive, and the longer it is, the higher the load on the radiologist.
The cost of this gap is not only delayed reporting.
Reviewing a series of images toward the end of a shift proceeds on residual attention: small lesions, symmetric changes, and borderline cases get lost in the flow, and some missed findings surface later — on a repeat visit or another study.
The second problem is reproducibility: linear dimensions and volumes taken manually diverge from shift to shift, and dynamics from a previous image have to be reconstructed anew.
Comparing two series by eye and getting an objective “has it become larger or smaller” is almost impossible.
Hence the task for AI analysis of MRI is formulated not as “find pathology,” but as aligning the flow: remove the routine part from the physician, record measurements identically, and highlight what is easy to miss. We break down how this is addressed.
What changes in the department’s work after implementing the model
The first effect is noticeable not in reading speed, but in the order of work: the model reviews the entire series and returns markup along with urgency signs, so studies with suspected acute pathology move to the top of the worklist, while elective ones move lower.
Time to the start of review decreases from hours of waiting in the general queue to minutes, while the physician opens the same study in the familiar viewer — only the moment when they get to it changes.
The second effect is the class of avoided rejections. The model highlights lesions and prevents missing an area outside habitual attention, and marks controversial cases for second reading.
The share of repeat reports falls: rereading is requested for a specific reason, not “just in case.” The load per shift evens out — peak hours no longer accumulate into an unreviewed backlog by the end of duty.
The order of magnitude is confirmed by publications on clinical implementations: in Radiology materials, the same shift is described — a reduction in time to the start of series review and a lower share of repeat reports without loss of report quality.
Exact values depend on the flow and profile of the department, so they are recorded by measurements before and after: time to the start of review, share of studies sent to second reading, number of misses on the control sample, and distribution of load across shift hours.
Approaches to image analysis: what to choose for the task
Choosing an approach starts not with the model architecture, but with the question the result must answer. Highlight a suspicious area, outline a contour, assign a series to a class, or compare with a previous study — four different tasks, and each needs its own annotation.
It is annotation that sets the quality ceiling: if lesions are annotated with bounding boxes, the model will not produce precise contours.
It is worth starting with the simplest formulation that meets the clinical need, and complicating it only when benefit is proven. Below is a comparison by annotation effort and by what the physician gets as output.
| Formulation | When it fits | Annotation requirements | Limitations |
|---|---|---|---|
| Lesion detection | Need to quickly highlight suspicious areas and prioritize the reporting queue | Boxes or points on every lesion, including small ones | Localization is coarse, size and volume are not calculated from the box |
| Region segmentation | Need area, volume, and precise boundaries for planning | Pixel contours, annotation by two specialists with reconciliation | Expensive and slow, sensitive to disagreement between annotators |
| Series classification | Need an answer “normal or pathology” or sorting by type | Label for the entire series, without contours | No localization; with a rare class, quickly hits imbalance |
| Dynamics assessment | There are two studies of one patient and the question “better or worse” | Co-registered image pairs and a unified acquisition protocol | Requires matching series, sensitive to differences in positioning and scanner |
In practice, approaches are combined: detection prioritizes series, classification filters out normal cases, segmentation refines volume, and dynamics assessment relies on already delineated regions.
We select the minimal formulation for the task and validate it on your images before full annotation.
How implementation proceeds: from data audit to handover
Implementation starts not with the model, but with data: the quality of the archive and annotation sets the accuracy ceiling, which cannot be raised by changing the architecture.
Therefore, first comes an inventory of what the clinic has already accumulated, and only then training.
- Audit of the image archive. We export a de-identified slice of studies and examine what is in it: series by body area, protocols, share of artifacts, and missed series. The output is a data map showing where there is enough material and where it is critically scarce.
- Annotation review. We calculate agreement between specialists and examine the rules used for contouring. Differences in boundaries are normal, but if interpretations diverge systematically, we first establish a unified protocol — otherwise the model learns from noise.
- Control sample. We set aside part of the studies before training begins, and strictly by patients, not by images: otherwise one patient will appear in both training and validation, and metrics will be inflated.
- Training and comparison of options. We run several approaches, but choose not by the number on the training part, but by behavior on held-out data.
- Validation on the control sample and error analysis. We calculate metrics by class and lesion size, separately for misses and false positives. We review each error with physicians: some are critical, some are a controversial interpretation of boundaries.
- Implementation in the clinic. We connect to the working environment in suggestion mode: the physician sees the markup and confirms or edits it, while the study flow does not stop.
- Solution acceptance and handover. We fix target metrics, hand over documentation, the regulations for working with the model, and a plan for retraining on new data, and train personnel.
What remains with the clinic: configurations and regulations
We hand over not only the trained model, but also everything without which it ceases to be reproducible: processing pipelines, rules for handling data, and instructions by which the shift works. Below is the list of artifacts that remain with the clinic after acceptance.
- Model and runtime environment: weights, fixed version, build files, and launch parameters — deployment can be repeated on your environment without us.
- Processing pipelines: the sequence of steps from the source series to markup — preprocessing, normalization, activation thresholds, and postprocessing that cuts off false positives.
- Physician workflow regulations: where to view the result, what counts as confirmation, how edits are recorded, and by what procedure a controversial case is reviewed.
- Data access rights: roles, separation by department and specialty, log of accesses to studies and exports.
- Image de-identification: at which step identifiers are removed from descriptions, who stores the matching key, and how its use is restricted.
- Solution documentation: metrics on the held-out sample, known limitations, and a list of cases where the model errs most often.
- Shift instructions: troubleshooting typical failures, model update procedure, and rollback to the previous version with one command.
Such a set removes dependence on the authors: the clinic can change the support contractor without losing access to the logic of how the system works.
Case: how series review time was reduced in diagnostics
A network of diagnostic centers processed several hundred series per day, and reviewing each took a physician 18–25 minutes: outline lesions, measure, compare with a previous study.
The queue grew faster than staffing, and some series went to repeat review by a second specialist — not because of case complexity, but because of contour discrepancies between shifts.
We trained a segmentation and detection model on an archive of annotated studies and embedded it into the viewer already in use.
Based on MONAI, we assembled preprocessing, bringing series into a unified space, and inference: the algorithm returns ready pre-markup for each lesion, and the physician confirms or edits the contours in the familiar interface.
Physician edits go into retraining, so the model improves on rare scanning protocols without rebuilding the dataset.
By the before-and-after numbers: average time to report decreased from 21 to 7 minutes per series, and the share of studies returned for review — from 11% to 3%.
Physicians stopped spending shifts on routine outlining and focused on controversial cases where the decision truly requires experience.
Separately, we validated on held-out data — series that participated neither in training nor in parameter selection.
Contour agreement with annotations from two independent physicians exceeded the threshold at which pre-markup is accepted without edits, while misses of large lesions and false positives remained within limits agreed with experts. It is precisely this margin of safety that allows not rechecking every series manually.
How does segmentation differ from detection on MRI images?
Detection answers the question “is there an object and where is it”: the model returns a box around the region of interest on a slice. Segmentation builds a contour pixel by pixel, so it provides shape, area, and volume. The difference is fundamental: a box speaks to presence and localization, a contour to measurement.
Annotation for detection is cheaper and faster: the physician only needs to draw a rectangle, disagreement between specialists is lower, and data is collected several times faster.
This formulation is used when the decision prioritizes the queue of studies, marks suspicious areas for second reading, or filters out normal cases — boundary precision is not critical here, the fact of a finding is what matters.
Segmentation is needed when the result goes into the report as a number: lesion area, formation volume, dynamics between two studies of one patient.
Shifting the contour by a few pixels changes the measurement, so pixel-level annotation, agreement between physicians, and separate boundary accuracy control are required.
In AI analysis of MRI, the choice of task formulation is determined by the next step: if the image goes to a physician for clarification, detection is enough; if the model calculates a metric for the report, segmentation is needed.
They are often combined: detection finds candidates, segmentation refines the contour only in those zones — less annotation and computation.
Quality in these cases is measured differently: for detection — share of missed findings and box agreement; for segmentation — overlap of the predicted contour with the reference.
We start with the question “what will go into the report” and select annotation and architecture for it — otherwise data is collected for the wrong task.
Questions asked before a project starts
At the start, the customer is concerned not with the model architecture, but with the data and processes around it. Below are the questions technical leaders ask most often, and answers without presentation wording.
How do you guarantee annotation quality?
Annotation is performed by specialist physicians according to a fixed protocol: a unified class system and rules for controversial cases. Part of the studies is annotated twice, and annotator agreement is measured — the model’s metric on the held-out sample depends on it.
Will the model work on our scanners?
Different manufacturers and scanning protocols produce different brightness and noise distributions. The sample is collected from several scanners, images are brought to a unified form, and quality is checked separately for each scanner. If a new scanner appears, we run a control pass and, if necessary, retrain the model.
Who is responsible for the model after implementation?
Monitoring records the share of failures, input data drift, and discrepancies with the physician’s report. A protocol change or scanner replacement triggers a notification, and we return to retraining. Model versions are stored, so rollback to the previous one takes minutes.
Will the department’s workflow have to change?
The solution is embedded into the current route: the study goes into processing, and the result returns to where the physician expects it. Viewing and editing results is part of the delivery; staff training is included in the project. What changes is not the workflow, but the share of routine: draft segmentation arrives ready-made.
Let’s discuss the task: what to send for assessment and a plan
To come back with a project assessment and work plan, a full technical specification is not needed — the inputs listed below are enough.
The more specific the source data and expectations, the more realistic the implementation timeline and the clearer the team composition: already at this stage it is visible what we will build on existing annotation and what will require rebuilding it.
- Examples of studies: several dozen series acquired under different conditions, including complex cases — this is how we assess data variability and the associated risks.
- How the reference is structured: whether annotated masks exist, who prepared them, and how consistent the annotations are between physicians.
- What you consider success: target metrics — contour agreement, sensitivity on small lesions, share of misses, acceptable number of false positives.
- Current manual process: how much time a specialist spends reviewing one study and which step you want to remove from them.
- Where the data is stored and how it is transferred: local environment or cloud, whether de-identification is needed, who is responsible for export.
- Infrastructure: where the model is planned to run — next to the workstation, on a separate server, in the customer’s secure environment.
- Organizational framework: desired implementation timeline, who accepts the result and performs stage-by-stage acceptance.
Based on these points, we will come back with an assessment of stages, a work plan, and team composition. Describe the task as it stands now — we will clarify the rest in conversation.
