Catalog / Healthcare & Clinical / HLTH-023

AI image reconstruction & accelerated scan acquisition (MRI, CT, PET)

Deep-learning reconstruction on the scanner turns undersampled or low-dose raw data (k-space, sinograms) into diagnostic images, shortening MRI exams and cutting CT/PET dose for radiology departments.

Parts needed to run it yourselfOptimizationVision

Scanners do not record images but raw data (k-space in MRI, projections in CT, coincidences in PET). Classical reconstruction trades scan time or radiation dose against noise and artefacts. Deep-learning reconstruction (DLR) learns to restore diagnostic quality from less data, so MRI exams get markedly shorter and CT/PET doses lower, while throughput and patient comfort rise. It is bought with the scanner, certified as part of the modality, and sits upstream of image interpretation (HLTH-001).

Problem & value

  • Today: MRI is slow (long exams, motion artefacts, queues); CT and PET dose is limited by the ALARA principle, and noise rises as dose falls. Parallel imaging and compressed sensing already allow some undersampling, but with limited acceleration before image quality degrades.
  • AI value: DLR removes noise and aliasing from undersampled or low-dose data. Vendors report MRI scan-time reductions of roughly 30-70% depending on sequence, and substantially lower CT/PET dose at comparable image quality; exact figures are sequence-, body-region- and site-specific and should be taken from vendor clinical evidence and your own validation [1][2][3].
  • Operational benefit: more slots per scanner per day, fewer repeats due to motion, better tolerance for claustrophobic, paediatric or acutely ill patients, and lower dose for repeat imaging.
  • Open research base: the fastMRI initiative (NYU Langone and Meta AI) released raw k-space data and challenges that standardised the field [4][5].

Variants

  • MRI: accelerated knee, brain, spine, cardiac and prostate protocols; 3D and multi-contrast sequences; low-field MRI where DLR compensates for low SNR.
  • CT: deep-learning image reconstruction (DLIR) for low-dose chest, abdomen, paediatric and cardiac CT; photon-counting CT denoising.
  • PET/PET-CT: shorter acquisitions or lower tracer activity via denoising.
  • Research-only: end-to-end unrolled networks and diffusion-based priors on public datasets.
  • Adjacent: purely post-hoc denoising or super-resolution of already reconstructed images is a separate, simpler product class; consumer upscaling is GEN-011 and is not medical.

How it works

  1. patient positioning + protocol (undersampled sequence / low-dose technique)
  2. raw data acquisition (multi-coil k-space | CT projections | PET events)
  3. data consistency + DL reconstruction network on the scanner's recon computer/GPU
  4. optional denoise / sharpen / super-resolution stage
  5. DICOM images + QA metrics
  6. PACS
  7. radiologist/technologist review (repeat or fall back to conventional recon if needed)
  • Core models: unrolled optimisation networks (variational network, E2E-VarNet style) that alternate CNN regularisers with a data-consistency step against the measured raw data; U-Net/ transformer denoisers for CT/PET; increasingly diffusion or score-based priors in research.
  • Data consistency is the safety lever: the output must remain faithful to measured data, not just look plausible.
  • Human-in-the-loop: technologist checks image quality at the console; radiologists read the images and can request a conventional reconstruction; the protocol is approved by the medical physicist and chief radiologist.

Data preparation

Reconstruction runs inside the scanner on raw data (k-space, sinograms), so there is practically no data preparation on the customer side. The vendor trained the model. What the clinic prepares is the acceptance and validation data: reference protocols, phantom scans, and a set of comparison exams in the PACS.

Typical gaps: protocols that differ between scanners and sites, missing documentation of which sequence uses which reconstruction, and raw data that is deleted after a few days, so side-by-side comparison is impossible later. Access rights to the scanner console and PACS are often shared accounts.

Preparation steps: (1) document the current protocols and image-quality criteria per examination; (2) agree with the vendor on phantom measurements and acceptance tests; (3) select 20 to 30 patient exams for blinded comparison of conventional and AI reconstruction by two radiologists, see PREP-018; (4) keep raw data for the validation period; (5) clean up user accounts, see PREP-023.

Rough share of effort: below 10 percent of the total, mostly radiologist and physicist time for validation. No tools beyond PACS, the scanner console and a reading-comparison sheet. See GUIDE-003 for a short readiness check.

Implementation paths

