(0008,0070) Manufacturer value as indirection to private tags

[Mathieu Malaterre]

Dear third party private tags readers,

Could someone please confirm that the correct approach to reading/interpreting private tags values is by first checking the public tag (0008,0070) Manufacturer ?

---

It seems that this tag is being removed when converting Enhanced MR Image Storage to legacy MR Image Storage on Siemens modality (MFSPLIT):

$ gdcmdump input.dcm | grep Manu
(0008,1090) LO [MAGNETOM Skyra] # 14,1 Manufacturer's Model Name
(0021,1022) SH [SIEMENS ] # 8,1 Manufacturer

$ dciodvfy input.dcm
Error - Missing attribute Type 2 Required Element=<Manufacturer> Module=<GeneralEquipment>

[David Gobbi]

The private creator tag is required to interpret private tags. I've never seen anything in the standard that connects private tags to (0008,0070).

Perhaps if the private creator tag is missing, then (0008,0070) could be used to "guess" the interpretation of private tags, but that would be non-standard.

[Jouke Numan]

Op woensdag 19 oktober 2022 om 22:45:44 UTC+2 schreef david...@gmail.com:

> The private creator tag is required to interpret private tags. I've never seen anything in the standard that connects private tags to (0008,0070).
>
> Perhaps if the private creator tag is missing, then (0008,0070) could be used to "guess" the interpretation of private tags, but that would be non-standard.

As per PS 3.5, private creator tag is mandatory to reserve the related private tag block and an absence would constitute a DICOM violation.

AFAIK, its value is the only way to identify the creator and drives how the content should be interpreted.

Regards, Jouke

[Mathieu Malaterre]

The use case I was considering could never happen in practice. An MR Image Storage instance will never contains both: (0019,SIEMENS MR HEADER,0C) and (0043,GEMS_PARM_01,39).

[Wim Corbijn]

Not sure about that it won't happen as processing applications might copy the original GE data and extend with Siemens data.
And when a product uses multiple subgroups you will need the Creator Code also to make the correct mapping.
So the manufacturer might give some indication but never gives sufficient information to do proper mapping of private attributes.
Don't use the Manufacturer tag for expected mappings.

[Steve Robbins]

On Friday, October 21, 2022 at 3:08:42 AM UTC-5, Wim Corbijn wrote:
> Not sure about that it won't happen as processing applications might copy the original GE data and extend with Siemens data.

I just saw today a DICOM dataset from a post-processing device that had private tags from both the originating device as well as the post-processing device. So I can confirm that multiple vendor private data does exist in the wild.

-Steve

[Mathieu Malaterre]

No, no and no.

My original point -although unclear- is about interpretation of quantitative imaging. An MR image comes from a *single* source. Typically one of Siemens, GE or Philips (Toshiba, UIH ... more recently).

In order to interpret the quantitative parameters of the Extended SOP Class instance, you need to clearly identify this source. In my initial proposal, I was suggesting to use (0008,0070) Manufacturer since it is *not* listed in any Application Level Confidentiality Profile Attributes (part15). I assumed until a few weeks ago that it would the most reliable attribute for this work. One the source is identified (eg. Siemens), then and only then one can load and interpret the extended attributes.

As explained at least one vendor (Siemens) is producing MR Image Storage instances without this attribute set (with a value). So one need to come up with an alternate implementation to identify the original source.

I absolutely do not buy the argument that one day, a private vendor will re-use private attributes for quantitative parameter from another different vendor. This is not happening today and will never happen in the future. I gave the example of diffusion b-value I could have taken other (ASL, MTR ...). GE is never going to incorporate Siemens CSA in lieu of PDB header.