TID CID etc. - DICOM

This is a discussion on TID CID etc. - DICOM ; I thought I was getting my mind around the DICOM standard when I ran into discussion of TIDs and CIDs... It seemed that they were shorthand for the specification... Then I ran into this tag: Tag (0040,DB00)the "Template Identifier" The ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: TID CID etc.

  1. TID CID etc.

    I thought I was getting my mind around the DICOM standard when I ran
    into discussion of TIDs and CIDs... It seemed that they were shorthand
    for the specification...

    Then I ran into this tag:
    Tag (0040,DB00)the "Template Identifier"

    The standard is interestingly silent on the purpose of this tag... or
    if it has anything to do with TIDs.

    Could someone shed light on the purpose of this tag, as well as the
    general concept of what TID and CID are used for and how they fit into
    the "big picture"?

    Thanks in advance!!

    -Kelly


  2. Re: TID CID etc.

    kellyatdentrix@gmail.com wrote:

    > Could someone shed light on the purpose of this tag, as well as the
    > general concept of what TID and CID are used for and how they fit
    > into the "big picture"?


    Did you already read the book "DICOM Structured Reporting" from David
    Clunie? It can be downloaded from: http://www.pixelmed.com/srbook.html

    Regards,
    Joerg Riesmeier

  3. Re: TID CID etc.

    These relate primarily to Structured Reports.

    Have you read Section 9 of DICOM Part 3?
    There at least some whisperings to read there.
    Also read the reference to the Template Identification
    Macro in Table C.17-6.

    The TID identifies the template of content item of
    the templates root. The intent is that a parser can
    use the TID to assist parsing the SR document.

    Similarly, the CID identifies the Context Group of
    from which a code is selected. See Section 8.

    DICOM Part 16 gives Templates and Context Group definitions.

    - Doug

    wrote in message
    news:1110212121.782432.82460@g14g2000cwa.googlegro ups.com...
    >I thought I was getting my mind around the DICOM standard when I ran
    > into discussion of TIDs and CIDs... It seemed that they were shorthand
    > for the specification...
    >
    > Then I ran into this tag:
    > Tag (0040,DB00)the "Template Identifier"
    >
    > The standard is interestingly silent on the purpose of this tag... or
    > if it has anything to do with TIDs.
    >
    > Could someone shed light on the purpose of this tag, as well as the
    > general concept of what TID and CID are used for and how they fit into
    > the "big picture"?
    >
    > Thanks in advance!!
    >
    > -Kelly
    >




  4. Re: TID CID etc.

    Hi Kelly

    kellyatdentrix@gmail.com wrote:
    > I thought I was getting my mind around the DICOM standard when I ran
    > into discussion of TIDs and CIDs... It seemed that they were shorthand
    > for the specification...
    >
    > Then I ran into this tag:
    > Tag (0040,DB00) the "Template Identifier"
    >
    > The standard is interestingly silent on the purpose of this tag... or
    > if it has anything to do with TIDs.
    >
    > Could someone shed light on the purpose of this tag, as well as the
    > general concept of what TID and CID are used for and how they fit into
    > the "big picture"?


    There are two schools of thought with respect to what a receiver of
    a DICOM SR should be able to do:

    1. examine the structure of whatever is encoded and match it to known
    patterns to determine a rendering or extraction of the relevant data

    2. key off a "template ID" that is encoded in the object and then
    extract data from where it is expected to be based on that template

    Sort of an XSL-T push versus pull model issue, if you known what I
    mean by that.

    Some amongst us believe that the only safe way to do the latter is
    to tie the template used, at least at the root level, to a specific
    SOP Class. This is the approach used by the Mammo and Chest CAD
    objects for example - the SOP Class specifies the use of a particular
    template, and this any TID encoded in the instance is irrelevant.

    Other applications are "less demanding" in terms of the interoperability
    requirements, ostensibly, and hence use generic SR SOP classes which
    can encoded any of a myriad of standard or other templates; this places
    the burden on the receiver to behave reasonably when it gets content
    that it doesn't recognize, either because it doesn't recognize the TID
    encoded in (0040,DB00) at the root content item, or because the object
    just doesn't match any recognized template.

    One of the advantages of the pattern matching approach that I have
    always encouraged, is that one can recognize similar patterns even
    if the SR object was created without a particular template use in
    mind; this may be naive in the general case, but actually works
    surprisingly well for simple documents because de novo attempts
    to use SR to do simple things tend to reinvent the same or very
    similar constructs.

    There is obviously a tradeoff here between generality to allow rapid
    adaptation to new applications, and meeting user's interoperability
    expectations.

    Personally I believe that there is way too much unnecessary "fear of
    SOP Class proliferation", that if one can be bothered to define a
    standard template then one should bother to add a UID for a corresponding
    SOP Class, and that encoding "template ID" in band as well would be
    completely redundant. Indeed, we added the SOP Class inheritance
    mechanism specifically for this use case to allow older devices to
    recognize new SOP Classes of this type easily (see Sup 90).

    However, through laziness, inertia or distraction, we don't seem to
    have gotten around to adding many of these template-specific SOP Classes
    in many cases yet.

    Anyway, so far there seems to be insufficient experience with newer forms
    of so-called "evidence" documents that are proliferating and being
    generated by the acquisition devices (e.g. ultrasound and cardiovascular
    measurement packages), in terms of how downstream consuming devices
    are going to handle the content, whether it be recognized by SOP Class,
    template or pattern matching.

    The real test for me is whether one vendor's ultrasound machine can
    reasonably display and/or edit the measurements produced by another
    vendor's ultrasound machine. Now that's interoperability ! Though
    probably an impractical use case.

    The standard only requires "unambiguous rendering" though.

    Also, remember that the (0040,DB00) value is really only meaningful at
    the top level content item ... lower down in the content tree, whilst
    it may be present, the flexibility of inclusion rules makes it pretty
    difficult to figure out what is going on. So for example if one wants
    to detect the presence of some kind of non-trivial numeric measurement
    template, pattern matching may be a better approach. XSL-T works very
    well for this sort of thing.

    David

    PS. CIDs just refer to Context Groups aka. "value sets", which are really
    just like defined terms or enumerated values except that they contain
    lists of codes rather than simple strings.

  5. Re: TID CID etc.

    Hi David,

    I have a different perspective on a few of your points.

    Concerning the second fuzzy set that you refer: you point out
    that there are two ways to identify the template:
    - create a SOP Class that mandates a root template, or
    - use the TID attribute
    The SOP Class approach ties template specific conformance behavior
    that is detailed in the DICOM Standard. If there is no specific conformance
    behavior defined in DICOM, then I don't see any motivation that favors
    a specialized SOP Class standardization approach. Nor do I see motivation
    for an SCU to adopt (or transition to) such a SOP Class if it came to be.
    (An implementation may have template specific behavior. If so, a good
    DICOM Conformance Statement states such behavior. Note that this
    behavior may be totally unrelated to display or rendering. Important clinical
    use cases include echocardiography reporting software that rely on
    semantic comprehension of Supplement 72 "evidence" documents to
    generate reports. Exchange between acquisition devices, though useful,
    is not of high importance.)

    One of your comments about the TID benefit being restricted to the root
    content item may be somewhat misleading: For example, there is value to
    alert the parser of the presence of a private extension template. And, to enable
    other applications to use such extensions by describing them in the product
    DICOM Conformance Statement.

    Finally, as you say, DICOM evidence document experience is early.
    The first ultrasound SCU's are barely two years old.
    However, the clinical is need is at least two decades old!
    (older than the first proprietary communication protocols that DICOM SR
    evidence documents are displacing)

    - Doug


    Pattern matching implies a
    "David Clunie" wrote in message news:422D7F2D.4020603@dclunie.com...

    > There are two schools of thought with respect to what a receiver of
    > a DICOM SR should be able to do:
    >
    > 1. examine the structure of whatever is encoded and match it to known
    > patterns to determine a rendering or extraction of the relevant data
    >
    > 2. key off a "template ID" that is encoded in the object and then
    > extract data from where it is expected to be based on that template
    >
    > Sort of an XSL-T push versus pull model issue, if you known what I
    > mean by that.
    >
    > Some amongst us believe that the only safe way to do the latter is
    > to tie the template used, at least at the root level, to a specific
    > SOP Class. This is the approach used by the Mammo and Chest CAD
    > objects for example - the SOP Class specifies the use of a particular
    > template, and this any TID encoded in the instance is irrelevant.
    >
    > Other applications are "less demanding" in terms of the interoperability
    > requirements, ostensibly, and hence use generic SR SOP classes which
    > can encoded any of a myriad of standard or other templates; this places
    > the burden on the receiver to behave reasonably when it gets content
    > that it doesn't recognize, either because it doesn't recognize the TID
    > encoded in (0040,DB00) at the root content item, or because the object
    > just doesn't match any recognized template.
    >
    > One of the advantages of the pattern matching approach that I have
    > always encouraged, is that one can recognize similar patterns even
    > if the SR object was created without a particular template use in
    > mind; this may be naive in the general case, but actually works
    > surprisingly well for simple documents because de novo attempts
    > to use SR to do simple things tend to reinvent the same or very
    > similar constructs.
    >
    > There is obviously a tradeoff here between generality to allow rapid
    > adaptation to new applications, and meeting user's interoperability
    > expectations.
    >
    > Personally I believe that there is way too much unnecessary "fear of
    > SOP Class proliferation", that if one can be bothered to define a
    > standard template then one should bother to add a UID for a corresponding
    > SOP Class, and that encoding "template ID" in band as well would be
    > completely redundant. Indeed, we added the SOP Class inheritance
    > mechanism specifically for this use case to allow older devices to
    > recognize new SOP Classes of this type easily (see Sup 90).
    >
    > However, through laziness, inertia or distraction, we don't seem to
    > have gotten around to adding many of these template-specific SOP Classes
    > in many cases yet.
    >
    > Anyway, so far there seems to be insufficient experience with newer forms
    > of so-called "evidence" documents that are proliferating and being
    > generated by the acquisition devices (e.g. ultrasound and cardiovascular
    > measurement packages), in terms of how downstream consuming devices
    > are going to handle the content, whether it be recognized by SOP Class,
    > template or pattern matching.
    >
    > The real test for me is whether one vendor's ultrasound machine can
    > reasonably display and/or edit the measurements produced by another
    > vendor's ultrasound machine. Now that's interoperability ! Though
    > probably an impractical use case.
    >
    > The standard only requires "unambiguous rendering" though.
    >
    > Also, remember that the (0040,DB00) value is really only meaningful at
    > the top level content item ... lower down in the content tree, whilst
    > it may be present, the flexibility of inclusion rules makes it pretty
    > difficult to figure out what is going on. So for example if one wants
    > to detect the presence of some kind of non-trivial numeric measurement
    > template, pattern matching may be a better approach. XSL-T works very
    > well for this sort of thing.
    >
    > David
    >
    > PS. CIDs just refer to Context Groups aka. "value sets", which are really
    > just like defined terms or enumerated values except that they contain
    > lists of codes rather than simple strings.




  6. Re: TID CID etc.


    David Clunie wrote:
    > Hi Kelly
    > > kellyatdentrix@gmail.com wrote:
    > > Tag (0040,DB00) the "Template Identifier"
    > >
    > > The standard is interestingly silent on the purpose of this tag...

    or
    > > if it has anything to do with TIDs.

    >
    > There are two schools of thought with respect to what a receiver of
    > a DICOM SR should be able to do:
    >
    > 1. examine the structure of whatever is encoded and match it to known
    > patterns to determine a rendering or extraction of the relevant data


    Are you talking about some kind of AI matching algorithm here David? Or
    is it simpler than that.

    > (see Sup 90).


    I have seen references to these supplements, and I've actually found a
    few of them. I'm really confused as to why there isn't one place that
    you can download any of the supplements you might be interested in.
    What is the point of a standard that isn't readily available? Or maybe
    I just haven't been able to find the right place yet. To get Supplement
    92, for example, I had to log in with a user name and password to an
    obscure ftp site. What's up with that?

    -Kelly


  7. Re: TID CID etc.

    David maintains a thorough list of DICOM related documents
    See: http://www.dclunie.com/dicom-status/status.html

    The NEMA site has a more limited list:
    http://medical.nema.org/

    -Doug
    wrote in message
    news:1110472369.425646.184780@g14g2000cwa.googlegr oups.com...

    > I have seen references to these supplements, and I've actually found a
    > few of them. I'm really confused as to why there isn't one place that
    > you can download any of the supplements you might be interested in.
    > What is the point of a standard that isn't readily available? Or maybe
    > I just haven't been able to find the right place yet. To get Supplement
    > 92, for example, I had to log in with a user name and password to an
    > obscure ftp site. What's up with that?
    >
    > -Kelly
    >




+ Reply to Thread