Security starts before de-identification
A secure imaging architecture protects data in transit, authenticates nodes and users appropriately, and records auditable events before it ever attempts de-identification. Transport security and de-identification solve different problems and both are required.
Layered DICOM security controls
Loading diagram...
If teams skip the early layers and jump straight to de-identification, they still leave acquisition, routing, and administrative access paths exposed. That is why DICOM security discussions usually involve secure transport profiles, audit expectations, and operational key management together.
DICOM Part 15: Security and system management profiles
Official reference for secure transport, audit, and confidentiality-profile guidance in the DICOM standard.
Read Part 15AWS Healthcare Industry Lens: medical imaging architecture
Architecture guidance for isolating imaging workloads and applying least-privilege controls in AWS environments.
Read the AWS imaging architecture guidancePart 15 de-identification is a profile, not a one-line scrub
The DICOM confidentiality model does not say "delete everything sensitive" and stop. It defines a base profile plus options that teams combine deliberately depending on whether they need to retain safe private tags, preserve some device identity, or keep enough temporal context for longitudinal analysis.
Common confidentiality-profile options
| Option | What it addresses | Why architects care |
|---|---|---|
| Basic Application Level Confidentiality Profile | Baseline attribute treatment for de-identification | Starting point for most de-identification workflows. |
| Clean Pixel Data | Burned-in or directly identifying pixel content | Pixel overlays and annotations can re-identify a subject even if tags are cleaned. |
| Clean Descriptors | Free-text fields that may leak identifiers | Protocol names and descriptors can carry identifying or site-specific context. |
| Retain Safe Private | Selected private attributes judged safe to keep | Useful when analytics or workflow tools depend on vendor-specific tags that are not identifying. |
Burned-in annotation remains a common blind spot
Text inside the image, screen captures, secondary captures, and overlays can all bypass tag-based de-identification. Pixel review or OCR-based inspection belongs in the operating design.
DICOM confidentiality profiles
Official DICOM security specification covering confidentiality-profile behavior and options.
Review the confidentiality profilesAWS HealthImaging compliance validation
AWS documentation describing compliance and validation considerations for HealthImaging workloads.
Read the compliance validation guideRelease workflows need auditable evidence, not only a scrubber
A production de-identification service should not behave like a black box that emits a cleaned file and nothing else. Teams usually need a scoped request, the chosen confidentiality options, evidence that pixel or OCR findings were reviewed, a decision on whether deterministic UID mapping is permitted, and an audit record for the release itself.
Governed de-identification release flow
Loading diagram...
Release controls worth proving explicitly
| Control | Why it matters | Evidence teams should keep |
|---|---|---|
| Scoped release request | Prevents broad export behavior that no one can justify later. | Approved requester, cohort definition, and stated purpose. |
| Pixel or OCR review | Tag cleaning alone does not prove that burned-in identifiers are gone. | Reviewer disposition, exception list, and any manual rework notes. |
| Mapping-vault separation | Deterministic remapping restores linkage power and should not travel with the release copy. | Separate access control, key custody, and access log review. |
| Audit-grade release event | Investigations need to know what was released, when, and under which policy. | Manifest version, profile/options used, approver, and destination system. |
This is where IHE ATNA-style thinking is useful even outside a formal IHE deployment. Audit trails and authenticated nodes give the de-identification release path an evidence record instead of forcing operators to reconstruct what happened from storage logs after the fact.
IHE ATNA profile
Official IHE profile for audit trail and node authentication concepts that support imaging release evidence.
Review ATNADICOM Part 15 confidentiality profiles
Normative DICOM confidentiality chapter covering the base profile and profile options that release workflows apply.
Read Chapter EOperational de-identification needs pixel and process controls
The standard gives you a profile vocabulary, but production de-identification still needs a pipeline: classify the input, apply the right confidentiality options, inspect pixel content, decide whether UIDs are remapped, and document every release path.
Example de-identification policy manifest
A simple policy record showing that de-identification decisions should be explicit, reviewable, and tied to workflow obligations.
Click on an annotation to highlight it in the JSON
That manifest is not a DICOM standard payload. It is an operational teaching aid. The point is that de-identification decisions should be explicit and reviewable rather than hidden inside one opaque batch job.
In a mature program, that manifest should line up with the release governance evidence. The policy record, reviewer outcome, and release audit event should describe the same cohort and the same de-identification option set rather than leaving operations to infer the connection later.
DICOM Part 15: Security and privacy controls
Normative foundation for the transport, audit, and confidentiality controls that de-identification programs build on.
Read the security standardAWS medical imaging architecture guidance
Reference architecture considerations for isolating PHI, using least privilege, and separating ingestion from release workflows.
Review the architecture guidanceKnowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.