• Disambiguation in attribute-module mappings

    From skrinakron@21:1/5 to All on Wed Nov 11 22:00:55 2020
    Hello,

    I'm trying to understand how to obtain the module and information entity
    of any given attribute in the IOD of a given DICOM file. My problem is
    that in some cases this determination seems ambiguous. For example, the Multi-Frame Grayscale Byte SC Image IOD contains the General Series module
    in its Series IE and the SC Equipment module in its Equipment IE. Both of
    these modules contain the Modality attribute (0008,0060), and here the SC Equipment one takes precedence over the General Series one [1], so that in
    this IOD the attribute (0008,0060) is unambiguously in the SC Equipment
    module of the Equipment IE. However, the CT Performed Procedure Protocol
    IOD (for another example) contains the Protocol Context module in its
    Protocol Procedure IE and the General Series module in its Series IE;
    these modules both contain the Protocol Name attribute (0018,1030), for
    which no such precedence information is given [2][3]. If I come across a top-level (0018,1030) attribute (i.e. one not contained in a sequence) in
    a file of this IOD, how do I know which module -- and thus which
    information entity -- the attribute belongs to? Is this choice arbitrary,
    or should the attribute be considered to belong in both modules and IEs?

    These examples were found by toying around with the Innolitics
    machine-readable DICOM standard representation [4] with little
    understanding of the finer points of the standard itself. I'm sure I'm oversimplifying somewhere, I just haven't been able to figure out where.
    I'd be grateful for a nudge in the right direction.

    [1] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.8.6.html#para_ae37c804-87a0-42ec-a150-a16a92520fdc
    [2] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#para_4405d28d-db41-4b21-89b5-c74923935975
    [3] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.34.2.html#para_36611353-b3d4-463a-8923-c42cb3dfa3ca
    [4] https://github.com/innolitics/dicom-standard/tree/master/standard

    /skrin

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Giese@21:1/5 to skrinakron on Tue Jan 12 08:17:28 2021
    First of all, I'm glad to see that our machine-readable DICOM standard representation is being used.

    If I come across a
    top-level (0018,1030) attribute (i.e. one not contained in a sequence) in
    a file of this IOD, how do I know which module -- and thus which
    information entity -- the attribute belongs to? Is this choice arbitrary,
    or should the attribute be considered to belong in both modules and IEs?

    I have not come across anything in the standard that would answer this question. Perhaps this is because IEs and modules, other than dictating which attributes are required, don't influence how DICOM files or messages are encoded. Somewhere in the
    standard (although I couldn't find where), there is a comment that says if an attribute shows up in a couple of modules with different "types", then the most restrictive type should be applied. This is used in the "enhanced" CIODs to require more
    attributes than in the enhanced ones. E.g., this attribute

    https://dicom.innolitics.com/ciods/enhanced-ct-image/enhanced-general-equipment/00080070

    makes the Manufacturer a type 1 attribute in the Enhanced CT CIOD, overriding the type here

    https://dicom.innolitics.com/ciods/enhanced-ct-image/general-equipment/00080070 .

    (We've considered adding a strike-through over shadowed attributes in the DICOM standard browser, but haven't gotten to it.)

    Out of curiosity, why do you want to disambiguate the IE for attributes?

    On Wednesday, November 11, 2020 at 1:04:45 PM UTC-5, skrinakron wrote:
    Hello,

    I'm trying to understand how to obtain the module and information entity
    of any given attribute in the IOD of a given DICOM file. My problem is
    that in some cases this determination seems ambiguous. For example, the Multi-Frame Grayscale Byte SC Image IOD contains the General Series module in its Series IE and the SC Equipment module in its Equipment IE. Both of these modules contain the Modality attribute (0008,0060), and here the SC Equipment one takes precedence over the General Series one [1], so that in this IOD the attribute (0008,0060) is unambiguously in the SC Equipment module of the Equipment IE. However, the CT Performed Procedure Protocol
    IOD (for another example) contains the Protocol Context module in its Protocol Procedure IE and the General Series module in its Series IE;
    these modules both contain the Protocol Name attribute (0018,1030), for which no such precedence information is given [2][3]. If I come across a top-level (0018,1030) attribute (i.e. one not contained in a sequence) in
    a file of this IOD, how do I know which module -- and thus which
    information entity -- the attribute belongs to? Is this choice arbitrary,
    or should the attribute be considered to belong in both modules and IEs?

    These examples were found by toying around with the Innolitics machine-readable DICOM standard representation [4] with little
    understanding of the finer points of the standard itself. I'm sure I'm oversimplifying somewhere, I just haven't been able to figure out where.
    I'd be grateful for a nudge in the right direction.

    [1] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.8.6.html#para_ae37c804-87a0-42ec-a150-a16a92520fdc
    [2] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#para_4405d28d-db41-4b21-89b5-c74923935975
    [3] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.34.2.html#para_36611353-b3d4-463a-8923-c42cb3dfa3ca
    [4] https://github.com/innolitics/dicom-standard/tree/master/standard

    /skrin

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gunter zeilinger@21:1/5 to J. David Giese on Wed Jan 13 01:05:11 2021
    The Type of an Attribute may also be "relaxed" by the IOD of a particular SOP Class. E.g. C.7.3.1 General Series Module includes Attribute Modality (0008,0060) with Type 1, but C.8.6.1 SC Equipment Module (which is itself included in IODs for Secondary
    Capture Images and Encapsulated Documents) includes Attribute Modality (0008,0060) with Type 3.


    On Tuesday, January 12, 2021 at 5:17:30 PM UTC+1, J. David Giese wrote:
    First of all, I'm glad to see that our machine-readable DICOM standard representation is being used.
    If I come across a
    top-level (0018,1030) attribute (i.e. one not contained in a sequence) in a file of this IOD, how do I know which module -- and thus which information entity -- the attribute belongs to? Is this choice arbitrary, or should the attribute be considered to belong in both modules and IEs?
    I have not come across anything in the standard that would answer this question. Perhaps this is because IEs and modules, other than dictating which attributes are required, don't influence how DICOM files or messages are encoded. Somewhere in the
    standard (although I couldn't find where), there is a comment that says if an attribute shows up in a couple of modules with different "types", then the most restrictive type should be applied. This is used in the "enhanced" CIODs to require more
    attributes than in the enhanced ones. E.g., this attribute

    https://dicom.innolitics.com/ciods/enhanced-ct-image/enhanced-general-equipment/00080070

    makes the Manufacturer a type 1 attribute in the Enhanced CT CIOD, overriding the type here

    https://dicom.innolitics.com/ciods/enhanced-ct-image/general-equipment/00080070 .

    (We've considered adding a strike-through over shadowed attributes in the DICOM standard browser, but haven't gotten to it.)

    Out of curiosity, why do you want to disambiguate the IE for attributes?
    On Wednesday, November 11, 2020 at 1:04:45 PM UTC-5, skrinakron wrote:
    Hello,

    I'm trying to understand how to obtain the module and information entity of any given attribute in the IOD of a given DICOM file. My problem is that in some cases this determination seems ambiguous. For example, the Multi-Frame Grayscale Byte SC Image IOD contains the General Series module in its Series IE and the SC Equipment module in its Equipment IE. Both of these modules contain the Modality attribute (0008,0060), and here the SC Equipment one takes precedence over the General Series one [1], so that in this IOD the attribute (0008,0060) is unambiguously in the SC Equipment module of the Equipment IE. However, the CT Performed Procedure Protocol IOD (for another example) contains the Protocol Context module in its Protocol Procedure IE and the General Series module in its Series IE; these modules both contain the Protocol Name attribute (0018,1030), for which no such precedence information is given [2][3]. If I come across a top-level (0018,1030) attribute (i.e. one not contained in a sequence) in a file of this IOD, how do I know which module -- and thus which information entity -- the attribute belongs to? Is this choice arbitrary, or should the attribute be considered to belong in both modules and IEs?

    These examples were found by toying around with the Innolitics machine-readable DICOM standard representation [4] with little understanding of the finer points of the standard itself. I'm sure I'm oversimplifying somewhere, I just haven't been able to figure out where. I'd be grateful for a nudge in the right direction.

    [1] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.8.6.html#para_ae37c804-87a0-42ec-a150-a16a92520fdc
    [2] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#para_4405d28d-db41-4b21-89b5-c74923935975
    [3] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.34.2.html#para_36611353-b3d4-463a-8923-c42cb3dfa3ca
    [4] https://github.com/innolitics/dicom-standard/tree/master/standard

    /skrin

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gunter zeilinger@21:1/5 to gunter zeilinger on Wed Jan 13 01:28:21 2021
    On Wednesday, January 13, 2021 at 10:05:13 AM UTC+1, gunter zeilinger wrote:
    The Type of an Attribute may also be "relaxed" by the IOD of a particular SOP Class. E.g. C.7.3.1 General Series Module includes Attribute Modality (0008,0060) with Type 1, but C.8.6.1 SC Equipment Module (which is itself included in IODs for Secondary
    Capture Images and Encapsulated Documents) includes Attribute Modality (0008,0060) with Type 3.

    Sorry, just recognized that skrinakron already pointed to that...
    I am also not aware of an explicit statement in the standard text, that the definition in IOD specifc modules overwrites the definition in more general modules - I just implies that overwrite rule from the meaning of "general" vs. "specific/particular"
    in common English language.

    On Tuesday, January 12, 2021 at 5:17:30 PM UTC+1, J. David Giese wrote:
    First of all, I'm glad to see that our machine-readable DICOM standard representation is being used.
    If I come across a
    top-level (0018,1030) attribute (i.e. one not contained in a sequence) in
    a file of this IOD, how do I know which module -- and thus which information entity -- the attribute belongs to? Is this choice arbitrary,
    or should the attribute be considered to belong in both modules and IEs?
    I have not come across anything in the standard that would answer this question. Perhaps this is because IEs and modules, other than dictating which attributes are required, don't influence how DICOM files or messages are encoded. Somewhere in the
    standard (although I couldn't find where), there is a comment that says if an attribute shows up in a couple of modules with different "types", then the most restrictive type should be applied. This is used in the "enhanced" CIODs to require more
    attributes than in the enhanced ones. E.g., this attribute

    https://dicom.innolitics.com/ciods/enhanced-ct-image/enhanced-general-equipment/00080070

    makes the Manufacturer a type 1 attribute in the Enhanced CT CIOD, overriding the type here

    https://dicom.innolitics.com/ciods/enhanced-ct-image/general-equipment/00080070 .

    (We've considered adding a strike-through over shadowed attributes in the DICOM standard browser, but haven't gotten to it.)

    Out of curiosity, why do you want to disambiguate the IE for attributes? On Wednesday, November 11, 2020 at 1:04:45 PM UTC-5, skrinakron wrote:
    Hello,

    I'm trying to understand how to obtain the module and information entity of any given attribute in the IOD of a given DICOM file. My problem is that in some cases this determination seems ambiguous. For example, the Multi-Frame Grayscale Byte SC Image IOD contains the General Series module
    in its Series IE and the SC Equipment module in its Equipment IE. Both of
    these modules contain the Modality attribute (0008,0060), and here the SC
    Equipment one takes precedence over the General Series one [1], so that in
    this IOD the attribute (0008,0060) is unambiguously in the SC Equipment module of the Equipment IE. However, the CT Performed Procedure Protocol IOD (for another example) contains the Protocol Context module in its Protocol Procedure IE and the General Series module in its Series IE; these modules both contain the Protocol Name attribute (0018,1030), for which no such precedence information is given [2][3]. If I come across a top-level (0018,1030) attribute (i.e. one not contained in a sequence) in
    a file of this IOD, how do I know which module -- and thus which information entity -- the attribute belongs to? Is this choice arbitrary,
    or should the attribute be considered to belong in both modules and IEs?

    These examples were found by toying around with the Innolitics machine-readable DICOM standard representation [4] with little understanding of the finer points of the standard itself. I'm sure I'm oversimplifying somewhere, I just haven't been able to figure out where. I'd be grateful for a nudge in the right direction.

    [1] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.8.6.html#para_ae37c804-87a0-42ec-a150-a16a92520fdc
    [2] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#para_4405d28d-db41-4b21-89b5-c74923935975
    [3] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.34.2.html#para_36611353-b3d4-463a-8923-c42cb3dfa3ca
    [4] https://github.com/innolitics/dicom-standard/tree/master/standard

    /skrin

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gunter zeilinger@21:1/5 to Ulrich Busch on Wed Jan 13 04:11:57 2021
    Right! I missed CP 132 ftp://medical.nema.org/medical/dicom/final/cp132_ft.pdf, which changed the "specific overwrites general" rule, to "most restrictive Type applies" - but with the amendment: "unless explicitly stated by the Attribute description"!
    And Table C.8-24. SC Equipment Module Attributes specifies as description for Modality (0008,0060), Type 3: "Source equipment for the image. This type definition shall override the definition in the General Series Module."

    So I think the specification is quite clear.

    On Wednesday, January 13, 2021 at 12:40:15 PM UTC+1, Ulrich Busch wrote:
    The specification of the resulting attribute types is in PS 3.3, C.1.2.3

    http://dicom.nema.org/medical/dicom/current/output/chtml/part03/chapter_C.html#sect_C.1.2.3

    When I read is correctly the rule is, that the most restrictive Type applies. Is this is correct, Type 3 of the Attribute Modality (0008,0060) in the SC Equipment Module does not override Type 1 in the General Series Module. It is rather a flaw of the
    specification (a demotion of a Type has no effect), maybe caused by a later addition of the General Series Module into the SC IODs.
    On Wednesday, January 13, 2021 at 10:28:24 AM UTC+1, gunter zeilinger wrote:
    On Wednesday, January 13, 2021 at 10:05:13 AM UTC+1, gunter zeilinger wrote:
    The Type of an Attribute may also be "relaxed" by the IOD of a particular SOP Class. E.g. C.7.3.1 General Series Module includes Attribute Modality (0008,0060) with Type 1, but C.8.6.1 SC Equipment Module (which is itself included in IODs for
    Secondary Capture Images and Encapsulated Documents) includes Attribute Modality (0008,0060) with Type 3.
    Sorry, just recognized that skrinakron already pointed to that...
    I am also not aware of an explicit statement in the standard text, that the definition in IOD specifc modules overwrites the definition in more general modules - I just implies that overwrite rule from the meaning of "general" vs. "specific/
    particular" in common English language.
    On Tuesday, January 12, 2021 at 5:17:30 PM UTC+1, J. David Giese wrote:
    First of all, I'm glad to see that our machine-readable DICOM standard representation is being used.
    If I come across a
    top-level (0018,1030) attribute (i.e. one not contained in a sequence) in
    a file of this IOD, how do I know which module -- and thus which information entity -- the attribute belongs to? Is this choice arbitrary,
    or should the attribute be considered to belong in both modules and IEs?
    I have not come across anything in the standard that would answer this question. Perhaps this is because IEs and modules, other than dictating which attributes are required, don't influence how DICOM files or messages are encoded. Somewhere in
    the standard (although I couldn't find where), there is a comment that says if an attribute shows up in a couple of modules with different "types", then the most restrictive type should be applied. This is used in the "enhanced" CIODs to require more
    attributes than in the enhanced ones. E.g., this attribute

    https://dicom.innolitics.com/ciods/enhanced-ct-image/enhanced-general-equipment/00080070

    makes the Manufacturer a type 1 attribute in the Enhanced CT CIOD, overriding the type here

    https://dicom.innolitics.com/ciods/enhanced-ct-image/general-equipment/00080070 .

    (We've considered adding a strike-through over shadowed attributes in the DICOM standard browser, but haven't gotten to it.)

    Out of curiosity, why do you want to disambiguate the IE for attributes?
    On Wednesday, November 11, 2020 at 1:04:45 PM UTC-5, skrinakron wrote:
    Hello,

    I'm trying to understand how to obtain the module and information entity
    of any given attribute in the IOD of a given DICOM file. My problem is
    that in some cases this determination seems ambiguous. For example, the
    Multi-Frame Grayscale Byte SC Image IOD contains the General Series module
    in its Series IE and the SC Equipment module in its Equipment IE. Both of
    these modules contain the Modality attribute (0008,0060), and here the SC
    Equipment one takes precedence over the General Series one [1], so that in
    this IOD the attribute (0008,0060) is unambiguously in the SC Equipment
    module of the Equipment IE. However, the CT Performed Procedure Protocol
    IOD (for another example) contains the Protocol Context module in its
    Protocol Procedure IE and the General Series module in its Series IE;
    these modules both contain the Protocol Name attribute (0018,1030), for
    which no such precedence information is given [2][3]. If I come across a
    top-level (0018,1030) attribute (i.e. one not contained in a sequence) in
    a file of this IOD, how do I know which module -- and thus which information entity -- the attribute belongs to? Is this choice arbitrary,
    or should the attribute be considered to belong in both modules and IEs?

    These examples were found by toying around with the Innolitics machine-readable DICOM standard representation [4] with little understanding of the finer points of the standard itself. I'm sure I'm
    oversimplifying somewhere, I just haven't been able to figure out where.
    I'd be grateful for a nudge in the right direction.

    [1] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.8.6.html#para_ae37c804-87a0-42ec-a150-a16a92520fdc
    [2] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#para_4405d28d-db41-4b21-89b5-c74923935975
    [3] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.34.2.html#para_36611353-b3d4-463a-8923-c42cb3dfa3ca
    [4] https://github.com/innolitics/dicom-standard/tree/master/standard

    /skrin

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ulrich Busch@21:1/5 to gunter zeilinger on Wed Jan 13 03:40:13 2021
    The specification of the resulting attribute types is in PS 3.3, C.1.2.3

    http://dicom.nema.org/medical/dicom/current/output/chtml/part03/chapter_C.html#sect_C.1.2.3

    When I read is correctly the rule is, that the most restrictive Type applies. Is this is correct, Type 3 of the Attribute Modality (0008,0060) in the SC Equipment Module does not override Type 1 in the General Series Module. It is rather a flaw of the
    specification (a demotion of a Type has no effect), maybe caused by a later addition of the General Series Module into the SC IODs.





    On Wednesday, January 13, 2021 at 10:28:24 AM UTC+1, gunter zeilinger wrote:
    On Wednesday, January 13, 2021 at 10:05:13 AM UTC+1, gunter zeilinger wrote:
    The Type of an Attribute may also be "relaxed" by the IOD of a particular SOP Class. E.g. C.7.3.1 General Series Module includes Attribute Modality (0008,0060) with Type 1, but C.8.6.1 SC Equipment Module (which is itself included in IODs for
    Secondary Capture Images and Encapsulated Documents) includes Attribute Modality (0008,0060) with Type 3.
    Sorry, just recognized that skrinakron already pointed to that...
    I am also not aware of an explicit statement in the standard text, that the definition in IOD specifc modules overwrites the definition in more general modules - I just implies that overwrite rule from the meaning of "general" vs. "specific/particular"
    in common English language.
    On Tuesday, January 12, 2021 at 5:17:30 PM UTC+1, J. David Giese wrote:
    First of all, I'm glad to see that our machine-readable DICOM standard representation is being used.
    If I come across a
    top-level (0018,1030) attribute (i.e. one not contained in a sequence) in
    a file of this IOD, how do I know which module -- and thus which information entity -- the attribute belongs to? Is this choice arbitrary,
    or should the attribute be considered to belong in both modules and IEs?
    I have not come across anything in the standard that would answer this question. Perhaps this is because IEs and modules, other than dictating which attributes are required, don't influence how DICOM files or messages are encoded. Somewhere in the
    standard (although I couldn't find where), there is a comment that says if an attribute shows up in a couple of modules with different "types", then the most restrictive type should be applied. This is used in the "enhanced" CIODs to require more
    attributes than in the enhanced ones. E.g., this attribute

    https://dicom.innolitics.com/ciods/enhanced-ct-image/enhanced-general-equipment/00080070

    makes the Manufacturer a type 1 attribute in the Enhanced CT CIOD, overriding the type here

    https://dicom.innolitics.com/ciods/enhanced-ct-image/general-equipment/00080070 .

    (We've considered adding a strike-through over shadowed attributes in the DICOM standard browser, but haven't gotten to it.)

    Out of curiosity, why do you want to disambiguate the IE for attributes? On Wednesday, November 11, 2020 at 1:04:45 PM UTC-5, skrinakron wrote:
    Hello,

    I'm trying to understand how to obtain the module and information entity
    of any given attribute in the IOD of a given DICOM file. My problem is that in some cases this determination seems ambiguous. For example, the
    Multi-Frame Grayscale Byte SC Image IOD contains the General Series module
    in its Series IE and the SC Equipment module in its Equipment IE. Both of
    these modules contain the Modality attribute (0008,0060), and here the SC
    Equipment one takes precedence over the General Series one [1], so that in
    this IOD the attribute (0008,0060) is unambiguously in the SC Equipment
    module of the Equipment IE. However, the CT Performed Procedure Protocol
    IOD (for another example) contains the Protocol Context module in its Protocol Procedure IE and the General Series module in its Series IE; these modules both contain the Protocol Name attribute (0018,1030), for
    which no such precedence information is given [2][3]. If I come across a
    top-level (0018,1030) attribute (i.e. one not contained in a sequence) in
    a file of this IOD, how do I know which module -- and thus which information entity -- the attribute belongs to? Is this choice arbitrary,
    or should the attribute be considered to belong in both modules and IEs?

    These examples were found by toying around with the Innolitics machine-readable DICOM standard representation [4] with little understanding of the finer points of the standard itself. I'm sure I'm oversimplifying somewhere, I just haven't been able to figure out where.
    I'd be grateful for a nudge in the right direction.

    [1] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.8.6.html#para_ae37c804-87a0-42ec-a150-a16a92520fdc
    [2] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#para_4405d28d-db41-4b21-89b5-c74923935975
    [3] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.34.2.html#para_36611353-b3d4-463a-8923-c42cb3dfa3ca
    [4] https://github.com/innolitics/dicom-standard/tree/master/standard

    /skrin

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From J. David Giese@21:1/5 to gunter zeilinger on Wed Jan 13 08:18:15 2021
    Ulrich, thanks for pointing to PS 3.3 C.1.2.3, that is indeed the section I had in mind, but couldn't find.

    On Wednesday, January 13, 2021 at 7:11:58 AM UTC-5, gunter zeilinger wrote:
    Right! I missed CP 132 ftp://medical.nema.org/medical/dicom/final/cp132_ft.pdf, which changed the "specific overwrites general" rule, to "most restrictive Type applies" - but with the amendment: "unless explicitly stated by the Attribute description"!
    And Table C.8-24. SC Equipment Module Attributes specifies as description for Modality (0008,0060), Type 3: "Source equipment for the image. This type definition shall override the definition in the General Series Module."

    So I think the specification is quite clear.
    On Wednesday, January 13, 2021 at 12:40:15 PM UTC+1, Ulrich Busch wrote:
    The specification of the resulting attribute types is in PS 3.3, C.1.2.3

    http://dicom.nema.org/medical/dicom/current/output/chtml/part03/chapter_C.html#sect_C.1.2.3

    When I read is correctly the rule is, that the most restrictive Type applies. Is this is correct, Type 3 of the Attribute Modality (0008,0060) in the SC Equipment Module does not override Type 1 in the General Series Module. It is rather a flaw of
    the specification (a demotion of a Type has no effect), maybe caused by a later addition of the General Series Module into the SC IODs.
    On Wednesday, January 13, 2021 at 10:28:24 AM UTC+1, gunter zeilinger wrote:
    On Wednesday, January 13, 2021 at 10:05:13 AM UTC+1, gunter zeilinger wrote:
    The Type of an Attribute may also be "relaxed" by the IOD of a particular SOP Class. E.g. C.7.3.1 General Series Module includes Attribute Modality (0008,0060) with Type 1, but C.8.6.1 SC Equipment Module (which is itself included in IODs for
    Secondary Capture Images and Encapsulated Documents) includes Attribute Modality (0008,0060) with Type 3.
    Sorry, just recognized that skrinakron already pointed to that...
    I am also not aware of an explicit statement in the standard text, that the definition in IOD specifc modules overwrites the definition in more general modules - I just implies that overwrite rule from the meaning of "general" vs. "specific/
    particular" in common English language.
    On Tuesday, January 12, 2021 at 5:17:30 PM UTC+1, J. David Giese wrote:
    First of all, I'm glad to see that our machine-readable DICOM standard representation is being used.
    If I come across a
    top-level (0018,1030) attribute (i.e. one not contained in a sequence) in
    a file of this IOD, how do I know which module -- and thus which information entity -- the attribute belongs to? Is this choice arbitrary,
    or should the attribute be considered to belong in both modules and IEs?
    I have not come across anything in the standard that would answer this question. Perhaps this is because IEs and modules, other than dictating which attributes are required, don't influence how DICOM files or messages are encoded. Somewhere in
    the standard (although I couldn't find where), there is a comment that says if an attribute shows up in a couple of modules with different "types", then the most restrictive type should be applied. This is used in the "enhanced" CIODs to require more
    attributes than in the enhanced ones. E.g., this attribute

    https://dicom.innolitics.com/ciods/enhanced-ct-image/enhanced-general-equipment/00080070

    makes the Manufacturer a type 1 attribute in the Enhanced CT CIOD, overriding the type here

    https://dicom.innolitics.com/ciods/enhanced-ct-image/general-equipment/00080070 .

    (We've considered adding a strike-through over shadowed attributes in the DICOM standard browser, but haven't gotten to it.)

    Out of curiosity, why do you want to disambiguate the IE for attributes?
    On Wednesday, November 11, 2020 at 1:04:45 PM UTC-5, skrinakron wrote:
    Hello,

    I'm trying to understand how to obtain the module and information entity
    of any given attribute in the IOD of a given DICOM file. My problem is
    that in some cases this determination seems ambiguous. For example, the
    Multi-Frame Grayscale Byte SC Image IOD contains the General Series module
    in its Series IE and the SC Equipment module in its Equipment IE. Both of
    these modules contain the Modality attribute (0008,0060), and here the SC
    Equipment one takes precedence over the General Series one [1], so that in
    this IOD the attribute (0008,0060) is unambiguously in the SC Equipment
    module of the Equipment IE. However, the CT Performed Procedure Protocol
    IOD (for another example) contains the Protocol Context module in its
    Protocol Procedure IE and the General Series module in its Series IE;
    these modules both contain the Protocol Name attribute (0018,1030), for
    which no such precedence information is given [2][3]. If I come across a
    top-level (0018,1030) attribute (i.e. one not contained in a sequence) in
    a file of this IOD, how do I know which module -- and thus which information entity -- the attribute belongs to? Is this choice arbitrary,
    or should the attribute be considered to belong in both modules and IEs?

    These examples were found by toying around with the Innolitics machine-readable DICOM standard representation [4] with little understanding of the finer points of the standard itself. I'm sure I'm
    oversimplifying somewhere, I just haven't been able to figure out where.
    I'd be grateful for a nudge in the right direction.

    [1] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.8.6.html#para_ae37c804-87a0-42ec-a150-a16a92520fdc
    [2] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#para_4405d28d-db41-4b21-89b5-c74923935975
    [3] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.34.2.html#para_36611353-b3d4-463a-8923-c42cb3dfa3ca
    [4] https://github.com/innolitics/dicom-standard/tree/master/standard

    /skrin

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From skrinakron@21:1/5 to John Giese on Sun Jan 24 23:27:33 2021
    Thanks for all your replies! Following your references to PS3.3 C.1.2.3
    and CP-132 confirms that I was indeeed missing the role of type
    designations. This clears up most of my confusion. While the special case
    of Modality in SC Equipment vs. General Series can apparently not be
    derived programmatically, at least it's a relatively easy singular
    exception to add.

    However, there's still one point I find unclear. The Trigger Source or
    Type attribute (0018,1061) is included twice in two IODs as follows.
    NM Image IOD: Frame of Reference IE, Synchronization module, type 3 / Image IE, NM Image module, type 3
    Enhanced PET Image IOD: Frame of Reference IE, Synchronization module, type 3 / Series IE, PET Multi-Gated Acquisition module, type 3
    Now, the type designation of this attribute in both IODs is clearly 3 (optional), but, as neither of the types is lower than the other, which module/IE takes precedence if this attribute is present (per PS3.3 6.2 at
    most once)? Does the same trigger ID or description always apply to both synchronization and series/image, making the choice arbitrary? It doesn't
    look like this association can be inferred from the attribute value,
    either.

    On Tue, 12 Jan 2021, John Giese wrote:
    Out of curiosity, why do you want to disambiguate the IE for attributes?

    PS3.3 C7.6.6.1.1 contains language specific to attributes in the Image IE
    [1], so I set out to see how these attributes could be identified and fell
    down the rabbit hole that is the DICOM information model. In addition to handling multi-frame files, it would be kind of neat to have a viewer that
    can display the macro and module of each attribute in a data set. Macros
    are straightforward in this respect, whereas modules turned out to be more involved.

    On Tue, 12 Jan 2021, John Giese wrote:
    I'm glad to see that our machine-readable DICOM standard representation
    is being used.

    It's honestly been the single most useful resource I've found in trying to
    make sense of the entirety of the specification. Thank you for providing
    it to the community.

    [1] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.6.html#sect_C.7.6.6.1.1

    /skrin

    On Wed, 13 Jan 2021, J. David Giese wrote:
    Ulrich, thanks for pointing to PS 3.3 C.1.2.3, that is indeed the section I had in mind, but couldn't find.

    On Wednesday, January 13, 2021 at 7:11:58 AM UTC-5, gunter zeilinger wrote:
    Right! I missed CP 132 ftp://medical.nema.org/medical/dicom/final/cp132_ft.pdf, which changed the "specific overwrites general" rule, to "most restrictive Type applies" - but with the amendment: "unless explicitly stated by the Attribute description"!
    And Table C.8-24. SC Equipment Module Attributes specifies as description for Modality (0008,0060), Type 3: "Source equipment for the image. This type definition shall override the definition in the General Series Module."

    So I think the specification is quite clear.
    On Wednesday, January 13, 2021 at 12:40:15 PM UTC+1, Ulrich Busch wrote:
    The specification of the resulting attribute types is in PS 3.3, C.1.2.3 >>>
    http://dicom.nema.org/medical/dicom/current/output/chtml/part03/chapter_C.html#sect_C.1.2.3

    When I read is correctly the rule is, that the most restrictive Type applies. Is this is correct, Type 3 of the Attribute Modality (0008,0060) in the SC Equipment Module does not override Type 1 in the General Series Module. It is rather a flaw of
    the specification (a demotion of a Type has no effect), maybe caused by a later addition of the General Series Module into the SC IODs.
    On Wednesday, January 13, 2021 at 10:28:24 AM UTC+1, gunter zeilinger wrote:
    On Wednesday, January 13, 2021 at 10:05:13 AM UTC+1, gunter zeilinger wrote:
    The Type of an Attribute may also be "relaxed" by the IOD of a particular SOP Class. E.g. C.7.3.1 General Series Module includes Attribute Modality (0008,0060) with Type 1, but C.8.6.1 SC Equipment Module (which is itself included in IODs for
    Secondary Capture Images and Encapsulated Documents) includes Attribute Modality (0008,0060) with Type 3.
    Sorry, just recognized that skrinakron already pointed to that...
    I am also not aware of an explicit statement in the standard text, that the definition in IOD specifc modules overwrites the definition in more general modules - I just implies that overwrite rule from the meaning of "general" vs. "specific/
    particular" in common English language.
    On Tuesday, January 12, 2021 at 5:17:30 PM UTC+1, J. David Giese wrote: >>>>>> First of all, I'm glad to see that our machine-readable DICOM standard representation is being used.
    If I come across a
    top-level (0018,1030) attribute (i.e. one not contained in a sequence) in
    a file of this IOD, how do I know which module -- and thus which >>>>>>> information entity -- the attribute belongs to? Is this choice arbitrary,
    or should the attribute be considered to belong in both modules and IEs?
    I have not come across anything in the standard that would answer this question. Perhaps this is because IEs and modules, other than dictating which attributes are required, don't influence how DICOM files or messages are encoded. Somewhere in the
    standard (although I couldn't find where), there is a comment that says if an attribute shows up in a couple of modules with different "types", then the most restrictive type should be applied. This is used in the "enhanced" CIODs to require more
    attributes than in the enhanced ones. E.g., this attribute

    https://dicom.innolitics.com/ciods/enhanced-ct-image/enhanced-general-equipment/00080070

    makes the Manufacturer a type 1 attribute in the Enhanced CT CIOD, overriding the type here

    https://dicom.innolitics.com/ciods/enhanced-ct-image/general-equipment/00080070 .

    (We've considered adding a strike-through over shadowed attributes in the DICOM standard browser, but haven't gotten to it.)

    Out of curiosity, why do you want to disambiguate the IE for attributes? >>>>>> On Wednesday, November 11, 2020 at 1:04:45 PM UTC-5, skrinakron wrote: >>>>>>> Hello,

    I'm trying to understand how to obtain the module and information entity
    of any given attribute in the IOD of a given DICOM file. My problem is >>>>>>> that in some cases this determination seems ambiguous. For example, the >>>>>>> Multi-Frame Grayscale Byte SC Image IOD contains the General Series module
    in its Series IE and the SC Equipment module in its Equipment IE. Both of
    these modules contain the Modality attribute (0008,0060), and here the SC
    Equipment one takes precedence over the General Series one [1], so that in
    this IOD the attribute (0008,0060) is unambiguously in the SC Equipment >>>>>>> module of the Equipment IE. However, the CT Performed Procedure Protocol
    IOD (for another example) contains the Protocol Context module in its >>>>>>> Protocol Procedure IE and the General Series module in its Series IE; >>>>>>> these modules both contain the Protocol Name attribute (0018,1030), for >>>>>>> which no such precedence information is given [2][3]. If I come across a
    top-level (0018,1030) attribute (i.e. one not contained in a sequence) in
    a file of this IOD, how do I know which module -- and thus which >>>>>>> information entity -- the attribute belongs to? Is this choice arbitrary,
    or should the attribute be considered to belong in both modules and IEs?

    These examples were found by toying around with the Innolitics
    machine-readable DICOM standard representation [4] with little
    understanding of the finer points of the standard itself. I'm sure I'm >>>>>>> oversimplifying somewhere, I just haven't been able to figure out where.
    I'd be grateful for a nudge in the right direction.

    [1] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.8.6.html#para_ae37c804-87a0-42ec-a150-a16a92520fdc
    [2] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#para_4405d28d-db41-4b21-89b5-c74923935975
    [3] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.34.2.html#para_36611353-b3d4-463a-8923-c42cb3dfa3ca
    [4] https://github.com/innolitics/dicom-standard/tree/master/standard >>>>>>>
    /skrin


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From J. David Giese@21:1/5 to All on Mon Jan 25 09:44:12 2021
    However, there's still one point I find unclear. The Trigger Source or
    Type attribute (0018,1061) is included twice in two IODs as follows.
    NM Image IOD: Frame of Reference IE, Synchronization module, type 3 / Image IE, NM Image module, type 3
    Enhanced PET Image IOD: Frame of Reference IE, Synchronization module, type 3 / Series IE, PET Multi-Gated Acquisition module, type 3
    Now, the type designation of this attribute in both IODs is clearly 3 (optional), but, as neither of the types is lower than the other, which module/IE takes precedence if this attribute is present (per PS3.3 6.2 at most once)? Does the same trigger ID or description always apply to both synchronization and series/image, making the choice arbitrary? It doesn't look like this association can be inferred from the attribute value,
    either.

    Good question. I don't know. It does seem that the two are redundant since the NM Image module is mandatory and the Synchronization module is user optional.

    https://dicom.innolitics.com/ciods/nm-image/synchronization/00181061 https://dicom.innolitics.com/ciods/nm-image/nm-image/00181061

    On Tue, 12 Jan 2021, John Giese wrote:
    I'm glad to see that our machine-readable DICOM standard representation
    is being used.
    It's honestly been the single most useful resource I've found in trying to make sense of the entirety of the specification. Thank you for providing
    it to the community.

    I'm glad to hear it. Would you mind if we used this quote on our website? If not, please email info@innolitics.com the name you'd like us to include with it. We'd really appreciate it.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gunter zeilinger@21:1/5 to All on Wed Jan 27 10:29:38 2021
    However, there's still one point I find unclear. The Trigger Source or
    Type attribute (0018,1061) is included twice in two IODs as follows.
    NM Image IOD: Frame of Reference IE, Synchronization module, type 3 / Image IE, NM Image module, type 3
    Enhanced PET Image IOD: Frame of Reference IE, Synchronization module, type 3 / Series IE, PET Multi-Gated Acquisition module, type 3
    Now, the type designation of this attribute in both IODs is clearly 3 (optional), but, as neither of the types is lower than the other, which module/IE takes precedence if this attribute is present (per PS3.3 6.2 at most once)? Does the same trigger ID or description always apply to both synchronization and series/image, making the choice arbitrary? It doesn't look like this association can be inferred from the attribute value,
    either.

    In the case of the NM Image IOD, the question about IE/module precedence has also practical consequences: if the Image IE, NM Image module takes precedence, the value of the attribute may vary over instances (=multi-frame images) belonging to the same
    series, otherwise - if the Frame of Reference IE, Synchronization module takes precedence, the value of the attribute has to be equal for all instances of one series.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Skrinakron@21:1/5 to J. David Giese on Wed Jan 27 23:12:53 2021
    On Mon, 25 Jan 2021, J. David Giese wrote:
    However, there's still one point I find unclear. The Trigger Source or
    Type attribute (0018,1061) is included twice in two IODs as follows.
    NM Image IOD: Frame of Reference IE, Synchronization module, type 3 / Image IE, NM Image module, type 3
    Enhanced PET Image IOD: Frame of Reference IE, Synchronization module, type 3 / Series IE, PET Multi-Gated Acquisition module, type 3
    Now, the type designation of this attribute in both IODs is clearly 3
    (optional), but, as neither of the types is lower than the other, which
    module/IE takes precedence if this attribute is present (per PS3.3 6.2 at
    most once)? Does the same trigger ID or description always apply to both
    synchronization and series/image, making the choice arbitrary? It doesn't
    look like this association can be inferred from the attribute value,
    either.

    Good question. I don't know. It does seem that the two are redundant since the NM Image module is mandatory and the Synchronization module is user optional.

    https://dicom.innolitics.com/ciods/nm-image/synchronization/00181061 https://dicom.innolitics.com/ciods/nm-image/nm-image/00181061

    Yes, the Synchronization module is only required if time synchronization
    has been applied [1]. Though there's no similar recourse to usage patterns
    in the PET Image IOD case (not Enhanced PET -- that was an error in my
    earlier post), as both the PET Multi-gated Acquisition and Synchronization modules are conditional instead of mandatory [2]. Further, if the
    acquisition was both gated and synchronized, both modules are required
    here and, being optional, the attribute could then be associated with
    either one and absent in the other.

    On Tue, 12 Jan 2021, John Giese wrote:
    I'm glad to see that our machine-readable DICOM standard representation
    is being used.
    It's honestly been the single most useful resource I've found in trying to >> make sense of the entirety of the specification. Thank you for providing
    it to the community.

    I'm glad to hear it. Would you mind if we used this quote on our website? If not, please email info@innolitics.com the name you'd like us to include with it. We'd really appreciate it.

    By all means! However, as I don't hold a relevant position or title
    anywhere, not even as a software developer, I'm afraid my name would only amount to "some random person on the internet". Maybe you could just refer
    to this thread for context?


    [1] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_A.5.4.html#para_edc74845-b433-4444-8140-a40e3fa08cf8
    [2] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_A.21.3.html

    /skrin

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From skrinakron@21:1/5 to gunter zeilinger on Sat Feb 6 17:39:19 2021
    On Wed, 27 Jan 2021, gunter zeilinger wrote:
    In the case of the NM Image IOD, the question about IE/module precedence
    has also practical consequences: if the Image IE, NM Image module takes precedence, the value of the attribute may vary over instances
    (=multi-frame images) belonging to the same series, otherwise - if the
    Frame of Reference IE, Synchronization module takes precedence, the
    value of the attribute has to be equal for all instances of one series.

    Oh, indeed! This is very relevant in that we could look at real-world
    datasets to see whether the value of the attribute varies or not. However,
    I'm afraid our institution doesn't have nuclear medicine studies, and even
    if there happens to be one somewhere on our archived media, it may well
    not be multi-frame.

    So in the absence of this experimental verification or a data model-based argument, here's what I think I'll be doing to resolve which module an attribute belongs to:
    1. If the attribute is (0008,0060) Modality, always prefer SC Equipment
    module over General Series.
    2. Otherwise pick the module that has the lower type designation for the
    attribute: 1(C) < 2(C) < 3. The conditional variants can be considered
    equivalent to their respective required ones here since a 1C/2C
    attribute should not have been included in the dataset we received if
    its condition wasn't met, and if the condition is met, the attribute is
    required.
    3. If the type designation for both modules has equal precedence,
    3a. prefer the mandatory module, meaning NM Image over Synchronization
    for (0018,1061) Trigger Source or Type and General Series over
    Patient Protocol Context for (0018,990D) Referenced Performed
    Protocol Sequence*
    3b. or, if neither module is mandatory, go with the one listed first,
    meaning PET Multi-gated Acquisition over Synchronization for
    (0018,1061) Trigger Source or Type.

    This could be further refined by inspecting module conditions in the
    dataset at runtime, but it doesn't really seem worth the effort if I still don't know which module to pick when both have their conditions met in 3b.

    Thanks again for the input, everybody. It's certainly made these
    complexities of DICOM clearer, even if I'm still not entirely convinced
    they're not mostly artifacts of the way the standard was put together.


    *) The Patient Protocol Context module seems sort of redundant here
    anyway: it only consists of (0018,990D), which is already mandatory in
    General Series if a Performed Procedure Protocol Instance was created [1].
    If the only way to tell which module the attribute is in is whether the referenced performed procedure protocol was created in the same study or elsewhere, there's no way to know based just on the single series dataset.

    [1] http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#para_f6ef0ba7-e40e-400e-9158-e37fd2faa10a

    /skrin

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)