DICOM Hanging Protocol Image Set Selector Sequence Proposal - DICOM

This is a discussion on DICOM Hanging Protocol Image Set Selector Sequence Proposal - DICOM ; The DICOM Hanging Protocol standard only allows literal definition of attribute values in the image set selector sequence and display set filtering and sorting operations sequences. This can be quite limiting. For instance it seems impossible to define a single ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: DICOM Hanging Protocol Image Set Selector Sequence Proposal

  1. DICOM Hanging Protocol Image Set Selector Sequence Proposal

    The DICOM Hanging Protocol standard only allows literal definition of
    attribute values in the image set selector sequence and display set
    filtering and sorting operations sequences. This can be quite limiting.
    For instance it seems impossible to define a single hanging protocol
    that covers the display of current and prior CR\DX studies of the same
    body part.

    Let me try to be a little more specific. Consider the case that as a
    general default I want to create a hanging protocol for x-ray type
    studies that show the primary study as well as the newest prior of *the
    same* body part. This is impossible to do with one hanging protocol,
    since I cannot specify that I want the secondary studies to have the
    same attributes as the primary study. I can only specify literal values.
    This means I need a separate hanging protocol for wrists, elbow,
    shoulder, knee etc, where I might otherwise do with only one. At the
    company where I work we have worked around this problem by extending the
    interpretation of the image set selector sequence etc to recognize a
    special literal '_same_'. When '_same_' is encountered the literal is
    substituted with the set of values defined in the primary study for this
    attribute.

    The hanging protocol below is for CR\DX of bones. If the user applies it
    to a CR\DX study of a left wrist then the hanging protocol will only
    consider priors with the same anatomical region sequence and laterality.

    == HP: Basic X-ray for bones

    Definition sequence:
    * Modality: CR\DX
    * Anatomical-region-seq.: Wrist, Elbow, Shoulder, Knee, Ankle, etc..

    Image Set Sequence:
    * Image set
    * Modality: CR\DX
    * Anatomical-region-seq.: _same_
    * Laterality: _same_

    * Time based image set:
    * image set 1: Current
    * image set 2: Prior

    Display Set Sequence:
    * Display Set 1
    * Display set box: "on the left"
    * Image set reference: 1
    * Display Set 2
    * Display set box: "on the right"
    * Image set reference: 2



    My question is this: Is this a strange use case, or would the DICOM
    standard benefit from such an extension. The implementation of the
    extension using a special literal '_same_' is probably not appropriate
    for formalization, but the underlying concept of using values from the
    primary study instead of only literals might be.

    br,

    Thomas Sondergaard

  2. Re: DICOM Hanging Protocol Image Set Selector Sequence Proposal

    I have forwarded your email to WG 11 for the authors of the
    supplement to consider.

    You might want to think about joining that list, since you
    have gone to the trouble of implementing this stuff.

    David

    Thomas Sondergaard wrote:

    > The DICOM Hanging Protocol standard only allows literal definition of
    > attribute values in the image set selector sequence and display set
    > filtering and sorting operations sequences. This can be quite limiting.
    > For instance it seems impossible to define a single hanging protocol
    > that covers the display of current and prior CR\DX studies of the same
    > body part.
    >
    > Let me try to be a little more specific. Consider the case that as a
    > general default I want to create a hanging protocol for x-ray type
    > studies that show the primary study as well as the newest prior of *the
    > same* body part. This is impossible to do with one hanging protocol,
    > since I cannot specify that I want the secondary studies to have the
    > same attributes as the primary study. I can only specify literal values.
    > This means I need a separate hanging protocol for wrists, elbow,
    > shoulder, knee etc, where I might otherwise do with only one. At the
    > company where I work we have worked around this problem by extending the
    > interpretation of the image set selector sequence etc to recognize a
    > special literal '_same_'. When '_same_' is encountered the literal is
    > substituted with the set of values defined in the primary study for this
    > attribute.
    >
    > The hanging protocol below is for CR\DX of bones. If the user applies it
    > to a CR\DX study of a left wrist then the hanging protocol will only
    > consider priors with the same anatomical region sequence and laterality.
    >
    > == HP: Basic X-ray for bones
    >
    > Definition sequence:
    > * Modality: CR\DX
    > * Anatomical-region-seq.: Wrist, Elbow, Shoulder, Knee, Ankle, etc..
    >
    > Image Set Sequence:
    > * Image set
    > * Modality: CR\DX
    > * Anatomical-region-seq.: _same_
    > * Laterality: _same_
    >
    > * Time based image set:
    > * image set 1: Current
    > * image set 2: Prior
    >
    > Display Set Sequence:
    > * Display Set 1
    > * Display set box: "on the left"
    > * Image set reference: 1
    > * Display Set 2
    > * Display set box: "on the right"
    > * Image set reference: 2
    >
    >
    >
    > My question is this: Is this a strange use case, or would the DICOM
    > standard benefit from such an extension. The implementation of the
    > extension using a special literal '_same_' is probably not appropriate
    > for formalization, but the underlying concept of using values from the
    > primary study instead of only literals might be.
    >
    > br,
    >
    > Thomas Sondergaard


  3. Re: DICOM Hanging Protocol Image Set Selector Sequence Proposal

    Hi David,

    Good idea, I'll do that!

    Thanks,

    Thomas


    David Clunie wrote:

    > You might want to think about joining that list, since you
    > have gone to the trouble of implementing this stuff.


+ Reply to Thread