Hi all,

is there a DICOM TAG to understand if a DICOM is enhanced or not?

Thank you :)

Domenico

On Monday, November 7, 2022 at 2:53:10 PM UTC+1, domenic...@gmail.com wrote:
> Hi all,
>
> is there a DICOM TAG to understand if a DICOM is enhanced or not?

From the DataSet you can check the value of SOP Class UID (0008,0016). For P10 file, you can check the meta header tag: Media Storage SOP Class UID (0002,0002).

You can also check for the existence of (5200,9229) Shared Functional Groups Sequence, because it is mandatory in enhanced DICOM IODs and should never be present in a non-enhanced DICOM IODs.

Hi David,

On Tuesday, November 8, 2022 at 7:24:48 AM UTC+1, david...@gmail.com wrote:
> You can also check for the existence of (5200,9229) Shared Functional Groups Sequence, because it is mandatory in enhanced DICOM IODs and should never be present in a non-enhanced DICOM IODs.

Where did you see that sentence "[...]should never be present in a non-enhanced DICOM IODs" ?

The fact that this attribute is present -say- in a legacy MR Image Storage, simply makes the instance be of a Standard Extended SOP Class.

* https://dicom.nema.org/medical/Dicom/2016b/output/chtml/part02/sect_3.11.3.html

or more recently:

* https://dicom.nema.org/medical/dicom/current/output/chtml/part02/sect_7.3.html

> Where did you see that sentence "[...]should never be present in a non-enhanced DICOM IODs" ?

It doesn't appear anywhere in the standard. So I must prefix it with "In my opinion."

But here is the justification. In order to be meaningful, the SharedFunctionGroupsSequence tree will use at least some the attributes from the enhanced functional group modules. But in legacy IODs, those same attributes (or their equivalents) are stored in the root of the data set. So the use of SharedFunctionGroupsSequence or PerFrameFunctionGroupsSequence in an extended legacy IOD will lead to duplication of information and difficulties with interpretation.

So, no, it's not disallowed by the standard (as far as I know), but it's a bad idea and I hope no vendors do such a thing.

In a recent discussion, you argued that no MR data set could have a GE PDB and a Siemens CSA. I agree, because, there would be huge problems interpreting such a data set, and no practical reason for anyone to generate such a data set. But can you point to a part of the standard that says it's not allowed?

On Tuesday, November 8, 2022 at 6:34:44 PM UTC+1, david...@gmail.com wrote:
> > Where did you see that sentence "[...]should never be present in a non-enhanced DICOM IODs" ?
> It doesn't appear anywhere in the standard. So I must prefix it with "In my opinion."
>
> But here is the justification. In order to be meaningful, the SharedFunctionGroupsSequence tree will use at least some the attributes from the enhanced functional group modules. But in legacy IODs, those same attributes (or their equivalents) are stored in the root of the data set. So the use of SharedFunctionGroupsSequence or PerFrameFunctionGroupsSequence in an extended legacy IOD will lead to duplication of information and difficulties with interpretation.
>
> So, no, it's not disallowed by the standard (as far as I know), but it's a bad idea and I hope no vendors do such a thing.
>
> In a recent discussion, you argued that no MR data set could have a GE PDB and a Siemens CSA. I agree, because, there would be huge problems interpreting such a data set, and no practical reason for anyone to generate such a data set. But can you point to a part of the standard that says it's not allowed?

True, this rant was also "in my opinion". The justification was that there is no hybrid GE/SIEMENS MR modality today.

My point (for OP) was that an MR Image Storage instance remains an "unenhanced" (legacy) MR Image Storage instance even if you duplicate some information in a SharedFunctionGroupsSequence attribute. This is how I understood the question `if a DICOM is enhanced or not?`.

-M