Hi Everyone,

Can I ask for some advice on the use of (0018,9087)?

I am looking at some draft documentation from a vendor regarding suggested methods of data anonymisation. The documentation notes that many PACS teams will remove all private tags as a default and this often screws up onward processing of DICOM data. This statement appears:

"It follows that the B-value should be retained before private fields are stripped and the most appropriate solution is to place this value in the tag (0018,9087), the official DICOM tag for diffusion B-value information."

Looking at the DICOM standard, it seems to me that (0018,9087) is part of either a Shared or Per-Frames Functional Group sequence and thus the tag is not relevant for single-frame MR data. So that the advice above is not correct in general and would actually be a violation of the standard if the file was not an enhanced MR multi-frame image.

However, I am unclear about the significance of the final part of the note in the standard, viz.

> "May be present otherwise."

Does this mean that you can just add this tag to a single-frame image and if the processing application chooses to look at it, then all well and good? Or would adding this tag to a single-frame image risk causing software enforcing strict DICOM compliance to reject the file?

Best wishes,

Simon

On Thursday, 24 August 2023 at 03:33:42 UTC-6, Simon Doran wrote:

> Does this mean that you can just add this tag to a single-frame image and if the processing application chooses to look at it, then all well and good? Or would adding this tag to a single-frame image risk causing software enforcing strict DICOM compliance to reject the file?

Placing this attribute in the root of a non-enhanced MR Image file as a Type 3 attribute would not be a violation of the standard, as far as I understand. Please see https://dicom.nema.org/medical/dicom/current/output/chtml/part02/sect_7.3.html

However, I don't think it's a wise thing to do, since processing software won't look for this attribute at that location. In general, processing software will expect the relevant private fields to be retained. This requires the use of a deidentifier that retains safe private attributes while removing attributes that are unsafe/unknown.

Thank you, David. That's extremely helpful.

Your last comment reflects my own view that a more desirable solution would be to use the "Retain Safe Private" option for the vendor private b-value tag, but this might not be practical in the scenario being discussed.

Best wishes,
Simon