How to De-Identify DICOM Medical Images: Checklist

Create a separate export copy in an approved environment. Apply the current DICOM PS3.15 Basic Application Level Confidentiality Profile across every instance and nested sequence, choose the additional confidentiality options needed for the intended use, replace or remove identifying attributes, remap instance-related UIDs consistently, and process dates according to a documented rule. Then inspect pixel data, graphics, overlays, thumbnails, structured content, private attributes, file metadata, the preamble, and any DICOMDIR rather than assuming a cleaned header makes the study safe.

Run a second validation pass on the exported copy before release: parse the output with an independent tool, compare retained attributes with an approved allowlist, review rendered images for text and recognizable features, and confirm that series relationships and clinically necessary content still work. Keep the source in its governed clinical system; do not overwrite it. If the legal basis, intended recipient, residual risk, or required image content is unclear, pause the export for the responsible privacy, security, research, or information-governance review.

De-identification is a disclosure decision, not only a file transformation. Record why the images are being prepared, which images and associated objects are in scope, who will receive them, how they will be transferred, what clinical or research utility must remain, whether linkage across studies is required, and which law, consent, ethics approval, contract, and institutional policy apply. The DICOM standard explicitly says its confidentiality profiles do not replace this contextual risk assessment.

For United States HIPAA-regulated disclosures, HHS describes two routes for designating health information de-identified: Safe Harbor and Expert Determination. Safe Harbor removes specified identifiers and also requires no actual knowledge that the remaining information could identify the person; Expert Determination requires a qualified expert to find a very small risk for the anticipated recipient and document the methods and results. That HHS framework is jurisdiction-specific. It is not a universal permission to disclose images and does not replace stricter local or institutional rules.

Do not build a short deletion list around Patient Name and Patient ID. PS3.15 Table E.1-1 defines actions for a much wider set of standard attributes, including accession numbers, institution and personnel fields, free-text descriptions, dates, identifiers and references. Apply the rule recursively inside sequences, because an identifier or referenced UID can remain below the top level. Account for related objects such as presentation states, structured reports, waveforms, secondary captures and encapsulated content when they are part of the export.

For a conformant de-identified DICOM file, PS3.15 requires replacement of file meta information and the 128-byte preamble with information about the de-identifying application, because those locations can leak network, implementation or private information. It also specifies how DICOMDIR files and group 0004 elements are handled. Marking Patient Identity Removed as YES and recording the De-identification Method or coded method communicates what was attempted, but those attributes are documentation—not proof that every identifying value is gone.

• Enumerate every SOP instance and associated object received, processed, rejected and released.
• Apply rules to attributes at every nesting level, not only the displayed header panel in a viewer.
• Replace filenames, folder names, archive labels and transfer manifests that expose patient, facility or accession details.
• Regenerate a required DICOMDIR from the de-identified files; never ship an original directory beside cleaned instances.
• Treat embedded PDF, CDA, STL/OBJ or other encapsulated documents as separate content that may require replacement or a governed content-specific process.

Names, record numbers, dates, facilities, barcodes and annotations may be stored in Pixel Data rather than in editable text attributes. Ultrasound, screen captures, scanned films, endoscopy, ophthalmic photography and other secondary-capture workflows deserve particular attention, but modality assumptions are not validation. Inspect representative—and, for a release workflow, appropriately comprehensive—renderings at full resolution, across frames, cine loops, colour channels and alternate presentations.

The PS3.15 Clean Pixel Data Option requires identifying information burned into stored pixels to be removed and Burned In Annotation to be set to NO. The standard is explicit that placing an overlay, shutter or graphic over the text is insufficient because another receiver may ignore it; the stored pixel values themselves must be changed. OCR and automated region detection can help triage, but PS3.15 notes that identifying text can be difficult to distinguish from useful annotations and that human intervention or approval may be required.

Also inspect icon images, overlays, curves, graphic annotations, presentation states and thumbnails produced by a portal or export tool. A clean main image beside an original thumbnail or annotation object is still a disclosure. Confirm that redaction did not remove laterality, scale, orientation, measurement context or other information needed for the approved purpose, and quarantine a study if safe pixel editing would make it misleading or unusable.

Private attributes are vendor-defined and may contain patient demographics, site names, device identifiers, protocol text, reconstruction parameters or opaque binary content. Under the PS3.15 Basic Application Level Confidentiality Profile, private attributes are removed when the Retain Safe Private Option is not selected. Selecting that option does not mean keeping every private tag: only attributes known to be safe may be retained, with the required private creator information; the rest must be removed or processed using an applicable element-specific de-identification action.

Use a versioned, vendor- and modality-aware allowlist supported by current documentation and testing. The standard's sample safe-private table is not a blanket vendor guarantee, and software upgrades can change what is emitted. Parse private sequences recursively when content is not guaranteed safe. If a technically important private element cannot be understood, either remove it and test whether utility remains or obtain authoritative documentation and governance approval before retention.

Study, Series, SOP Instance, Frame of Reference and other instance-related UIDs can link an export back to the original PACS or another copy. The Basic Profile uses replacement UIDs and requires internal consistency: references between images, segmentations, measurements and presentation objects must still point to the corresponding replacement instances. Structural identifiers such as SOP Class UID serve a different purpose and should not be removed as though they identified a patient.

