DICOM tags explained: the patient, study, series and image attributes, and the ones that matter for de-identification

Short answer: every DICOM object (an image, a report, a dose record) is a list of data elements, each identified by a tag: a group number and an element number, written as four hex digits each, such as (0010,0010) for Patient's Name. Each element has a value representation (VR) that says what kind of data it holds (text, date, UID, integer, binary) and then the value itself. The pixels are just one more element, (7FE0,0010) Pixel Data. The full dictionary is Part 6 of the standard, with about 5,000 public tags; vendors may add private tags with odd group numbers.

The levels

DICOM tags are organised into four levels matching the DICOM hierarchy: patient (name, ID, birth date, sex), study (Study Instance UID, date, accession number, description, referring physician), series (Series Instance UID, modality, body part) and image (SOP Instance UID, SOP Class UID, rows, columns, bits, window settings, pixel data). Every file repeats the values of all four levels.

DICOM groups the attributes by the level of the hierarchy they describe. The same values are repeated in every file of a study, which is why a single image can be filed correctly on its own.

Value representations

A DICOM value representation (VR) is a two-letter code telling software how to read an element's bytes: PN for person names, LO and SH for strings, CS for code strings, DA, TM and DT for dates and times, UI for unique identifiers, IS and DS for numeric strings, US for unsigned shorts, SQ for sequences, OB or OW for binary.

The VR tells software how to read the bytes. The common ones: PN person name (components separated by ^: family^given^middle^prefix^suffix); LO long string; SH short string; CS code string (uppercase, from a fixed list); DA date YYYYMMDD; TM time; DT date-time; UI unique identifier (dotted numbers, max 64 characters); IS integer string; DS decimal string; US unsigned short; SQ sequence, a nested list of further data elements; OB/OW other byte or word, raw binary. In DICOMweb JSON, each attribute is written as {"vr": "PN", "Value": [...]}, as shown in DICOMweb explained.

UIDs: the identifiers that must not change

The DICOM Study, Series and SOP Instance UIDs are globally unique identifiers generated by the scanner under the manufacturer's registered root and reused by the PACS index, the FHIR ImagingStudy and DICOMweb URLs. They must never be rewritten inconsistently, or the study falls apart. The SOP Class UID, by contrast, identifies the kind of object, not the image.

The three UIDs (study, series, instance) are the only globally unique identifiers in the system. They are generated by the scanner under the manufacturer's registered root and are reused everywhere: the PACS index, the FHIR ImagingStudy, the DICOMweb URL. If a tool rewrites them inconsistently (de-identifying one file but not its neighbour), the study falls apart. The SOP Class UID is different: it is not an identifier of this image but of the kind of object (CT image, MR image, Structured Report), fixed by the standard.

Tags that carry personal data

The DICOM tags that carry personal data are listed in Part 15, Annex E of the standard, the Basic Application Level Confidentiality Profile: patient name, ID, birth date, address and telephone, physician and institution names, device serial numbers, dates and times at every level, free-text descriptions, private tags, nested sequences holding identifiers, and text burned into the pixels.

Part 15, Annex E of the standard defines the Basic Application Level Confidentiality Profile: a list of attributes that identify the patient, the clinicians or the institution, with an action for each (remove, replace with a dummy, keep, clean). The obvious ones are the patient name, ID, birth date, address and telephone, the physicians' names, the institution name and address, and the device serial number. Less obvious:

• Dates and times at every level (study, series, acquisition, content), which are shifted or removed depending on the research need;
• Free-text fields (Study Description, Image Comments, Protocol Name) that technologists sometimes fill with names;
• Private tags, whose meaning only the vendor knows; the safe default is to remove them;
• Burned-in annotations: text drawn into the pixels themselves (ultrasound and some screenshots), flagged by (0028,0301) Burned In Annotation and only removable by editing the image;
• Sequences such as Referenced Patient Sequence or Other Patient IDs, where identifiers hide inside nested elements.

Good de-identification tools follow Part 15, keep a mapping of old to new UIDs in a secure place and log what they changed. For the broader picture (HIPAA Safe Harbor, GDPR anonymisation and pseudonymisation), see De-identification of health data.

Reading a header yourself

You can read a DICOM header yourself with any DICOM viewer or with command-line tools such as dcmdump from DCMTK or pydicom in Python, which print the file as a list of tags. The header shows the patient name, birth date, study date and study description, so you can confirm that images obtained from a hospital are yours.

Any DICOM viewer shows the header; command-line tools (dcmdump from DCMTK, pydicom in Python) print it as a tag list. If you obtained your own images from a hospital, the header is where you confirm that the name, birth date and study date are yours and that the study description matches the exam you had. See How to get your CT or MRI images.

Related pages

• DICOMweb explained
• FHIR ImagingStudy vs DICOMweb
• PACS vs RIS vs VNA
• De-identification of health data
• How to get your CT or MRI images (DICOM)

Sources

• DICOM PS3.6: Data Dictionary
• DICOM PS3.5: Data Structures and Encoding (value representations)
• DICOM PS3.15 Annex E: Attribute Confidentiality Profiles
• DICOM PS3.3: Information Object Definitions
• pydicom documentation

Frequently asked questions

Why are tags written as (0010,0010) and also as 00100010?

They are the same thing: the group 0010 and the element 0010 in hexadecimal. The parenthesised form is used in documentation and viewers; the eight-digit form is used as the key in DICOMweb JSON.

What is a private tag?

An element defined by a vendor rather than the standard, in an odd-numbered group (for example (0009,xxxx) or (0029,xxxx)), with a private creator element that names the vendor block. Only that vendor's software knows the meaning; de-identification removes them by default.

Are DICOM tags the same as FHIR elements?

No. FHIR ImagingStudy carries a handful of them (the UIDs, modality, body site, counts, dates); the rest of the header stays in DICOM. The DICOM standard's Part 16 and the FHIR specification document the few mappings that exist.

Which tags do I need to find an image in an archive?

Patient ID or name to find the studies, then the Study Instance UID to retrieve the right one. QIDO-RS searches on exactly these; the series and instance UIDs come back in the response.

Anpheros Daily

Try it in Anpheros Daily

Keep your scan and test reports in one place in Anpheros Daily, ready to show at your next visit.

How it works in the app →

iPhone & MacAndroidOpen in your browser →

Written by

The Anpheros team

Anpheros builds a medical record that the patient controls and can share with any clinic, on an HL7 FHIR R4 platform, based in the EU. These guides help you understand and organise your health; they do not replace your doctor.

About Anpheros →

Anpheros

The more you log, the clearer your record

Your health history in one place, under your control.

Symptom diaryPatterns show over time

Emergency cardQR in your phone's Wallet

All your resultsLabs and reports together

You decideWho sees what, and for how long

Create your free account

Free · Works in your browser · No card