Relationships between Modules - DICOM

This is a discussion on Relationships between Modules - DICOM ; Ok, this may seem like a retarded newbie question, but that's only because I'm a retarded newbie. :-) I kind of look at a DICOM data set as containing an IOD (perhaps more than one), which contains a list of ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Relationships between Modules

  1. Relationships between Modules

    Ok, this may seem like a retarded newbie question, but that's only
    because I'm a retarded newbie. :-)

    I kind of look at a DICOM data set as containing an IOD (perhaps more
    than one), which contains a list of Information Entities, which contain
    Modules, which contain lists of Tags. I got this idea from the figure
    on page 7 of the Phillips document, which seems to be highly regarded
    in this community.

    (A copy of said document is at
    http://www.unifesp.br/dis/set/discip...OMCookbook.pdf
    in case anyone wants to see the figure 1-4 that was the source of my
    impressions about DICOM IODs, IEs, Modules, Tags/Attributes and their
    relationship to each other.)

    I long ago gave up on the Information Entity part of this hierarchy, as
    far as my implementation goes, so for my implementation an IOD directly
    contains Modules, which in turn contain Tags.

    The problem with this simplistic view of the world is that, much to my
    surprise, the same tag can appear in two different Modules in the same
    IOD!! I hadn't anticipated that this might be the case.

    So, for the "Digital Intra-Oral X-Ray Image For Presentation" IOD, for
    example, the Image Type (0008,0008) tag appears in both the "General
    Image Module" and the "DX Image Module"... ok, so this might lead me to
    believe that the DX Image Module is a specialization of the General
    Image Module... or vice versa, but a quick perusal of these two modules
    shows that while they have several tags in common, they are clearly not
    specializations of each other and are quite distinct.

    So, supposing that you have the following structure, inspired by the
    Phillips document:

    class Tag_0008_0008 : Tag
    {
    // ... instance data ...
    };

    // ... more tags...

    class Module_GeneralImage : Module
    {
    // ... more tags ...
    Tag_0008_0008 *imageType;
    }

    class Module_DXImage : Module
    {
    // ... more tags ...
    Tag_0008_0008 *imageType;
    }

    // ... More Modules ...

    class DigitalIntraOralXray {
    Module_GeneralImage *generalImageModule;
    Module_DXImage *dxImageModule;
    // ... more modules ...
    }

    So the question is: Which imageType should win when the data set is
    written to a file or the network?

    This discovery is very disconcerting to me... and it's not an isolated
    thing, the Intra-Oral IOD mentioned above has 38 such collisions
    including one case where it's in there three times!!!

    Perhaps the most hilarious part of this is that tag (0008,0008) is Type
    1 in one of the modules and Type 3 in another...

    Does the term Module have ANY real meaning at all? I'm just depressed.
    I can see no real structure to IODs at all, other than as a list of
    tags.

    Was this intentional? I just can't believe it is this way on purpose.

    -Kelly


  2. Re: Relationships between Modules

    My understanding is that Module is a kinda concept of high level. One
    tag maybe related to more than one module. But from low level, tags in
    a dicom image are listed in ascending order and never repeat (except in
    a sequence).


  3. Re: Relationships between Modules

    Hi Kelly

    PS 3.3 3.8.12 Specialization:

    "Specialization is the replacement of the Type, value range
    and/or description of an Attribute in a general Module of an
    IOD, by its Type, value range and/or description defined in
    a modality-specific Module of an IOD.

    Note: The same Attribute may be present in multiple Modules in
    the same IOD but not specified to be “Specialized”."

    kellyatdentrix@gmail.com wrote:

    ....
    > The problem with this simplistic view of the world is that, much to my
    > surprise, the same tag can appear in two different Modules in the same
    > IOD!! I hadn't anticipated that this might be the case.
    >
    > So, for the "Digital Intra-Oral X-Ray Image For Presentation" IOD, for
    > example, the Image Type (0008,0008) tag appears in both the "General
    > Image Module" and the "DX Image Module"... ok, so this might lead me to
    > believe that the DX Image Module is a specialization of the General
    > Image Module... or vice versa, but a quick perusal of these two modules
    > shows that while they have several tags in common, they are clearly not
    > specializations of each other and are quite distinct.
    >

    ....
    >
    > class Module_GeneralImage : Module
    > {
    > // ... more tags ...
    > Tag_0008_0008 *imageType;
    > }
    >
    > class Module_DXImage : Module
    > {
    > // ... more tags ...
    > Tag_0008_0008 *imageType;
    > }
    >
    > // ... More Modules ...
    >
    > class DigitalIntraOralXray {
    > Module_GeneralImage *generalImageModule;
    > Module_DXImage *dxImageModule;
    > // ... more modules ...
    > }
    >
    > So the question is: Which imageType should win when the data set is
    > written to a file or the network?


    That in the modality-specific Module, Module_DXImage in this case.

    > This discovery is very disconcerting to me... and it's not an isolated
    > thing, the Intra-Oral IOD mentioned above has 38 such collisions
    > including one case where it's in there three times!!!
    >
    > Perhaps the most hilarious part of this is that tag (0008,0008) is Type
    > 1 in one of the modules and Type 3 in another...
    >
    > Does the term Module have ANY real meaning at all? I'm just depressed.
    > I can see no real structure to IODs at all, other than as a list of
    > tags.
    >
    > Was this intentional? I just can't believe it is this way on purpose.


    It is intentional.

    It just doesn't happen to fit the object-oriented programmer's
    understanding of classes that at first sight it appears to
    mimic.

    David

  4. Re: Relationships between Modules

    David Clunie wrote:
    > Hi Kelly


    Hi Dave.

    > Note: The same Attribute may be present in multiple Modules in
    > the same IOD but not specified to be "Specialized"."


    So how does one tell which Tag instance wins? That is, which module's
    description of a particular tag gets written out to the file, since
    only one instance of the tag is actually written out? Or are they all
    assumed to have an equal value?

    How does one tell which Module is the "modality-specific" Module of an
    IOD? By the name and intuition, or are there some specific rules
    somewhere?

    > > Was this intentional? I just can't believe it is this way on purpose.

    >
    > It is intentional.
    >
    > It just doesn't happen to fit the object-oriented programmer's
    > understanding of classes that at first sight it appears to
    > mimic.


    You can say that again! :-)

    I guess I should not be surprised by this, seeing as how DICOM was
    invented so long ago. What does surprise me, I guess, is how long it
    took to figure this out. It's difficult for me to understand a system
    that has so many things implemented completely differently than I would
    have implemented them.

    Maybe there should be a DICOM for Object-Oriented Dummies book ;-)

    I'm really unhappy that the Phillips document that is so highly touted
    would lead one down this particular primrose path.

    -Kelly


+ Reply to Thread