Date anonymization in DICOM

[Luigi Pampana Biancheri]

The HIPAA Safe Harbor de-identification method requires to remove the information about dates, but you can keep the year: see https://www.hhs.gov/hipaa/for-professionals/special-topics/de-identification/index.html#dates 

How can this be done in DICOM, that is, how can we keep the year discarding the day and month? Please note that "20250000" is not admitted by the standard. Putting, for example, "20250101" seems not to be admitted, at least according to our legal advisors.

Many thanks in advance for yout help!

Luigi Pampana Biancheri

luigi.pampana_at_esaote.com  

[Mathieu Malaterre]

Hi Luigi,

Could you clarify what you mean by "seems not to be admitted", since "20250101" is a perfectly valid DA field.

https://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_6.2.html#para_312cfe02-4e56-4356-a757-e4074a11be69

[Luigi Pampana Biancheri]

Sorry, I was not clear enough, I meant "it is not admitted by the safe harbor method", you should only keep the year, putting any day and/month is not admitted (see the link I sent you).

Regards.

Luigi P.B.

[Mathieu Malaterre]

Luigi,

I am not familiar with those requirements. However DICOM defines a mechanism for de-identification, where you can use the option "Retain Longitudinal Temporal Information With Modified Dates Option":

* https://dicom.nema.org/medical/dicom/current/output/chtml/part15/sect_E.3.6.html

The logic that we use in Clinical Trials context is as describe in Note (1):

[...]

1. Aggregation of dates may be performed by various means such as setting all dates to the first day of the month, all months to the first month of the year, etc., depending on the precision required for the application.

[...]

[David Clunie]

Hi Luigi

I think you may be over-interpreting the rule (which is regulatory) and taking too
literally the example in the guidance from OCR (which is advisory, and may allow
for alternative means of compliance with the same effect).

You may be confusing the requirement to reduce the precision of the original
non-de-identified value of the date (aggregate it to the precision of a year) with
the representation after reduction to that level of precision (aggregation).

The rule [1] as quoted on the guidance page [2] only says:

"All elements of dates (except year) for dates ..."

It does not specify how that year is then to be encoded or represented, and nor would
one expect it to.

I.e., if all dates are aggregated to the precision of a year (e.g., all original
dates from 2009/01/01 through 2009/12/31 are replaced by a single date value
of 2009/01/01) then I believe that the intent and letter of the regulation
would be satisfied, since any recipient would then not be able to recover any
knowledge of precision greater than a year, so you don't need to literally send
"2009" only as opposed to "2009/01/01" if the "01/01" is actually a dummy
replacement value.

Note that a year (yyyy) without a month (mm) and day (dd) is not a valid DA VR value
when encoded in DICOM [3], as your question states. Nor, AFAIK, is a date without
month and year a valid date in most SQL databases, etc.. So you have to address
the distinction between meaning and representation in this situation if you want
to retain DICOM conformance and utility.

All that said, my suggestion would be to actually shift the dates (including the
year) rather than simply aggregate them to the level of a year, by some amount that
is consistent within a single subject's set of information, in order to preserve
within-subject longitudinal integrity, but so that not even the year can be recovered
(since for medical imaging applications the year is not usually useful, whereas the
interval between studies is). E.g. you can do worse than shifting the earliest date
in a set of images to 1970/01/01 and all other dates by the corresponding offset
(see Note 2 in the section of PS3.15 [4] that Mathieu referred to).

I.e., the HIPAA rule would be satisfied (no real dates, not even years) but greater
utility (days between studies) would be retained. The privacy rule "safe harbor"
method does not explicitly address risk incurred from retaining internals of time
between events.

Replacing dates more effectively might also help for other jurisdictions.

For the HIPAA Privacy Rule, don't forget the interaction of dates, years and ages,
presence or absence of the birth date, and aggregation of everything over 89 years.

Of course, whatever you decide to do, document it in your risk analysis and describe
the behavior in your user documentation.

PS. We did not specifically address the meaning vs. representation issue of the year
aggregation in the MIDI TG report [5] in Section 1.17.9 Dates and Times, and Section
1.17.5 Retention of DICOM Compliance, so if we ever do an update to it, I will add
something about your question.

David

1. §164.514(b) (2)(i) (C)

2. https://www.hhs.gov/hipaa/for-professionals/special-topics/de-identification/index.html#safeharborguidance

3. https://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_6.2.html#para_312cfe02-4e56-4356-a757-e4074a11be69

4. https://dicom.nema.org/medical/dicom/current/output/chtml/part15/sect_E.3.6.html