Which path for whom

  • Enterprise (hospital groups, radiology practices, imaging centres): Path A, because deep-learning reconstruction is a scanner-vendor feature, already CE-marked and tuned to the specific hardware; it cannot be added from outside.
  • Developer: Path C, because open reconstruction research (fastMRI, MONAI, PyTorch toolkits) fits method development and validation, not clinical use.
  • Public (university hospitals, municipal clinics): Path A as part of scanner procurement, with the AI licence written into the tender, because certified products are the only clinically usable route.

Path A — Buy (default and almost the only clinical option)

  • Scanner OEM features, certified with the modality: Siemens Healthineers Deep Resolve (MRI) and Deep Resolve in CT; GE HealthCare AIR Recon DL (MRI) and TrueFidelity DL (CT); Philips SmartSpeed Precise (MRI) and Precise Image (CT); Canon Healthcare Advanced Intelligent Clear-IQ Engine (AiCE); United Imaging uAI-based reconstruction; Siemens/GE/Philips/Canon DLR for PET. Siemens Healthineers (DE) and Philips (NL) are European manufacturers.
  • Vendor-neutral add-ons: SubtlePET/SubtleMR (Subtle Medical), AIRS Medical SwiftMR, ClariPi (CT denoising), Hyperfine for portable low-field MRI. Verify the CE mark and the scanner compatibility.
  • Choose A when: you operate clinical scanners. Purchase decision is a modality purchase or software upgrade, with an application-specialist-led protocol rollout.

Path B — Build on cloud APIs

Not applicable for the reconstruction itself: raw data volume, latency and medical-device certification make cloud APIs unsuitable. Cloud is useful only for downstream QA analytics and research on de-identified data (e.g. EU-region object storage, MLflow, MONAI Deploy).

Path C — Self-host (open source, research and validation only)

  • Open frameworks: fastMRI reference code (PyTorch), MONAI (incl. MONAI Reconstruction), BART toolbox for classical and learned reconstruction, SigPy, ODL/TomoSAM-style tools, TIGRE and CIL for CT, STIR/PyTomography for PET, ISMRMRD for raw-data exchange, Gadgetron for in-line recon.
  • Use: method evaluation, phantom studies, benchmarking against vendor DLR, teaching. Using such models on patients makes you the manufacturer of a medical device (see Risks).
  • Hardware: HW3 (one 48-141 GB GPU) for 3D multi-coil training/inference; HW2 for 2D research.

Path D — Custom training

Worthwhile for scanner manufacturers, research groups and device start-ups. Needs large sets of fully sampled raw data across sequences, field strengths and coils, ideally via federated or consortium arrangements, plus phantom and clinical reader studies and an MDR-compliant quality management system (ISO 13485, IEC 62304).

State of the art (2026)

  • Standard of care in new scanners: all major vendors ship DLR as a default or optional licence; newer generations pair it with AI-assisted acquisition (auto-positioning, motion correction).
  • Research frontier: unrolled networks remain the benchmark in the fastMRI challenges [5]; generative priors (diffusion) and foundation-style models promise higher acceleration and generalisation across anatomies and scanners.
  • Evidence: reader studies generally show non-inferior diagnostic quality at shorter scan times for common protocols, but evidence on small or subtle lesions and rare pathologies is thinner.
  • Limits and failure modes: DLR can create plausible but false structures (hallucination) or remove small real ones, especially with strong acceleration, unseen pathology, metal implants or out-of-distribution coils/sequences; reconstruction networks can be unstable to small perturbations [6]. Smoothed "plastic" texture can alter radiomics features and quantitative measurements (volumetry, perfusion, SUV), so longitudinal comparisons across protocols need care.

Shared resources & combinations

  • Downstream interpretation: HLTH-001 radiology AI works on the reconstructed images; check that models were validated on DLR-processed data, since texture statistics differ.
  • HLTH-021 radiotherapy contouring and planning uses CT/MRI with their own dose/geometry requirements; DLR must not distort geometry.
  • HLTH-024 ultrasound AI shares the idea of AI at the point of acquisition.
  • HLTH-004 decision support consumes imaging findings downstream.
  • Shared stack: GPU recon servers, DICOM/PACS, ISMRMRD, MONAI, MLOps for drift monitoring.

Effort, cost & KPIs

  • Path A: software licence or part of a scanner purchase; weeks to months for protocol optimisation, reader sign-off and technologist training. Cost drivers: licence per system/sequence, GPU recon hardware, physics QA time.
  • Path C/D: many months to years; large data-curation, regulatory and clinical-validation effort.
  • KPIs: minutes per exam, exams per scanner-day, repeat/motion-rework rate, CT dose (DLP, CTDIvol) and PET activity, image-quality scores (reader Likert, SNR, SSIM on phantoms), diagnostic concordance with conventional protocol, patient wait times.

