DICOM de-identification: a six stage Annex E pipeline

DICOM de-identification means systematically removing or replacing Individually Identifiable Information across metadata and pixel data so a study can leave clinical control without exposing a patient. Implementers need three things working together: a metadata scrub mapped to PS3.15 Annex E, a pixel-cleaning pass that catches burned-in text, and an audit trail using the Patient Identity Removed and De-identification Method tags. Everything below builds out that playbook.

---

TL;DR:

• Most de-identification efforts must include a pixel-cleaning process to remove burned-in PHI, which OCR and template methods detect with varying reliability.
• UID replacement should be consistent and deterministic, often via a hash, to maintain data relationships without breaking referential integrity.
• Private tags from vendors require manual review and tailored handling, as proprietary data can contain hidden identifiers and operator comments.
• Date-shifting preserves longitudinal research value by applying a consistent offset per subject, but the offset must be securely stored and governed.
• Relying on default tool settings is risky; thorough validation, customization, and ongoing testing are essential for compliance and data integrity.

---

Table of Contents

• What does DICOM PS3.15 Annex E actually require?
• Metadata Tag Rules: Remove, Replace, Keep, or Clean
• Cleaning Burned-In PHI from Pixel Data
• A Different Path: Outsourcing the Interpretation Layer
• Pseudonymization and Date-Shifting Without Losing Research Value
• What the Research Says About Default Tool Settings
• Building a Validation and Audit Framework
• An Operational Pipeline You Can Adapt
• Why do governance decisions matter more than the tooling?
• Where to Go Deeper on the Standard and the Regulations
• Sources

What does DICOM PS3.15 Annex E actually require?

Annex E is the normative reference for DICOM de-identification, and if you've configured a de-id pipeline without reading it directly, you've probably inherited someone else's assumptions. The standard defines Attribute Confidentiality Profiles: a Basic Profile that every implementation should support, plus a set of Options you layer on top depending on your data recipient and use case. The Basic Profile handles the attributes everyone agrees are identifying: patient name, ID, birth date, addresses, and similar demographic fields. The Options handle the harder judgment calls.

Three options matter most in practice. Clean Pixel Data addresses burned-in annotations, the text and graphics rendered directly into the image rather than stored as metadata. Clean Graphics covers annotations and overlays stored as DICOM graphic objects rather than pixels. Retain Longitudinal Temporal Information lets you keep meaningful date and time relationships between studies instead of stripping every date to zero, which matters enormously for oncology follow-up imaging or any longitudinal research cohort.

Annex E also defines action codes that tell an implementation exactly what to do with each attribute:

• D , replace with a non-zero length dummy value that preserves the attribute's format.
• Z , replace with a zero-length value.
• X , remove the attribute entirely.
• K , keep the attribute unchanged.
• C , clean the attribute, meaning replace identifying substrings but retain non-identifying content.
• U , replace with a consistent UID that differs from the original but maps predictably within your dataset.

These codes aren't arbitrary. A PatientName tag typically gets a Z or D action. A StudyInstanceUID gets U, so relationships between series in the same study survive de-identification even though the original identifiers don't. That distinction between deletion and consistent replacement is where most homegrown scripts go wrong: they treat every sensitive-looking tag as a candidate for outright removal, which breaks the referential integrity that downstream tools rely on to group series correctly.

The standard is explicit that attribute cleaning is necessary but not sufficient on its own, since pixel data and private tags carry their own risks that the core profile doesn't automatically resolve. That single caveat should shape how you scope your entire pipeline.

Finally, Annex E requires two audit attributes once you've applied a de-identification profile. Patient Identity Removed (0012,0062) should be set to YES. De-identification Method (0012,0063) and its structured counterpart, De-identification Method Code Sequence (0012,0064), should record which profile and options you applied. Regulatory reviewers and downstream researchers will look for these tags first, before they look at anything else in your header.

Metadata Tag Rules: Remove, Replace, Keep, or Clean

Once you understand the action codes, the real work is building a tag inventory specific to your data sources, because every PACS vendor and modality adds its own flavor of identifying information on top of the DICOM baseline. Start with the tags every implementation must handle, then move to the ones your imaging fleet introduces.

The core sensitive tags and their typical treatment look like this:

• PatientName, PatientID, OtherPatientIDs , replace (D or Z), since these are direct identifiers with no clinical value once removed.
• InstitutionName, InstitutionAddress, ReferringPhysicianName , remove or replace, depending on whether your recipient needs institutional provenance.
• StudyDate, SeriesDate, AcquisitionDate , clean or shift rather than delete outright if longitudinal analysis matters.
• SOPInstanceUID, SeriesInstanceUID, StudyInstanceUID , replace consistently with the U action, never simply removed.
• AccessionNumber, IssuerOfPatientID , remove, since these frequently map back to a hospital's own record system.

