AI for CT analysis: segmentation, detection, quantitative analysis

AI CT analysis: where the manual reporting workflow breaks

In a department, it is a flow rather than individual images: during a shift, dozens of studies pass through a physician, each with hundreds of slices across several phases.

While series review is done by hand, the queue for study reporting grows faster than it can be cleared: urgent findings sit in the same pile as routine ones, and some studies roll over to the next day.

The second bottleneck is reproducibility. Two physicians will describe the same series differently: lesion contour boundaries, maximum linear size, and volume depend on where the boundary is drawn and on which slice the measurement is taken.

For the patient, this is a difference in interpretation; for the department, it means no metrics that can be compared across studies.

Then the cost only grows: dynamics have to be reconstructed from report text, and it does not provide consistent numbers from visit to visit, so increase or decrease of a formation is judged by wording.

A neural network for CT here does not work instead of the physician, but as a layer that segments structures in the same way across all series.

AI CT analysis addresses three points: it relieves the queue for study reporting, removes labeling variability through a single algorithm, and provides repeatable numerical characteristics for comparison over time.

Automatic CT reporting in this workflow is a draft with calculated metrics that the physician reviews and supplements, not text replacing them. Let's break down how this works in practice.

What automatic processing of study series provides

A CT series is hundreds of slices that a physician traverses manually: marking lesion boundaries and transferring measurements into the report.

Automation removes this routine: CT segmentation identifies target structures across all slices, CT quantitative analysis calculates volumes and density characteristics using a single methodology, and the result is stored in the DICOM series as ordinary annotation, over which the physician works with familiar tools.

The key effect is measurement reproducibility. One threshold, one recalculation geometry, one model version: re-reviewing the same series yields the same result regardless of who reviewed it and on which shift.

A whole class of repeat reviews disappears, when a measurement is redone because of doubts about the annotation rather than because of new clinical data.

Model quality control is an ongoing loop, not a check at launch.

We maintain a regression set of studies with reference masks, run it in full with every update, and monitor the discrepancy rate for each finding class: a drop in this rate stops the release rather than reaching the physician.

In sum, this compresses the reporting cycle time: the annotation draft and measurements are ready by the time the physician opens the series, and all that remains is to review and confirm.

Cases that are questionable by the confidence threshold are surfaced — misses that previously came to light at a follow-up visit are caught on the first pass.

Model operating modes: batch, interactive, streaming

Batch CT processing is a mode for arrays: overnight archive loading, retrospective review of accumulated studies, preparation of samples for quality audit.

The model processes the queue without physician involvement, the result is stored alongside the DICOM series, and it is reviewed in the morning. There is one limitation, but it is fundamental: the response arrives hours later, not at the moment of examination.

Interactive image review is enabled right at the workstation: the physician opens a series, the model returns a mask and quantitative metrics within seconds, and they edit the contours and confirm the report.

Here, not only accuracy but also response time matters — if a series takes more than a few seconds to process, edits start to get in the way, and the mode quietly falls out of use.

Streaming study processing is deployed at the archive input: each new study goes to the model immediately upon arrival, and the result is returned to the patient record before the radiologist opens the images.

This mode requires reserve capacity for peak hours and clear failure behavior — otherwise the entire queue stalls.

What to choose for the department profile

The modes do not compete; they combine: streaming covers the current shift, batch covers the accumulated archive and rechecking, and interactive covers complex cases.

The choice of operating mode is determined by the flow profile: how many studies per day, whether there are pronounced peaks, and whether the department is ready to change its procedures.

During task review, we compare these parameters with the configuration and say which mode will deliver results and which will create unnecessary workload.

Implementation stages: from data audit to handover

The order of stages here is not a formality: a model with good numbers on a prepared dataset underperforms on a specific clinic's flow — different scanners, positioning, slice thickness.

That is why we begin AI implementation in diagnostics not with the model but with a CT data audit, and finish with acceptance testing on studies the model has not seen.

Work sequence

1. CT data audit. We review what has been accumulated: study series, availability of reports, distribution by scanners, protocols, and finding classes. The output is a gap map: which cases are scarce and where annotation is contradictory.
2. Solution design and acceptance criteria. We fix what the system calculates — contours, lesions, volumetric indicators — and the quality metrics in advance. We evaluate at the study level, not the individual slice level.
3. Annotation according to a single protocol. Disputed cases go to arbitration; we separately measure inter-physician agreement. If specialists disagree among themselves, the model will not become more accurate than they are.
4. Tuning on clinic data. Fine-tuning for the local fleet of scanners and positioning, with checks that the model does not memorize a specific scanner instead of pathology features.
5. Model validation on a holdout set. Tests on studies from another period, error analysis by subgroups: small lesions, artifacts, postoperative conditions.
6. Integration and solution acceptance. The result appears where the physician views the images, with a log and quality mark; acceptance is based on agreed metrics.
7. Handover to operation. Usage procedures, staff training, analysis of typical errors, and support — the model is updated on new studies.

Artifacts and procedures that remain with the customer

Handover of the solution is not an archive with model weights, but a set of materials that your team can use to operate the system without us: deploy it, update it, analyze a disputed case, and explain to an auditor where a number in the report came from. Below is what physically remains with the customer after delivery.

