De-identification and research utility

Deleting (0010,0010) PatientName is not the same as making an imaging release anonymous. Identity-bearing information may remain in other attributes or free text, in institution and device fields, in dates and times, in linkable UIDs, or in the pixels themselves. A face, burned-in annotation, or recognizable visual feature is not removed by a tag-deletion script.

The opposite failure is possible too. A blunt transformation can remove dates and identifiers independently for every instance and destroy the internal references and longitudinal pairing that a research study needs. De-identification is thus a controlled transformation under a stated purpose and risk context. It is neither a single deletion nor permission to retain everything that seems useful.

Confidentiality is a set of scoped decisions

DICOM provides a vocabulary for attribute confidentiality profiles. The profile approach is useful because it makes the trade-off explicit: information is removed, changed, or retained according to the intended use, and the profile itself does not replace the wider de-identification process. The action applied to an attribute depends on the profile, its options, and the content that the attribute or pixel data actually carries.

The common action codes provide a compact mental model:

Action	Working meaning
D	Replace with a non-zero-length value.
Z	Replace with zero length, or with a non-zero dummy value where the IOD or VR requires one.
X	Remove the attribute.
K	Keep the attribute.
C	Clean the value while preserving its intended meaning where possible.
U	Replace UIDs consistently within the protected scope.

These codes are not a universal per-attribute recipe. The profile table and its options determine the action, and a release process must verify the result rather than infer safety from the presence of a code.

Several surfaces require separate attention. Patient and personnel identifiers can appear in ordinary attributes, accession values, free-text comments, protocol descriptions, and report content. Dates and times can expose schedules or permit linkage; when a scientific purpose requires intervals, one possible design is a consistent subject-level date shift. Consistent shifting can preserve intervals and replace absolute dates, but effective obscuring and residual linkability depend on offset handling, retained context, additional information, and the circumstances of the release. That is a documented risk trade-off, not a universal date policy.

UIDs are opaque identifiers, but they are still linkable. Consistent replacement can preserve references among the instances of a study or series. It does not, by itself, create the link between two timepoints of the same subject. That longitudinal link needs a separate stable pseudonymous subject key or a controlled mapping, designed and protected for the release context.

Private attributes, structured report content, overlays, presentation annotations, and graphics are separate review surfaces. Vendor-private data can contain unexpected values. Text embedded in a structured object or a graphic can carry identity even when ordinary patient attributes have been processed. Pixel data requires its own inspection because burned-in text and recognizable visual features are not discoverable by metadata processing alone. DICOM confidentiality options can identify relevant cleaning choices, but the implementation process must still find and handle the actual content.

The transformation should also be declared. DICOM provides attributes for indicating that patient identity was removed and for recording de-identification method information. An encrypted attributes data set can support an authorised re-identification process when the governance context permits it. By contrast, an unencrypted hash of an identifier can remain vulnerable to dictionary attacks. Neither a declaration nor a hash is a substitute for access control, threat analysis, or release review.

Technical confidentiality is not legal anonymity

Technical de-identification, pseudonymisation, and anonymisation are related but distinct concepts. The DICOM profile describes transformations of a data set; it does not determine every means by which a person could be identified in a release.

Legal terminology is jurisdiction-specific. As one bounded example, the GDPR uses the concept of pseudonymisation for processing in which attribution to a person requires additional information held separately. That concept is not the same as anonymisation. The GDPR’s anonymisation boundary is assessed in context, including the means reasonably likely to be used to identify a person; it is not a property that a DICOM attribute can assert. Rare findings, small groups, visual features, and linkage with another release can change that assessment.

This is a distinction for technical and privacy review, not legal advice. Applying a DICOM confidentiality profile, even carefully, does not by itself establish legal anonymity for a particular release. The applicable jurisdiction, access arrangements, additional data, and release context must be assessed by the responsible privacy and legal processes. The same caution applies to the boundary between research software and a clinical product: de-identification mechanics do not decide intended purpose, qualification, or regulatory status.

Preserve the study without hiding the risk

For a longitudinal research release, the design should record at least which date attributes survive and in what form, how UIDs are remapped, how timepoints are linked, whether free text and private attributes were inspected, and how burned-in or recognizable visual content was addressed. A per-instance UID rewrite can break references within a study; an independently generated subject key can break the pairing between timepoints. Conversely, preserving original identifiers or exact dates without a documented risk basis can preserve a linkage that the release was intended to remove.

The useful result is not a claim that a script made the data anonymous. It is a traceable statement of the transformation, its intended research utility, its remaining risks, and the governance decision for the release. Technical identity, workflow identity, provenance, custody, and legal classification remain different questions even when they concern the same DICOM objects.

Once those boundaries are explicit, the path from a stored result to clinical use can be evaluated without treating transport success or model accuracy as a proxy for deployment. The next chapter takes up that clinical and lifecycle evidence.