Private tags are where automated pipelines quietly fail. Every manufacturer, from CT console software to third-party dose-tracking add-ons, writes proprietary group/element pairs into the private tag blocks, and many of those blocks carry operator initials, technologist comments, or even free-text clinical notes typed directly into a workstation. Before you run any automated de-identification job against a new data source, dump the full tag set from a representative sample and manually review every private tag group. Cross-reference vendor documentation where it exists. Where it doesn't, treat unknown private tags with suspicion by default.

UID handling deserves its own discipline. The goal is a deterministic mapping: the same original UID always produces the same replacement UID within a dataset, so relationships between images, series, and studies stay intact after de-identification. This usually means generating a lookup table (often a hash of the original UID combined with a project-specific salt) and applying it consistently across every file touched by that study. Annex E treats UID remapping as this kind of two-step process: stable replacement within the dataset, plus an encrypted mapping table retained separately if your governance framework permits lawful re-identification later.

Pro Tip: Build your private tag inventory once per imaging source and reuse it across projects. A CT scanner's private tag layout rarely changes between studies, so a reusable catalog per device model saves you from re-auditing the same manufacturer quirks every time a new dataset request comes in.

Cleaning Burned-In PHI from Pixel Data

Metadata scrubbing catches nothing that's baked into the actual image. Ultrasound frames routinely burn patient name and date of birth into the corner of the image itself. Nuclear medicine and PET-CT screen captures often carry a full demographic header rendered as pixels. If your pipeline only touches header tags, none of that goes away, and you've produced a dataset that looks de-identified on paper while still exposing identifiers to anyone who opens the image.

This is exactly why Annex E's Clean Pixel Data option exists as a separate, optional layer rather than being folded into the Basic Profile. Cleaning pixel data typically involves detecting text regions, then either masking them with a solid block or inpainting over them to preserve visual continuity for reviewers who need the surrounding anatomy intact.

Detection approaches fall into three general categories, and each has a distinct failure mode:

• OCR-based detection reads burned-in text directly and flags likely PHI strings, but struggles with low-contrast overlays, non-standard fonts, and rotated text.
• Template or position heuristics exploit the fact that many modalities burn text into consistent screen locations, which works well for a known scanner model but breaks the moment a vendor changes their display layout.
• ML-based detectors trained on annotated burned-in text generalize better across modalities but need ongoing retraining as new equipment enters your imaging fleet.

Position-based detection tends to work reliably for consistent template placements, like a modality header that always lands in the same screen coordinates, but it fails as soon as overlays vary in position or size. The practical answer is pairing OCR with position heuristics and routing anything ambiguous to a human reviewer rather than trusting either method alone.

That human-in-the-loop step isn't optional for any dataset leaving your institution. Set concrete acceptance criteria before you go live: a defined sample percentage of every de-identified batch gets manual visual review, any image flagged by the automated detector goes to a reviewer regardless of confidence score, and no batch ships without a signed-off completion log. Ultrasound and nuclear medicine studies deserve a higher review sampling rate than CT or MR, given how often those modalities burn text directly into frames.

Pro Tip: Keep a running gallery of every burned-in PHI pattern your reviewers have ever flagged, organized by modality and vendor. New team members onboard faster, and it becomes the seed dataset for retraining your detector when a new scanner model shows up.

A Different Path: Outsourcing the Interpretation Layer

Some organizations building a de-identification pipeline are doing it to move imaging data toward research, and others are doing it because they're managing overflow interpretation volume and need images flowing cleanly between systems without adding another portal to the mix. If reads getting signed on time is the real bottleneck, de-identification tooling alone will not fix it.

AstraRad approaches this from the interpretation side. Studies route through your existing PACS with no separate login for your staff to manage, and every read gets a final signed report from a US board-certified subspecialist matched to the modality, backed by peer review and compliance documentation your administrators can hand to an auditor without assembling it themselves. STAT cases turn around in under an hour, routine studies inside 24 hours, with 99.4% SLA compliance over the past year. That's a meaningfully different operational risk profile than trying to staff overnight or overflow coverage internally.

If your imaging center or radiology group is evaluating whether to build more in-house capacity or hand off volume to a partner that already runs compliant PACS integration at scale, start by reviewing per-report pricing for your specific study mix and see what a signed report actually costs against your current overflow expenses.

Pseudonymization and Date-Shifting Without Losing Research Value