• Model documentation — which studies it was trained on, on which independent sample sensitivity and false-positive rate were measured, and under what conditions quality degrades.
• Data flow diagram — the path of a study from scanner to workstation: where it is stored, what is sent for processing, and at which step de-identification is performed.
• Integration with the physician's workstation — how annotation and quantitative values appear in the familiar viewing window and what the physician sees if the analysis service is unavailable.
• Access policies — roles, who can see source studies and results, who can export, and the data access log.
• Physician workflow procedures — for which series to run analysis, how to read annotation and volume estimates, and in which cases the output must be manually rechecked.
• Error review procedures — how a discrepancy is recorded, where disputed cases go, and how they affect the next model version.
• Configurations and recovery — deployment parameters, dependencies, and steps to roll back to a previous version if the new one performs worse on your data.

Additionally, we provide a short physician instruction — one or two pages without technical details — and hold a session where we review real cases on your studies.

The package is updated together with the model: as the version changes, the documentation and metrics change; otherwise, in six months no one will remember what the indicators were calculated on.

Case study: lesion segmentation and reporting in a department workflow

A clinic with a flow of 70–90 chest studies per shift: series arrive in DICOM, and three radiologists read them in turn. Lesions were annotated manually on slices, and the report was written in free text.

Inter-physician discrepancies in lesion count and size reached 18%, and nearly every fourth case was returned for re-reading — the department's reporting was closed with delay.

What was changed

The segmentation model was trained on annotations from two radiologists: disputed cases were resolved before launch so that the reference was agreed upon rather than "averaged across the hospital." Processing runs next to the workstation — the series goes for analysis immediately upon arrival, and masks and quantitative indicators are overlaid on the slices.

The report draft is assembled into a structured template, and the physician edits the wording instead of typing it manually.

The before and after metrics were captured on the same flow: the CT segmentation case was designed so that the comparison would not be blurred by a change of equipment or scanning protocol.

The model does not make a diagnosis — it returns measured volumes, coordinates, and dynamics relative to the previous study, while interpretation remains with the specialist.

How does detection differ from segmentation and measurements?

Lesion detection answers the question "is there a finding and where": the model returns coordinates, a bounding box, or a probability map.

It does not provide geometry — volume cannot be calculated from such annotation — but it does solve flow prioritization: a study with a suspicious nodule goes to the physician first, and a series without findings does not occupy the queue.

This is the shortest path to impact because it does not require pixel-level annotation during training.

Segmentation versus detection is the difference between "where" and "what shape." The model outlines the contour of a structure and returns a mask, from which area, volume, and density distribution are calculated.

Annotation is done by an expert, and disputed boundaries — near a vessel, the pleura, or on soft tissues — differ even among annotators, so we separately verify reproducibility: two runs on the same study should produce a similar contour; otherwise, volume over time means nothing.

Volume measurement and dynamics are the third layer.

It appears when there are masks from at least two studies of the patient: volume is calculated for each series, then the series are registered so that comparison follows the same anatomical landmarks rather than differences in positioning.

What matters here is not the absolute number but repeatability — it is what determines whether growth of a formation can be distinguished from method error.

The choice of method is dictated by the clinical question, not by model quality. For screening and triage of the flow, detection is sufficient; for intervention planning, treatment response assessment, and follow-up, segmentation with volume measurement is needed.

Most often, a cascade works: detection filters out the unnecessary and launches segmentation only where it is needed — quality is higher, processing is faster.

Method limitations and technical concerns

Variability of scanners and protocols is the main source of quality degradation. A model trained on one fleet of scanners loses sensitivity on another: slice thickness, noise level, contrast enhancement, and patient positioning change.

That is why we begin not with deploying a ready-made model but with statistics on your fleet and data quality checks on a sample of studies.

We measure false positives not abstractly but by their cost to the physician: how many extra findings occur per study and how much time is spent reviewing them.

The detection threshold is an adjustable parameter: it is shifted either toward recall so that nothing is missed, or toward precision so that the report does not drown in noise. A specific mode is selected for each task, and this is fixed in acceptance.

Where is personal data processed?

We agree on the environment before launch: inference inside your perimeter or on a dedicated environment with de-identification at the input — identifiers are removed from the study, leaving only the image series. Access, logging, and retention periods are described in the procedure.

Let's discuss the task: how to integrate AI into your study flow

So that the project assessment is based on your data rather than general assumptions, we start the conversation with task definition.

Send a slice of your study flow and how it is currently organized — this shows protocol variability, series quality, and where AI delivers gains and where it adds unnecessary work for the physician.

What to send so that we return with an implementation plan:

• A sample of studies for a period — 20–50 series are enough to assess protocol variability, slice thickness, and typical artifacts.
• A description of the current flow: where studies come from, where they are stored, in which system the report is written, and what happens to it afterward.
• The clinical task formulation — structure segmentation, lesion detection, or quantitative dynamics analysis — indicating which answer is considered correct.
• 5–10 examples of physician reports: from these we build the reference and agree on the acceptance metric, rather than on "similar or not similar."
• Processing requirements: operation within your network, on-site de-identification or transfer outside, and who gets access to the results.
• Flow volume and timelines: how many studies per day, whether real-time review is needed or batch processing is suitable.
• The responsible person on your side who confirms the reference and accepts the result at each stage.

In response, we send an implementation plan: the composition of stages, acceptance metrics at each of them, an integration scheme with your archive and viewer, a list of risks, and a rollback procedure to manual reporting if quality is not confirmed on a specific data slice. Describe the task — we will return with an estimate and work plan.