5. Clunie DA, Flanders A, Taylor A, Erickson B, Bialecki B, Brundage D, et al. Report of the Medical Image De-Identification (MIDI) Task Group -- Best Practices and Recommendations. arXiv; 2025. Available from: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10081345/ doi:10.48550/arXiv.2303.10473

On 9/15/25 7:26 AM, Mathieu Malaterre wrote:
> Luigi,
>
> I am not familiar with those requirements. However DICOM defines a mechanism for de-identification, where you can use the option "Retain Longitudinal Temporal Information With Modified Dates Option":
>
> * https://dicom.nema.org/medical/dicom/current/output/chtml/part15/sect_E.3.6.html
>
> The logic that we use in Clinical Trials context is as describe in Note (1):
>
> [...]
>

> 1.

>
> Aggregation of dates may be performed by various means such as setting all dates to the first day of the month, all months to the first month of the year, etc., depending on the precision required for the application.
>

> /[...]/

>
> On Monday, September 15, 2025 at 11:01:03 AM UTC+2 Luigi Pampana Biancheri wrote:
>
> Sorry, I was not clear enough, I meant "it is not admitted by the safe harbor method", you should only keep the year, putting any day and/month is not admitted (see the link I sent you).
>
> Regards.
>
> Luigi P.B.
>
> Il giorno lunedì 15 settembre 2025 alle 09:50:41 UTC+2 Luigi Pampana Biancheri ha scritto:
>

> The HIPAA Safe Harbor de-identification method requires to remove the information about dates, but you can keep the year: see https://www.hhs.gov/hipaa/for-professionals/special-topics/de-identification/index.html#dates <https://www.hhs.gov/hipaa/for-professionals/special-topics/de-identification/index.html#dates>

>
> How can this be done in DICOM, that is, how can we keep the year discarding the day and month? Please note that "20250000" is not admitted by the standard. Putting, for example, "20250101" seems not to be admitted, at least according to our legal advisors.
>
> Many thanks in advance for yout help!
>
> Luigi Pampana Biancheri

> luigi.pampana_at_esaote.com <http://luigi.pampana_at_esaote.com>
>
> --
> You received this message because you are subscribed to the Google Groups "DICOM Forum" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to dicomforum+...@googlegroups.com <mailto:dicomforum+...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/dicomforum/007f8e0a-b686-4d35-81d8-3f78738c2d89n%40googlegroups.com <https://groups.google.com/d/msgid/dicomforum/007f8e0a-b686-4d35-81d8-3f78738c2d89n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Luigi Pampana Biancheri]

Hi David, Hi Mathieu,

many thanks for your help.

We are introducing different options to de-identify the ultrasound exams, implemented according to the DICOM Basic Application Level Confidentiality; one of them follows the “Retain Longitudinal Temporal Information with Full Dates Option”, and of course cannot be a real anonymization, but just (at most) a pseudonymization (if you have the hospital accession information you can easily re-identify the exams...). 

The option I described was intended to really de-identify the exams, but retains the year (for the age of the patients we follow the aggregation of everything over 89 years), and from the DICOM point of view should follow the "Retain Longitudinal Temporal Information with Modified Dates Option". As far as this implemented option is involved, we are not interested in maintaining the temporal coherence among various exams (in this case the Full Dates Option could be used, see above), but only among the images of the same exam, mainly for the reason of stress test or exams with contrast media. 

In my opinion, just putting "YYYY0101" for the DICOM Study Date (that is, 1st January of the year of the exam) correctly follows the Safe Harbor rule, but our legal advisors questioned my understanding. As David wrote, " I think you [not me, our legal advisors :-) ] may be over-interpreting the rule (which is regulatory) and taking too literally the example in the guidance from OCR (which is advisory, and may allow for alternative means of compliance with the same effect).". I'll come back to our legal advisors trying to convince them...

Many thanks again.

Luigi P.B.

You received this message because you are subscribed to a topic in the Google Groups "DICOM Forum" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dicomforum/yuC1I4srUYQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dicomforum+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dicomforum/010001994d6b21b7-64856b0e-1978-4244-ba5f-9b14d1c2f243-000000%40email.amazonses.com.

[Jörg Riesmeier]

Hi Luigi,

A small addition: if you ever have to deal with DT (Date Time) attributes, e.g., for Acquisition DateTime (0008,002A), the definition of this VR would allow to encode only the year (YYYY) component.
See: https://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_6.2.html#para_89d6d588-e108-4ee1-b4ba-74a5c3f0df43

Regards,

Jörg

[David Clunie]

But it would be a terrible idea to actually take advantage of the more flexible DT VR in that manner, if other data elements in the same dataset were DA and required a dummy month and year, since their relationship would then be ambiguous, as encoded.