AI Medical Imaging

What is AI medical imaging?

AI medical imaging is software that analyzes medical images to triage urgent studies, detect or characterize findings, segment anatomy and automate measurements. In a hospital it sits between the modality, PACS and RIS: it receives studies over DICOM, takes order context from HL7 v2, and returns results as DICOM objects the radiologist reviews before signing.

Four functional classes of imaging AI

• Computer-aided triage and notification (CADt): Scores emergency or inpatient studies soon after acquisition and flags suspected findings such as intracranial hemorrhage, large-vessel occlusion, pulmonary embolism or pneumothorax so the worklist can reorder them.
• Computer-aided detection (CADe) and diagnosis (CADx): Marks regions of interest such as lung nodules, breast calcifications or colon polyps, and may add a characterization score for the reading physician.
• Quantitative segmentation and volumetry: Measures organ volumes, cardiac chamber function, tumor dimensions or bone density and exports the values as structured data for the report.
• Acquisition and reconstruction support: Runs on or near the scanner to check positioning, catch motion artifacts before the patient leaves the table, or denoise low-dose CT and accelerated MRI.

Which rules apply to imaging AI software?

Imaging AI falls under FDA device rules, the DICOM standard and HIPAA, and each one shapes a different part of the build. The manufacturer owns the FDA submission. The hospital and its vendors own the data path and the business associate contracts.

• FDA Criterion 1: FDA's final Clinical Decision Support Software guidance (January 2026) says software that acquires, processes or analyzes a medical image does not meet the first non-device CDS criterion, so image analysis for a clinical purpose is a device function.
• Change control: FDA's final guidance on Predetermined Change Control Plans for AI-enabled device software functions (December 2024) lets a manufacturer describe planned model modifications and how they will be validated in the marketing submission, so those changes do not each need a new submission.
• Cyber devices: Section 524B of the FD&C Act requires manufacturers of cyber devices to provide a software bill of materials, a plan to monitor and address postmarket vulnerabilities, and processes that give reasonable assurance of cybersecurity.
• De-identification: DICOM PS3.15 Annex E defines the Basic Application Level Confidentiality Profile and its options, which list the attributes to remove or replace when a study leaves the hospital.
• Cloud hosting: HHS guidance on HIPAA and cloud computing says a cloud provider that stores ePHI for a covered entity is a business associate even when it holds only encrypted data it cannot view.

FDA also publishes a list of AI-enabled medical devices authorized for marketing in the United States. A buyer can check a product's clearance and its indication there before any integration work starts, which avoids building a pipeline for a use the device was never cleared for.

How does an AI medical imaging pipeline work inside a hospital?

A study moves from the modality through routing, de-identification and inference, then back to PACS and RIS for the radiologist to review. The reader never has to open a separate browser tab to see the result.

• Stage 1, Acquisition and series routing: When a CT or MRI finishes, the modality or a PACS router sends the study to an edge gateway. The gateway reads DICOM attributes such as Modality, BodyPartExamined, SeriesDescription, SliceThickness and ConvolutionKernel, matches the Accession Number to the HL7 v2 ORM order, and forwards only the series the model accepts.
• Stage 2, De-identification, quality gate and inference: The gateway replaces identifying attributes under the PS3.15 profile the hospital chose, checks for burned-in text on ultrasound and secondary capture images, confirms the protocol is in scope, and runs inference on premises or in a BAA-covered cloud tenant.
• Stage 3, Results back to PACS and RIS: Results return as a DICOM Structured Report for measurements, a Segmentation object for masks, or a presentation state for marks on the image. An HL7 v2 ORU message or a FHIR R4 DiagnosticReport updates the worklist priority and can pre-fill measurement fields in the report template.
• Stage 4, Review and feedback: The radiologist views the native series with the AI layer toggled on or off, accepts or edits measurements, and signs. The accepted or rejected result is logged for postmarket performance monitoring.

Why reading-room integration decides adoption

A radiologist works from a PACS viewer, a worklist and speech recognition at the same time. A tool that needs its own login, a manual MRN search and its own image loading adds steps to every study, and readers stop opening it.

Results that arrive as DICOM objects appear where the reader already looks. The IHE AI Results (AIR) profile describes how AI output is encoded and displayed for exactly this reason.

What should the DICOM edge gateway handle?

The edge gateway decides which images reach the model and whether results find their way back, so it carries more failure risk than the model itself. A gateway that drops or mismatches studies creates silent gaps that nobody notices until a missed finding is reviewed.

