Which DICOM Tags Contain PHI, and What to Replace Them With

If your imaging core de-identifies studies with its own script, the heart of that script is a list of DICOM (Digital Imaging and Communications in Medicine) tags. Two questions decide whether that list does its job, namely which DICOM tags contain protected health information (PHI) and what to write in their place once a value has to go. A cleaned header can still be a broken one, since a date field holding the word REDACTED can stop strict viewers and picture archiving and communication systems (PACS) from reading the file.

The tags below are grouped by what they identify and mapped to the Safe Harbor categories of the Health Insurance Portability and Accountability Act (HIPAA). Our guide to DICOM de-identification sets those categories out alongside the pixels and the rest of the file.

The DICOM tags that carry PHI, grouped by what they identify

Every attribute in a DICOM header has a tag made of a group number and an element number, such as (0010,0020) for Patient ID, and most patient attributes sit in group 0010. The complete reference is Table E.1-1 in PS3.15, which lists every attribute the standard's confidentiality profile acts on. The table below groups the attributes a Safe Harbor review meets most often. Table E.1-1 lists many more, among them Patient's Birth Time (0010,0032), Other Patient IDs (0010,1000) and the equipment's Device Serial Number (0018,1000). A script should be checked against the full table, not against a short list, this one included.

Several rows carry no Safe Harbor letter, and they still belong on the list. The DICOM profile removes physicians, operators and the institution anyway, as our guide explains, because together they can point to one patient, and it removes Country of Residence as well. An unusual occupation or a rare ethnic group in a small population can also narrow a study to very few people. A de-identification program has to decide how it treats these fields instead of keeping them by default.

Free text is where a tag list runs out

Free-text attributes hold whatever someone typed, which makes them the weakest point of any list that works by field name. Study Description (0008,1030) and Series Description (0008,103E) are meant to describe the exam, but nothing stops a technologist typing a name or a date of birth into them. Image Comments (0020,4000), Patient Comments (0010,4000) and Additional Patient History (0010,21B0) are open text by design.

A small test study shows the gap in any tool that works by field name alone. Put a name and a date of birth in the standard patient fields, and type the same details into the study description, the series description and the image comments. Then run the tool with its rule list alone. The standard fields come back masked while the three free-text fields come through exactly as typed, because nothing in a list of field names tells the tool to read what someone wrote. Run it again with detection reading the text the rules do not name, and the typed copies should be gone as well.

The standard's baseline takes the blunt route with these fields, and Table E.1-1 marks Image Comments for removal. Its Clean Descriptors Option exists for projects that need descriptive text kept, and it cleans the text instead of removing it. Detection is what makes that cleaning practical across thousands of studies, and our article on how named entity recognition finds PHI in clinical text explains how such models find names and dates inside sentences.

Remove, empty or replace: what the standard allows

Once you know which attributes identify someone, the standard gives each one an action code, and the right choice depends on whether the attribute has to stay in the object. The definitions below are quoted from PS3.15, where VR stands for value representation, the attribute's data type.

Deleting an attribute is not always allowed, because PS3.5 makes some of them mandatory in the objects that carry them. Type 2 attributes "shall be included in the Data Set and their absence is a protocol violation", although they may be sent empty when the value is unknown. Type 1 attributes must carry a value, since "The Length of the Value Field shall not be zero." Patient's Name, Patient ID, Patient's Birth Date and Accession Number are all Type 2 in the modules that define them, which fits the Z the baseline gives most of them. For protected Type 1 attributes the standard adds that "Dummy values may be necessary", because an empty value is not allowed.

Replacing the value while leaving the attribute in place avoids most of these traps, since software that expects an attribute keeps finding it. Putting a detector on the header raises a different risk, because a header is full of short codes and numbers that a detector trained on prose can mistake for identifiers. Modality, Photometric Interpretation, Number of Frames and instance numbers are examples, and masking one of them leaves a file that no longer describes its own pixels. Only text fields that can carry a person's details should ever reach a detector.

A replacement value has to fit the field's data type

Every DICOM attribute declares a value representation, and PS3.5 fixes the format each one may hold, which is the rule any replacement value has to respect.

Every replacement therefore has to suit the field's data type, since a text mask in a date or age field leaves a file that strict parsers reject even with every identifier gone. A person-name field can take placeholder text, while a date field can only take something shaped like a date, so no single mask can serve both.

Dates need a decision before any value is written, because Safe Harbor's date rule, covered in our guide, keeps only the year. A fixed neutral date in the right format removes the date, and it also removes the interval between a patient's scans, which a longitudinal study may need. Keeping those intervals is a separate problem that belongs with the pipeline holding the patient crosswalk, and the standard's option for it is set out in our article on multi-frame files, series and studies.

Ages over 89 are awkward in DICOM, because the age format holds only a three-digit number and a unit. A program that keeps ages can write one agreed value, such as 090Y, for every patient over 89 and record what it means, while the baseline profile simply removes Patient's Age.

How to check a de-identified header

A header check has to prove two things at once, that every identifying value is gone and that everything else still reads as valid DICOM. Each attribute in the table of PHI tags above should be either absent or holding a value its data type allows. Structural attributes such as Modality, Photometric Interpretation, Rows, Columns and Pixel Spacing should be exactly as they were. A DICOM validator does much of this work in one run, reporting missing Type 2 attributes, empty Type 1 attributes and values in the wrong format before a receiving PACS rejects the file.

A header can also record that it was de-identified, and a release process should decide who sets that record and how it is checked. Under the baseline profile, Patient Identity Removed (0012,0062) "shall be replaced or added to the Data Set with a value of YES". The profile also asks for the method to be recorded, as codes in De-identification Method Code Sequence (0012,0064), as a text description in De-identification Method (0012,0063), or both. A recipient can read that value without opening anything else, so it should be set by the step that actually did the work and checked like any other output. Copies hiding in private groups and nested items call for the separate checks in our article on DICOM private tags and nested sequences.

What Redactor changes in a DICOM header

VIDIZMO Redactor handles a DICOM header in two layers, a standard rule list for the fields known to identify someone and an optional artificial intelligence (AI) pass over the text the list does not name.

The same Safe Harbor identifiers in records, recordings and documents are covered on Redactor's HIPAA redaction page.