People & change

Involve management for the licence and scanner budget, and the head of radiology as process owner. Radiologists and radiographers (MTRA) are the users; the medical physicist signs off the protocols. IT and IT security cover the scanner network, and the data protection officer (DPO) is informed because patient images are processed, although the processing stays inside the existing clinical systems.

Works council: usually no. The reconstruction runs in the scanner and does not evaluate staff behaviour, so §87(1) no. 6 BetrVG is normally not triggered. It becomes relevant if the vendor adds usage dashboards that log individual operators or reading times; then ask the works council or Personalrat. §90(1) no. 3 still calls for timely information when work processes (protocols, throughput) change.

Data protection: patient data are special-category data, but the processing is covered by the treatment purpose; check whether remote vendor service gets access to images and sign an AVV (Art. 28 GDPR). A DPIA is rarely new, update the existing records.

AI literacy: support staff literacy under Art. 4 AI Act; teach radiologists the typical artefacts of deep-learning reconstruction (smoothing, hallucinated detail) and radiographers the new protocols. Communicate the benefit: shorter exams, less dose. Pilot with one scanner and one body region, and keep the conventional reconstruction available as fallback.

Guides: GUIDE-006, GUIDE-009, GUIDE-014.

Risks, regulation & compliance

  • EU AI Act: reconstruction software is a medical device (or a component of one) under MDR (EU) 2017/745 requiring notified-body assessment, so it is a high-risk AI system via Art. 6(1) and Annex I; AI Act requirements are integrated into the conformity assessment and apply to such products on the extended Annex I timeline (2 Aug 2028, deferred from Aug 2027 by the Digital Omnibus on AI, Reg. (EU) 2026/1744) [7][8]. Not a prohibited practice under Art. 5.
  • MDR/IVDR: the DLR claim (dose or time reduction at equivalent diagnostic quality) must be backed by clinical evaluation; changes to the algorithm or training data may be significant changes. Healthcare institutions using a model off-label or in-house fall under MDR Art. 5(5) conditions.
  • GDPR: raw data and images are special-category health data (Art. 9); training or vendor service/remote-support access needs a legal basis, DPA, and de-identification. EHDS will shape secondary use of imaging data.
  • Radiation protection: dose reduction must follow EU Euratom Directive 2013/59 optimisation and diagnostic reference levels; changing protocols needs physicist sign-off.
  • Mitigations: phantom-based acceptance and constancy tests, side-by-side conventional recon retained for a transition period, reader studies on local case mix, post-market drift monitoring, vendor incident reporting, documentation of reconstruction type in DICOM metadata.

Getting started

  1. Inventory scanner models and software versions; ask vendors which DLR options are CE-marked for them and what sequences/regions are covered.
  2. Define 2-3 high-volume protocols (e.g. knee, lumbar spine, low-dose chest CT) as pilots.
  3. Run phantom tests and a local reader study comparing conventional and DLR protocols.
  4. Update protocols, technologist training, QA schedules and DICOM tagging; inform downstream AI vendors.
  5. Track time, dose and repeat rates monthly; review incidents with the vendor.

Sources

  1. Siemens Healthineers — Deep Resolve — https://www.siemens-healthineers.com/en-us/magnetic-resonance-imaging/technologies-and-innovations/deep-resolve
  2. GE HealthCare — AIR Recon DL — https://www.gehealthcare.com/en/campaigns/air-recon-dl
  3. Philips — SmartSpeed MRI acceleration — https://www.usa.philips.com/healthcare/technology/smartspeed-ai
  4. Zbontar et al. — fastMRI: An Open Dataset and Benchmarks for Accelerated MRI — https://arxiv.org/abs/1811.08839
  5. Muckley et al. — Results of the 2020 fastMRI Challenge for Machine Learning MR Image Reconstruction — https://arxiv.org/abs/2012.06318
  6. Antun et al. — On instabilities of deep learning in image reconstruction — PNAS 2020 — https://www.pnas.org/doi/10.1073/pnas.1907377117
  7. Regulation (EU) 2017/745 (MDR) — https://eur-lex.europa.eu/eli/reg/2017/745/oj
  8. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
  9. MONAI — https://monai.io