• Transport: Accept DIMSE C-STORE from older modalities and DICOMweb STOW-RS from newer systems, and retrieve priors with C-MOVE or WADO-RS when the model compares studies over time.
• Series selection: Route by protocol rules, not by series number. Localizers, dose reports and bone reconstructions waste bandwidth when the model needs one soft-tissue axial series.
• Order matching: Pair each study with its HL7 v2 ORM by Accession Number, and handle ADT A40 merges so a result is not filed against a retired patient identifier.
• Pseudonymization map: Replace StudyInstanceUID, SeriesInstanceUID and PatientID with stable pseudonyms, and keep the lookup table inside the hospital boundary so the result can be re-linked locally.
• Buffering and retries: Queue studies during network outages, retry with backoff, and alert when a study waits longer than the agreed limit.
• Duplicates and resends: Detect a study sent twice by the modality, and decide whether a corrected resend replaces the earlier result or creates a new one.
• Conformance statement: Publish the SOP classes, transfer syntaxes and private tags the gateway supports, and test it against each PACS and vendor-neutral archive on site.

Steps from trained model to signed report

Putting imaging AI into production takes seven steps, and the order matters because later steps depend on decisions made early.

• 1. Define the task and the pathway: State whether the model triages, detects, measures or improves acquisition, and confirm the FDA pathway and predicate or De Novo plan with the manufacturer's regulatory lead.
• 2. Agree the turnaround target with the clinical owner: Triage only helps if the flag lands before the study is opened, so the department sets the target and the team measures against it.
• 3. Build the edge gateway: Implement transport, series rules, order matching, buffering and the pseudonymization map described above.
• 4. Implement de-identification and pixel scrubbing: Apply the chosen PS3.15 profile options and run text detection on frames that may carry burned-in annotations.
• 5. Package inference: Serve models in versioned containers, for example NVIDIA Triton or ONNX Runtime, and validate inputs so a non-contrast head CT model never scores a contrast neck series.
• 6. Produce standard outputs: Write measurements as DICOM SR using TID 1500, masks as DICOM SEG, and marks as presentation states, and map report fields to RadLex, SNOMED CT or LOINC codes.
• 7. Monitor after go-live: Track sensitivity, false-positive rate and accept or override rates by scanner model, protocol, site and patient group, and feed results to the manufacturer's postmarket process.

Where imaging AI deployments fail

The failure points below sit in the data path and the reading workflow rather than in model accuracy. Test for each one before a pilot widens.

• Single-site validation: A model validated on one institution's scanners can degrade on other manufacturers, reconstruction kernels or slice thicknesses.
• PHI left in the study: Removing PatientName while leaving institution names, accession numbers, private vendor tags or burned-in ultrasound text leaves identifiers in a study that was meant to be de-identified.
• Overwritten pixels: Writing marks into the original series instead of a separate object removes the radiologist's view of the native acquisition.
• Out-of-scope inputs: Scoring a study the model was not built for, instead of returning a clear out-of-scope status, produces confident output on the wrong data.
• Alert fatigue: A triage tool that flags too many normal studies teaches readers to ignore the priority icon.
• Late regulatory work: Writing the software lifecycle file, SBOM and validation plan after the model is built forces rework before submission.
• No feedback loop: Without comparing AI output to signed reports, nobody can show whether performance holds after a scanner upgrade.

What should a buyer ask an imaging AI vendor?

A buyer should ask for evidence that the product is cleared for the intended use and that it fits the hospital's imaging systems. This checklist covers the questions that change the integration plan.

• Clearance and indication: Which FDA authorization covers the product, and does the cleared indication match the planned body part, modality and patient group?
• Supported inputs: Which protocols, slice thicknesses and scanner models were validated, and what happens when a study falls outside them?
• Output objects: Does the product return DICOM SR, SEG and presentation states, or only secondary capture images that PACS cannot use as data?
• Change plan: Does the authorization include a PCCP, and how will the hospital be told when the model changes?
• Security file: Can the vendor share its SBOM and its process for postmarket vulnerabilities?
• Hosting and contracts: Will inference run on site or in the cloud, and will every party that touches ePHI sign a business associate agreement?
• Performance data: Will the vendor share per-site metrics so the hospital can compare them with its own signed reports?

How Agnotic can help

Imaging AI succeeds or stalls on the systems around the model, and those systems are what Agnotic Technologies builds for radiology AI vendors, medtech companies and hospital imaging teams: DICOM and DICOMweb edge gateways, PACS and vendor-neutral archive integration, HL7 v2 ORM and ORU feeds, FHIR R4 ImagingStudy and DiagnosticReport, and SR, SEG and presentation-state outputs.

For a device manufacturer, Agnotic engineers work inside the client's quality system and produce the software design, verification and traceability records its regulatory team needs. For a hospital, Agnotic builds the gateway, monitoring and HIPAA-ready hosting that let a cleared product run on local scanners.

Sources

• DICOM PS3.15 Annex E: Attribute Confidentiality Profiles
• FDA: Clinical Decision Support Software guidance (January 2026)
• FDA: Predetermined Change Control Plan for AI-Enabled Device Software Functions (final guidance)
• FDA: Artificial Intelligence-Enabled Medical Devices list
• FDA: Cybersecurity in Medical Devices, premarket guidance including section 524B
• HHS: Guidance on HIPAA and cloud computing
• HL7 FHIR R4: ImagingStudy resource