De-identification, anonymization, and pseudonymization get used interchangeably in casual conversation, but they mean different things to a compliance reviewer. De-identification is the broad process of stripping identifiers. Anonymization implies the removal is irreversible. Pseudonymization replaces identifiers with a consistent substitute while keeping a controlled mapping that authorized parties can reverse under defined governance conditions.

Choose pseudonymization when your research protocol requires linking a subject's imaging back to clinical outcomes later, or when a multi-site study needs to merge records from the same patient across institutions without ever exposing the original identity to analysts. Choose irreversible anonymization when the data is leaving your governance boundary entirely, such as public benchmark datasets or third-party model training sets where no legitimate use case exists for reversal.

Dates deserve particular care because deleting them outright destroys longitudinal research value. Preserving that value usually means date-shifting rather than deletion: applying a single random offset per subject across every study in that subject's record. This preserves the interval between a baseline scan and a six-month follow-up while preventing an attacker from using the actual calendar date to cross-reference other records.

A few implementation details worth locking down:

• Generate the per-subject offset once and store it with the same access controls as your re-identification key, since the offset itself is sensitive.
• Document the offset range and random-generation method in your validation records, so reviewers can confirm intervals remain intact.
• Apply the offset consistently to every date field in a study, including secondary capture timestamps that are easy to overlook.

The governance question underneath all of this is re-identification risk relative to who receives the data. A dataset shared under a signed data use agreement with a known academic collaborator carries different risk than the same dataset posted to an open repository, and your choice between pseudonymization and full anonymization should reflect that difference explicitly, not default to whichever is easier to implement.

What the Research Says About Default Tool Settings

The tool landscape for DICOM de-identification splits into a few recognizable categories: open-source libraries you integrate into your own pipeline, standalone GUI cleaners built for one-off batch jobs, filters integrated directly into PACS or VNA middleware, and commercial appliances sold with support contracts and compliance documentation attached. Each category trades convenience against control differently, and none of them is safe to trust on default settings alone.

That's not a hedge. A comparative evaluation of ten non-commercial DICOM toolkits found that only one de-identified every required element correctly using its out-of-box defaults; four more reached full compliance only after careful configuration, and several others showed low success rates without that manual tuning. If you've assumed that installing a well-known open-source de-identifier and running it against your export folder satisfies your compliance obligation, that finding should change your assumption immediately.

Some open-source projects handle this better than others by design. Libraries like the dicom-anonymizer project implement standard-based tag lists directly and, notably, anonymize date fields rather than deleting them outright, specifically to avoid the downstream application crashes that come from missing required date attributes. That's a small design choice with outsized practical consequences, since a viewer or PACS ingestion pipeline that expects a populated StudyDate field can fail outright on a null value.

Run any candidate tool through this evaluation checklist before you commit to it in production:

1. Does it expose a fully customizable action profile, or only a fixed default set of tags?
2. Does it support private tag discovery and configurable handling, not just the public DICOM dictionary?
3. Does it include a pixel-cleaning capability, or does it stop at metadata?
4. Does it write the Patient Identity Removed and De-identification Method audit tags automatically?
5. Does the vendor or project publish a test suite or validation report you can review independently?

A tool failing any one of these checks isn't automatically disqualified, but it means you're assuming responsibility for that gap yourself, and you need a documented compensating control.

Building a Validation and Audit Framework

Every de-identification pipeline needs a test suite before it touches real patient data, and that test suite needs to be adversarial, going well beyond a happy-path sanity check. Build a synthetic or carefully scrubbed test dataset that deliberately includes private tags from every scanner model in your fleet, burned-in PHI patterns across each modality you support, sequence-level UIDs nested inside structured reports, and multi-study longitudinal date sets from the same simulated subject.

Run the following checks against every batch before it leaves your environment, and keep running them long after initial tool qualification:

• Confirm Patient Identity Removed (0012,0062) is present and set to YES on every output file.
• Verify De-identification Method (0012,0063) or the Code Sequence variant actually reflects the profile and options you applied, rather than a generic placeholder string.
• Run OCR against a statistically meaningful sample of pixel data, flagging any residual text hits for manual review.
• Compare UID mappings across the full study to confirm every series and instance UID remapped consistently, with no orphaned references back to original identifiers.

The MIDI project's benchmark datasets and reported testing methodology offer a useful external reference point if you want to validate your pixel-level cleaning algorithm against something beyond your own internal test set, particularly for burned-in text detection accuracy.

