DICOM Image Generation Modules for Visualising AI Findings

Summary

We build DICOM image generation modules that turn the output of diagnostic AI into something a radiologist can read on the image itself. The module takes the original study and the model output, renders findings onto the pixel data with contours around regions of interest and a label carrying the analysis result, and writes the annotated result back out as a valid DICOM object that behaves normally in any viewer. This kind of engagement covers rendering, DICOM object construction, archive integration and the regulated development process around it.

The Challenge

Findings returned as text are usable but inconvenient, because a reader has to translate a written description back onto the image mentally. Closing that gap correctly is harder than it looks. Model output is typically expressed in pixel or normalised coordinates against a preprocessed input that may have been resampled, cropped or reoriented relative to the stored image; mapping back incorrectly produces contours that sit convincingly in the wrong place, which is worse than no contour at all. Multi-frame and multi-slice studies add per-frame handling.

Metadata correctness is equally unforgiving. An object with an invalid or duplicated identifier, or one written into the original series, can overwrite or masquerade as the acquisition itself. Conformance in the field varies considerably between viewers and archives, so transfer syntax negotiation and association behaviour cannot be assumed. Software that contributes to diagnosis is generally regulated as software as a medical device, so the documentation trail is part of development rather than a step after it.

The Solution

Generation flow

A study is uploaded, the analysis engine produces findings with coordinates, and the module converts the source image into a renderable representation, applies overlays and re-encodes. Using DICOM Secondary Capture for the generated object preserves visual quality while producing something every viewer and archive accepts.

Object construction and rendering

• The new object receives its own SOP Instance UID while remaining attached to the correct study and, where appropriate, a new series, so it never overwrites the original acquisition.
• Patient identifiers, study and series descriptions, referenced image sequences and image orientation are carried through consistently.
• Window and level handling is applied deliberately, so burned-in annotation stays legible without misrepresenting the underlying grayscale.
• Coordinate spaces are mapped explicitly from the model input back to stored pixel space, including any resampling, cropping or reorientation.

Archive integration and routing

Generated images are of little use if a physician has to download and re-upload them. The module integrates with the picture archiving and communication system through DICOM network services, acting as a C-STORE service user so results reach the hospital archive directly, typically behind an internal API so sending behaviour can be configured per site. Practical work includes negotiating transfer syntaxes the destination accepts, handling association limits and timeouts, retry and queueing when the archive is unavailable, and agreeing series descriptions so the annotated series is easy to find alongside the original.

Regulatory and safety design

Development follows a quality management system aligned to ISO 13485 and a software lifecycle aligned to IEC 62304, with requirements traceability, software architecture, risk management including hazard analysis, verification records and release documentation produced as the work proceeds rather than reconstructed afterwards. Where the software is used in Europe, personal data handling shapes storage, logging, transfer and anonymisation. Safety design also covers misuse: every output carries a clear marking that it represents an algorithmic assumption requiring clinical confirmation, rendered so it cannot be cropped away unnoticed, and failure behaviour is explicit, so when confidence is unavailable or rendering fails the module produces no annotated image rather than a partial one.

How we staff and verify it

We work with senior engineers experienced in medical imaging libraries and DICOM toolkits, plus quality assurance familiar with regulated software testing, integrating into an existing product team. Verification uses anonymised reference studies across modalities and vendors.

What This Delivers

Findings appear where they belong, on the image, in the viewer the reader already uses, with no export or re-import step. Annotated series arrive in the archive alongside the original acquisition and are unmistakably identified as algorithmic assumptions awaiting clinical confirmation. The regulated documentation set exists as a by-product of building the module, so a submission is assembled from work already done.

Technologies and Tools

Python with established medical imaging libraries and DICOM toolkits; DICOM Secondary Capture objects and DICOM network services including C-STORE for archive integration; and a development process aligned to ISO 13485 and IEC 62304.