The Retain UIDs Option exists for uses where traceability provides enough benefit to justify the additional linkability risk. PS3.15 warns that UIDs can support identity recovery when an actor has the originals or the source database. It also warns against false confidence: retained pixel data may itself be matched with an original image even after UIDs change. Document the decision, scope of consistent remapping, mapping custody and destruction or retention rule; never expose a re-identification key with the released data.

Dates and times can make a study linkable, yet longitudinal analysis may depend on the intervals between scans, treatment, laboratory results or an index event. PS3.15 provides mutually exclusive options to retain full dates or retain modified dates. The modified-date option requires transformation that reduces matching risk while preserving the longitudinal relationships needed for the application. A consistent subject-level shift or controlled aggregation may be appropriate, but the rule must cover dates and times together, including events spanning midnight, and must not corrupt calculations such as dynamic imaging timing.

If HIPAA Safe Harbor is the chosen route, HHS says elements of dates directly related to an individual that are more specific than the year are not permitted, with special treatment for ages over 89. A date-shifted day and month therefore should not be assumed to satisfy Safe Harbor merely because it is no longer the real date. Expert Determination, another lawful basis or a limited-data-set arrangement may use a different governed analysis. Decide the legal route before choosing a DICOM date option, and check related reports, filenames and manifests for dates outside the image attributes.

Full-face photographs and comparable images are identifiers under the HIPAA Safe Harbor list. Beyond photography, high-resolution CT or MRI of the head and neck can support a facial surface reconstruction, and dental or other distinctive anatomy may be recognizable or matchable. Removing names and dates does not address this risk. Assess the anatomic coverage, resolution, intended recipient, available comparison data and whether multiple instances make reconstruction possible.

The PS3.15 Clean Recognizable Visual Features Option requires enough removal or distortion to prevent recognition and may require human review. Defacing, masking or other transformations can degrade anatomy and may invalidate morphometry, surgical planning, dental analysis or another approved use. Validate the transformed pixels for the intended technical purpose and record the trade-off. If both identifiability and the identifiable anatomy are essential, de-identification may be the wrong governance model; controlled access, consent or another approved safeguard may be required instead.

Treat successful completion by the de-identification tool as the start of release validation. Use a separate parser or viewer to enumerate remaining standard and private attributes, search string and person-name values, verify the profile's required actions, and render the actual exported objects. Check multi-frame instances, alternate windows, overlays, icons, presentation states, structured text and encapsulated objects. Sample-based review may miss a rare template or modality; the validation plan should reflect corpus variety and the consequence of a miss.

Keep a release record that can reproduce the transformation without copying patient identifiers into a second uncontrolled log. Record a job identifier, source system, intended use and recipient class, software and rule-set versions, DICOM profile and options, counts by SOP class and disposition, UID/date strategy, private-tag allowlist version, pixel and facial-review method, validation results, exceptions, reviewer role, approval and release time. Where policy permits, cryptographic hashes of controlled input and released output can support integrity and traceability, but mappings or hashes derived from identifiers need their own access controls.

PS3.15 requires a conforming application's statement to describe which attributes it removes, replaces, encrypts or inserts; how replacement values and referential integrity work; which options and transfer syntaxes it supports; and applicable restrictions. HHS likewise requires the methods and results of an Expert Determination to be documented. A product label or conformance statement does not replace testing on the actual modalities, vendor versions and export pathways being released.

Use this as an engineering and governance prompt, not as legal approval or a substitute for a qualified imaging, privacy, security or research review. Tailor the release rule to the purpose and jurisdiction, and stop when an exception cannot be explained and validated.

• Scope: list every study, series, instance, presentation state, report, thumbnail, attachment, archive and manifest intended for release.
• Authority: record purpose, recipient, legal or consent route, institutional approval, data-sharing controls and required clinical utility.
• Profile: state the DICOM PS3.15 Basic Profile version and every selected option; default to no retention option without a documented need.
• Attributes: apply the normative action table recursively; replace file metadata and preamble; handle DICOMDIR and filenames; record the de-identification method.
• Pixels and graphics: inspect all relevant frames and rendered forms; permanently edit identifying stored pixels; remove or clean overlays, icons and presentation content.
• Recognizable features: assess photographs, head and neck volumes, dental images and other distinctive anatomy; validate any defacing or masking against intended use.
• Private content: remove private attributes unless each retained element is affirmatively known and documented as safe under a controlled allowlist.
• UIDs and dates: preserve referential integrity across replacements; document any retention; apply one coherent, legally appropriate temporal strategy across linked objects.
• Validation: use an independent parser and viewer, scan retained text, render outputs, test relationships and record every exception or rejected file.
• Release: approve the exact output set, transfer through the authorized channel, protect any mapping separately, and retain a privacy-safe, reproducible audit record.

Neither removal of listed tags nor claimed conformance proves that a DICOM information object is anonymous. The standard says its confidentiality profiles do not guarantee removal of all individually identifying information and points to contextual re-identification risk, private or future attributes, pixels, external data, recipient capability, key management and local regulation. HHS also describes de-identification as reducing risk rather than eliminating every possibility of identification.

This guide does not select a legal method, certify a product, validate a local rule set, authorize disclosure, or determine whether transformed images remain fit for diagnosis, research, training or publication. Do not upload patient-identifying DICOM files to SameCase. Use only an institutionally approved workflow, and do not release a study when safe transformation, consent, authorization or residual-risk review is unresolved.