The DICOM file (.dcm, .dicom)

DICOM, Digital Imaging and Communications in Medicine, is the international standard for medical images. It defines both a file format and network protocols, which is why scanners, workstations and hospital archives (PACS) from different manufacturers can exchange images. A .dcm file is one DICOM object: usually one image, such as one slice of a CT scan, one X-ray or one ultrasound frame, but it can also be a multi-frame image, a video, a report or a radiotherapy plan.

The standard began in 1983, when the American College of Radiology and the National Electrical Manufacturers Association (NEMA) formed a committee. Their first standard, ACR-NEMA 300, appeared in 1985 and connected devices point to point over a dedicated 16-bit parallel interface; a second version followed in 1988. The third version, in 1993, moved to TCP/IP networks and was renamed DICOM. NEMA remains the secretariat, and the standard, published as PS3, is revised several times a year.

A DICOM file is always both picture and record. Next to the pixels it carries who the patient is, when and where the scan was made, with which machine and settings, and how the pixels should be shown. That makes DICOM files useful, and sensitive.

• A scan is many files. A CT or MRI study is usually hundreds of .dcm files, one per slice, grouped into series. Viewers put them back together.
• Files from a hospital disc often have names like IM000001 and no extension. Part 10 of the standard limits each part of a file name on such media to 8 characters; the DICOMDIR file at the top of the disc is the index.
• Not a picture format. Pixels are often 12 or 16 bits with a meaning (in CT, Hounsfield units), and a viewer must apply window settings to turn them into a grey image on screen.

Everything in a DICOM data set, from the patient's name to the pixels, is a data element:

In implicit VR encoding the VR is left out and the reader looks it up in the data dictionary by tag. Elements with an odd group number are private: manufacturers use them for their own data, and their meaning is documented, if at all, in the vendor's conformance statement.

If a viewer opens the header but shows no image, it usually doesn't support the transfer syntax. Converting to an uncompressed one, for example with DCMTK or pydicom, usually fixes it.

The standard has a method for this. PS3.15 Annex E defines attribute confidentiality profiles: a table of every attribute that can identify someone and what to do with it, removing it (X), emptying it (Z), replacing it with a dummy value (D), replacing a UID consistently (U), keeping it (K) or cleaning it (C). Options cover cases such as keeping dates for longitudinal studies or cleaning descriptions. A de-identifier also records what it did, in Patient Identity Removed (0012,0062) and De-identification Method (0012,0063).

• The header is only half the job. Names and dates can be burned into the pixels themselves, for example on ultrasound screenshots or scanned documents. Annex E requires that burned-in identifying text is removed too (its Clean Pixel Data option) and that overlays and graphics are cleaned.
• Private tags can hold anything. The basic profile removes them unless they're known to be safe.
• Faces can be reconstructed from head CT and MRI scans with 3D rendering. Removing the name alone doesn't make such a scan anonymous.
• Annex E itself warns that following a profile is part of a de-identification process, not a replacement for one, and doesn't guarantee confidentiality.

Many viewers and research platforms have an anonymise function, and libraries such as pydicom and DCMTK can script the changes. Whatever you use, check the result in a viewer that shows every tag, and look at the images themselves.

A disc from a hospital often includes a viewer, which may only run on Windows. Free and paid alternatives:

• Open a whole disc, not single files: point the viewer at the folder or the DICOMDIR so it can group slices into series.
• Adjust window and level (contrast and brightness) to see different tissues. CT values range over thousands of units; a screen shows 256 greys at a time.
• In Python: pydicom.dcmread("image.dcm") reads the file; print it to see every element, and .pixel_array gives the pixels as a NumPy array.
• ImageMagick can read DICOM images (magick image.dcm image.png), but it can't write DICOM, and 12- or 16-bit images may come out too dark or washed out without the right window.

Inside hospitals, DICOM files traditionally travel over DICOM's own network protocol. DICOMweb, defined in part 18 of the standard, is a set of RESTful web services for the same job:

Metadata can be returned as JSON or XML instead of binary. Many web-based viewers and cloud imaging archives are built on DICOMweb, which is how a radiologist can look at a study in a browser without a .dcm file ever being downloaded as such. A browser can't open a .dcm file by itself.

• From a viewer: most viewers export the current image, with the window you set, as JPEG or PNG, and some export a series as a video. This is the easiest route for a presentation.
• With ImageMagick: magick image.dcm -auto-level image.png. Fine for a quick look; it doesn't apply DICOM window settings.
• With pydicom: read the file, apply the rescale slope and intercept (0028,1053 and 0028,1052) and the window you want, then save with Pillow. This gives you control over exactly what's shown.
• For research, many pipelines convert whole series to volume formats such as NIfTI, with tools like dcm2niix.

Exported JPEG or PNG files contain no DICOM header, but they can still identify someone: text burned into the image, or a face in a 3D rendering. Look at the image before sharing it.

• Polyglot files. Because the 128-byte preamble may contain anything, a file can be a valid DICOM image and a working Windows or Linux program at the same time (CVE-2019-11687). Opening it in a viewer doesn't run it, but such a file can carry malware past filters that trust medical images. Mail and upload filters should scan DICOM files like any other executable content and check what the preamble holds.
• Parser bugs. DICOM is large and complex, and viewers and libraries have had vulnerabilities triggered by malformed files. Keep viewers updated.
• Discs with autorun viewers. Viewers on hospital discs are programs. Open discs from a source you trust, or copy the image files and use your own viewer.
• Privacy is the main risk. A DICOM file in the wrong place is a data breach. Store and send them encrypted, and de-identify before sharing.