Inferensys

Glossary

DICOM De-identification Profile

A DICOM De-identification Profile is a standardized set of rules defined in DICOM Part 15 for systematically removing or modifying Protected Health Information (PHI) from DICOM headers and pixel data to create compliant, anonymized data sets for research and secondary use.
Stylish WeWork-like workspace with hot desks and document wall, professional searching through enterprise knowledge base on a mounted ultrawide display, warm industrial pendants overhead.
PRIVACY COMPLIANCE

What is DICOM De-identification Profile?

A DICOM De-identification Profile is a standardized set of rules defined in DICOM Part 15 for removing or modifying Protected Health Information (PHI) from DICOM headers and pixel data to create anonymized data sets for secondary use.

A DICOM De-identification Profile is a formally defined specification in DICOM Part 15 that dictates exactly which data elements must be removed, modified, or retained to eliminate Protected Health Information (PHI) from a DICOM data set. The most common profile, the Basic Application Level Confidentiality Profile, specifies the de-identification of all attributes listed in the DICOM PS3.15 Table E.1-1, including Patient Name (0010,0010) and Patient ID (0010,0020), while retaining clinically relevant, non-identifying technical parameters.

Compliant de-identification requires more than header scrubbing; it must address burned-in annotations in pixel data and clean private tags. The profile defines a structured method using a Confidentiality Code for each attribute, where codes like U (replace with UID) and Z (zero out) specify the action. This ensures a deterministic, reproducible process for creating HIPAA-compliant Safe Harbor data sets for research and algorithm training.

DICOM PART 15

Core Characteristics of a De-identification Profile

A DICOM de-identification profile is a standardized set of rules defining exactly which data elements must be removed, modified, or retained to create a safe, anonymized data set for research or secondary use.

02

Clean Pixel Data: Beyond the Header

De-identification is not limited to DICOM tags. A robust profile must address burned-in annotations and encapsulated documents:

  • Burned-in Annotation Recognition: Algorithms must detect text or graphics rendered directly into the pixel data, such as patient names on ultrasound screens
  • Modality LUT Removal: Look-Up Tables embedded in private tags can contain identifying calibration data and must be stripped
  • Encapsulated PDFs: Structured reports or scanned documents embedded within the DICOM object must be parsed and redacted separately Failure to clean pixel data is a primary cause of re-identification in public datasets.
03

Handling Private Attributes

Medical device vendors often store proprietary information in Private Tags (odd group numbers like 0009,xx10). A safe de-identification profile must:

  • Block all private tags by default unless they are explicitly known to be safe
  • Maintain a Private Block Map that identifies which reservation blocks have been removed
  • Recognize that private tags can recursively contain Patient Identification data in custom formats Simply ignoring odd-numbered groups is insufficient; a strict allow-list or complete removal strategy is required.
04

Longitudinal Consistency: Pseudonymization

For clinical trials, simply removing a Patient ID breaks the ability to track a patient over time. A pseudonymization strategy replaces the real ID with a Study-level or Patient-level pseudonym:

  • A one-way cryptographic hash (e.g., SHA-256) of the real Patient ID ensures consistent mapping
  • The Patient ID (0010,0020) is replaced, not removed, preserving the relational model
  • Date shifting applies a random but consistent offset to all dates, preserving intervals while hiding absolute chronology This allows longitudinal analysis without exposing the original identity.
05

Retaining Safe Clinical Context

Aggressive de-identification can strip clinically vital information. A well-designed profile retains Safe Attributes that are essential for diagnostic algorithm training:

  • Patient's Age (derived from Date of Birth, then the birth date is removed)
  • Patient's Sex (0010,0040)
  • Study Description (0008,1030) and Series Description (0008,103E)
  • Image Pixel Data (7FE0,0010) after burned-in annotation removal
  • Acquisition Parameters (kVp, mAs, Slice Thickness) which have no identifying power The goal is to maximize data utility while minimizing re-identification risk.
06

The Clean Descriptor Option

DICOM Part 15 defines a Clean Descriptor Option for attributes like Study Description (0008,1030) and Series Description (0008,103E). Instead of blanking these fields, which can break downstream analysis, the profile can:

  • Replace free-text descriptions with standardized, coded terms
  • Map verbose institutional protocol names to generic anatomical descriptions
  • Retain the clinical meaning while removing potential identifiers like technician initials or department codes This preserves the semantic value of the data for machine learning pipelines.
DICOM DE-IDENTIFICATION

Frequently Asked Questions

Clear answers to the most common technical questions about applying the DICOM Part 15 standard to create compliant, anonymized data sets for research and development.

A DICOM De-identification Profile is a precisely defined, standardized set of rules from DICOM Part 15 that specifies exactly which data elements must be removed or modified to eliminate Protected Health Information (PHI) from medical images. It is necessary because simple ad-hoc scrubbing of patient names is insufficient and dangerous; DICOM files contain thousands of potential PHI locations, including private tags, UIDs, and free-text fields. A formal profile ensures consistent, auditable anonymization that satisfies legal frameworks like HIPAA and the GDPR by addressing all 18 HIPAA identifiers, preventing re-identification through quasi-identifiers such as study dates or institution names, and providing a defensible methodology for creating research cohorts.

Prasad Kumkar

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.