DICOM guide — PENRA Courses

What DICOM is

DICOM (Digital Imaging and Communications in Medicine) is the international standard for storing and exchanging medical images. A DICOM file is more than a picture: it contains the pixel data for one image and a header of tagged metadata describing the patient, study, acquisition and image geometry.

Files often use a .dcm extension, but the extension is not authoritative: some systems export DICOM files with no extension or with .ima. The platform identifies DICOM by parsing the file, not by its name.

One file is usually one image. A CT or MRI examination is normally many DICOM files — one per slice — grouped into a series.

Footnote — multiframe and enhanced objects: some DICOM files carry many frames in a single object (multiframe enhanced CT/MR, ultrasound cine loops, angiography and some secondary captures). The Atlas stores the file as one instance and does not split those frames into separate slices; where you need a scrollable stack, export single-frame images rather than a multiframe object.

Study hierarchy

DICOM groups images into four levels. The Atlas follows the same structure:

Level	Meaning	In the Atlas
Patient	One person, identified by a Patient ID and name in the header.	Not displayed. Cases are written up without patient identifiers.
Study	One imaging encounter, identified by a Study Instance UID.	Used to group uploads so related series can be imported together.
Series	Images from one modality, body part and acquisition, identified by a Series Instance UID.	A Series record; the stack you view in the viewer.
Instance	One image/slice, identified by a SOP Instance UID.	A `SeriesImage` row and the stored image file.

A case combines one or more series with the clinical write-up (history, description, report, diagnosis and differential).

What data we read from DICOM

When a file is uploaded, the platform parses its header. A deliberately small set of values is used to organise the upload and build the series:

Header field	How it is used
`StudyInstanceUID`, `SeriesInstanceUID`, `SOPInstanceUID`	Identifies and groups the images; detects duplicates and supports content transfer.
Study Description, Series Description, Protocol Name	Suggests the examination and the series name shown in the Atlas.
Modality, Body Part Examined	Populates the modality and examination metadata.
Slice Thickness, Series Number	Series metadata and ordering.
Study Date / Series Date	Used for display dates and study-date ordering; never shown as a patient identifier.
Image Orientation Patient	Infers the imaging plane (axial, coronal, sagittal).
Contrast Bolus Agent	Records whether contrast was used.
Patient ID	Retained only on the pending-upload record to help group images from the same patient; it is not shown in cases or to learners.

Each stored image also keeps the tags the web viewer needs: rows/columns, pixel spacing and representation, window centre/width, photometric interpretation, image position/orientation, frame of reference, instance number and SOP class. These are technical values, not clinical free text.

Images and ordering

Pixel data is decoded and converted into images the browser can display. That is how the built-in viewer provides windowing, scrolling and measurement. A pixel hash is also calculated so the same file cannot be imported twice.

Slices are ordered using their position in space — normally ImagePositionPatient / SliceLocation, falling back to InstanceNumber. If a stack jumps while scrolling, reorder it by slice location from the series or case page (see ordering images).

Images may be downsampled to keep storage and loading times reasonable; the original pixel hash is retained for duplicate detection.

Linking cases and series automatically

The DICOM hierarchy is what lets the Atlas connect uploads to the right records without manual matching:

Series → series UID. Images sharing a SeriesInstanceUID are imported into one Series record, and the series is attached to a case. Re-uploading the same study can therefore be attached to the existing case rather than creating a duplicate.
Study → case. Uploads are grouped by StudyInstanceUID. Import as case series creates one case per selected study, reads each study's date from the DICOM headers (StudyDate, falling back to AcquisitionDate or SeriesDate), and links the new cases in the order they are selected/imported using the previous_case relationship.
Linked-case navigation. The previous/next links on a case come from that chain, so readers can move through a patient's studies in order. You can still edit the link manually on a case.
Continuation imports. If part of a study was imported before, the Uploads page detects it from the study UID and offers Import remaining N series / Finish these imports for the existing case.

Within a series, image order is separate: slices are sorted by their position in space (or instance number) — see Images and ordering.

Anonymisation and safety checks

Uploaded series are checked automatically before they are used. The checks are advisory and are not a substitute for proper local de-identification.

Header scan — looks for real identifiers in text fields: valid NHS numbers, identifiers beginning with a known ODS site code, and text inside encapsulated documents. Synthetic/random values written by a de-identification tool are ignored.
Pixel scan — samples images and runs OCR to find burned-in names, addresses, hospital numbers, dates and NHS/ODS identifiers.
De-facing — head imaging can be pixel de-faced to reduce the risk of re-identification from facial reconstruction. The technique and parameters are recorded on the series.

A series with findings is flagged and withheld from learners until it is reviewed and cleared; a series whose checks have not run stays in the “unknown” state rather than being treated as identified. Staff can review flags from the Atlas PHI flags page.

Uploading DICOM

The uploader tool exports, anonymises and uploads whole cases from Insignia Insight. If you already have anonymised DICOM, use the web upload page. Uploaded files wait under Uploads until you import them into a series and case.

JPG/PNG images can also be uploaded, but they carry no DICOM header or pixel metadata, so windowing and automatic ordering are limited and the anonymisation header checks do not apply.

Limitations and good practice

Always de-identify at source where possible; the automated checks are a safety net, not a guarantee.
Check a newly imported case in the viewer before publishing it.
Use series descriptions that make sense to learners — they become the stack names.
If a stack is out of order, reorder by slice location before writing up the case.
Report suspected identifying content through the case feedback option or to the platform administrator.

Looking for the import workflow? See the guided walkthroughs and the Atlas help.