Document retention matters as much as detection accuracy. If your governance framework permits lawful re-identification, the mapping table between original and replacement identifiers needs encryption at rest, restricted access logging, and a defined retention period tied to your institutional review board approval or data use agreement, not an indefinite default. Treat that mapping table as more sensitive than the de-identified data itself, because it's the single point of failure that turns anonymized data back into PHI.

An Operational Pipeline You Can Adapt

A production-grade de-identification pipeline breaks into six discrete stages, and treating each as a distinct checkpoint, rather than one monolithic script, makes failures easier to isolate and fix.

1. Discovery , Inventory every tag, public and private, present in a representative sample from each imaging source before writing a single rule.
2. Profile design , Map your discovered tags to Annex E action codes, documenting the rationale for each choice, especially deviations from the Basic Profile.
3. Metadata scrub , Apply the profile programmatically, with UID remapping handled through a consistent, logged lookup table.
4. Pixel cleaning , Run OCR and position-based detection against every image, masking or inpainting flagged regions.
5. QA , Route flagged images and a fixed sampling percentage of every batch to human reviewers against documented acceptance criteria.
6. Packaging and audit metadata , Write the Patient Identity Removed and De-identification Method tags, generate a batch-level audit log, and archive the encrypted mapping table if reversal is permitted.

Treat this pipeline the way you'd treat any other production software: with regression testing. Maintain a fixed regression dataset containing every known burned-in PHI pattern, private tag quirk, and edge-case date structure your team has ever encountered, and run it against every pipeline update before deployment. Automated OCR checks against that regression set catch the silent failures that a manual spot check would miss, and monitoring for private-tag drift matters especially after a PACS upgrade or new scanner rollout, since vendors change private tag layouts without much warning.

On the integration side, most hospitals and imaging centers run de-identification as a step bolted onto their existing PACS workflow rather than a standalone tool, which means mapping tables and audit logs need to live somewhere your PACS administrators and data governance team can both access without duplicating infrastructure. Loop in data governance before you finalize your profile design, not after a research request forces the conversation. A profile decision that seems purely technical, like whether to retain longitudinal date relationships, is really a policy decision about acceptable re-identification risk, and that's not a call an engineer should make alone.

Pro Tip: Version your de-identification profile the same way you version application code. When a research partner asks which profile generated a dataset six months ago, "the Annex E Basic Profile plus Clean Pixel Data, version 3, deployed March 2026" is an answer you can defend. "Whatever the script did at the time" is not.

Why do governance decisions matter more than the tooling?

The technical mechanics of DICOM de-identification are, honestly, the easier part. Action codes are documented. Detection algorithms are well understood. What consistently trips up otherwise capable teams is treating de-identification as a purely engineering problem when it's really a governance problem with an engineering component attached.

Every profile decision, whether to shift dates instead of deleting them, whether to permit reversible pseudonymization, how long an encrypted mapping table gets retained, is a policy choice with legal and ethical weight. Who holds the key to re-identify a subject? Under what conditions can that key be used? Those questions belong to compliance officers and principal investigators, not to whoever wrote the de-identification script. The strongest pipelines I've seen work because IT, compliance, and the research team sat down together before the first line of code was written, not after an audit flagged a gap.

The biggest risk isn't a missed tag. It's the false confidence that comes from running a well-known open-source tool with its default settings and assuming that's equivalent to compliance. Continuous validation against a regression suite, not a one-time qualification test, is what actually protects an institution over the years a de-identification pipeline stays in production.

Rafael

Where to Go Deeper on the Standard and the Regulations

The sources below cover the normative requirements, the empirical evidence on tool reliability, and the regulatory framing you'll need if compliance or legal asks for citations rather than summaries.

• PS3.15 Annex E is the normative text every profile decision in this article traces back to. Read it directly.
• The PMC 2015 toolkit evaluation is the empirical basis for treating default tool settings with skepticism.
• The MIDI project's final report offers benchmark datasets for validating pixel-cleaning algorithms.
• The HHS PHI guidance frames the regulatory definitions that determine when data actually qualifies as de-identified.
• ClaroClaim's security and HIPAA compliance resource is a useful background reference for teams building out their broader compliance documentation.
• HIPAA vs. HITRUST covers the difference between the legal floor and the certifiable framework auditors ask about, which is the distinction most de-identification governance documents blur.
• How PHI and imaging data are handled in teleradiology sets out the BAA, access and retention side of the same problem, for the studies that leave your control to be read rather than to be researched.

Sources

• E Attribute Confidentiality Profiles (Normative)
• Free DICOM de-identification tools in clinical research: functioning and safety of patient privacy
• EDRN DICOM de-identification process (LabCAS help)
• Final Report: Medical Imaging De-Identification (MIDI) Project
• What is PHI? | HHS