What is Study ID (0020,0010) and how it is used? - DICOM

This is a discussion on What is Study ID (0020,0010) and how it is used? - DICOM ; I created a scheduled study in PACS. Assigned the study id (0020,0010) with a value "yyyy". The modality query PACS for a worklist and the above worklist is returned to the modality. However, the study id tag is not send ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: What is Study ID (0020,0010) and how it is used?

  1. What is Study ID (0020,0010) and how it is used?

    I created a scheduled study in PACS. Assigned the study id (0020,0010)
    with a value "yyyy".

    The modality query PACS for a worklist and the above worklist is
    returned to the modality. However, the study id tag is not send to the
    modality because it is not a return attribute for worklist.

    The modality acquired some images and randomly assigned a study id
    (0020,0010) with value "xxxx" and send the images to PACS.

    PACS received the images but does not update the study id "yyyy" with
    the study id "xxxx" in the images.

    Now the modality issues a C-FIND to PACS and PACS send the C-FIND
    response with study id "yyyy" and some study instance uid "1.2.2"

    The modality complains that the study id "yyyy" does not match the
    original study id "xxxx" in the images.

    1. So, my question, What is study id (0020,0010) and how it is used?

    2. The DICOM Standard says the study id is user generated or equipment
    generated. Given the above scenario, should PACS update the original
    study id "yyyy" with the study id "xxxx" from the modality?

    Thanks

    Wayne.


  2. Re: What is Study ID (0020,0010) and how it is used?

    The Study ID belongs to the modality. It is an id the equipment
    generates to identify the study for future reference. In some ways it
    can be considered obsolete. Where you see it most is on CT and MR
    modality consoles. The modality generates the study ID and uses it in a
    cross reference database for studies - typically keeping track of
    which optical disk, CD, DVD the study was written on. Historically, it
    got into Q/R model so the PACS would pick it up, but it hasn't been
    included into any of the cross system integration frameworks like MWL &
    PPS, IHE, etc because it really just traces back to a relatively
    isolated database (the mod console database). Generally the PACS
    shouldn't update the Study ID under the priniciple that what is
    generated in the modality, stays in the record as is - ie. you
    wouldn't update the date time stamps that the modality inserted into
    the image when it was put into the PACS.


  3. Re: What is Study ID (0020,0010) and how it is used?

    Wayne enyaw_2010@hotmail.com wrote:

    > I created a scheduled study in PACS. Assigned the study id (0020,0010)
    > with a value "yyyy".
    >
    > The modality query PACS for a worklist and the above worklist is
    > returned to the modality. However, the study id tag is not send to the
    > modality because it is not a return attribute for worklist.
    >
    > The modality acquired some images and randomly assigned a study id
    > (0020,0010) with value "xxxx" and send the images to PACS.
    >
    > PACS received the images but does not update the study id "yyyy" with
    > the study id "xxxx" in the images.
    >
    > Now the modality issues a C-FIND to PACS and PACS send the C-FIND
    > response with study id "yyyy" and some study instance uid "1.2.2"
    >
    > The modality complains that the study id "yyyy" does not match the
    > original study id "xxxx" in the images.
    >
    > 1. So, my question, What is study id (0020,0010) and how it is used?
    >
    > 2. The DICOM Standard says the study id is user generated or equipment
    > generated. Given the above scenario, should PACS update the original
    > study id "yyyy" with the study id "xxxx" from the modality?


    The short answer to Wayne's question is that the PACS should not be
    pre-assigning a value for Study ID, but rather should always use the
    value received from the modality for Study ID, just like it should do
    for Study Date and Study Time.

    But, this is more complex in the case where instances for a study come
    from multiple modalities, hence the longer discussion below.

    eric.goodall@gmail.com wrote:

    > The Study ID belongs to the modality. It is an id the equipment
    > generates to identify the study for future reference. In some ways it
    > can be considered obsolete. Where you see it most is on CT and MR
    > modality consoles. The modality generates the study ID and uses it in a
    > cross reference database for studies - typically keeping track of
    > which optical disk, CD, DVD the study was written on. Historically, it
    > got into Q/R model so the PACS would pick it up, but it hasn't been
    > included into any of the cross system integration frameworks like MWL &
    > PPS, IHE, etc because it really just traces back to a relatively
    > isolated database (the mod console database). Generally the PACS
    > shouldn't update the Study ID under the priniciple that what is
    > generated in the modality, stays in the record as is - ie. you
    > wouldn't update the date time stamps that the modality inserted into
    > the image when it was put into the PACS.


    One should not forget the model on which DICOM is based, hence should
    not consider attributes as individual entities but rather as being
    attributes of the entity in the model, i.e. Study ID is an attribute
    of a STUDY, not something that can contain any value one wants to
    stuff in there.

    However, standalone modalities have traditionally stuffed their notion
    of an "exam number" into Study ID, and their own "exam" date and time
    into Study Date and Study Time; they have had no other choice.

    But DICOM says that the Study ID (and Study Date and Study Time) are at
    the Study level, and the Study is (unfortunately), not the province
    of the modality.

    All study level attributes are supposed to be the same for all instances
    that are part of the same study, which presents an impossible dilemma if
    different values are generated on different modalities.

    Indeed, the "correct" way to think of Study ID is as a human-readable
    shadow of Study Instance UID - i.e. all instances with the same Study
    Instance UID should have the same Study ID and vice verse, in an ideal
    world; however, we know that this is not the case in practice for
    instances coming off a modality, even (or especially) if they get their
    Study Instance UID from MWL.

    Now, since Study ID (and Study Date and Time) are (unfortunately) not
    included in the MWL query, there is no way for the modalities to know
    what to put in here. We discussed in an earlier thread the possibility
    of adding such attributes that the second and subsequent modalities
    could use; this was discussed at IHE and is thought to be impractical
    since there is a huge installed base that already doesn't do this,
    and there is always the group case (more than one SPS satisfied by
    a single PPS) to deal with. See:

    http://groups-beta.google.com/group/...7c8e3cdc6bbad7

    So, the responsibility remains at the RIS/PACS receiving the instances
    (and corresponding PPS) ... the instances one gets from the "first"
    modality have the values to use and keep in the database and present
    in the response to a subsequent study level query; this is especially
    true of Study Date and Study Time, which are supposed to be when the
    study started (as per the definition in DICOM PS 3.3).

    When instances for the same Study Instance UID start to arrive from
    another modality, them the value for Study ID in the database at
    the study level could be replaced with the "new" modality-generated
    value, but perhaps should not be; the values for Study Date and Study
    Time should only be replaced in the database if they are earlier,
    even if they arrived later (if you see what I mean).

    When instances are archived in the PACS or at the very least when they
    are retrieved from the PACS, the values in the instances should probably
    be coerced to match those in the database, otherwise the system retrieving
    the instances will have the same problem, i.e. study level attributes
    that vary between instances from the same study, as well as diverging
    from what was returned in the query. This approach ignores the issue of
    what happens if the instances are ever returned to the modality, with
    the same UIDs but different values in the study level attributes, but
    this is an uncommon use case, and has a similar consequences as when
    patient level attributes are reconciled (since from the model's
    perspective, patient attributes must be the same in all instances
    of the same study).

    If one completely ignores the problem, which is often done, then one
    of the effects on the user is that what they see in a query browser
    does not match up with what they see in the local browser or in the
    locally displayed images when the study is retrieved, depending on
    whether the remote query, local browser and local display are
    consistent in how they handle these "study" level attributes; this
    is especially true if the user is looking for a particular study by ID,
    or date and time, obviously, but especially so if one of the browsers
    splits the same study, as defined by its Study Instance UID, into
    two as far as display to the user is concerned, based on divergent
    values in Study ID, Study Date and Study Time, and the other doesn't.

    David

    PS. With respect to Wayne's original question, involving assigning a
    value to Study ID internally when a study is "scheduled"; there is no
    requirement that this been done, and indeed from a DICOM perspective
    scheduling does not occur at the "study" level, but rather at the
    requested procedure and scheduled procedure step levels; the MWL SCP does
    have to assign a value to Requested Procedure ID, and there is no reason
    a modality could not use that as Study ID, but that still allows for
    different values in the group case, and I am not sure how commonly
    modalities copy MWL Requested Procedure ID into Study ID, if ever,
    probably since DICOM PS 3.17 Annex J (the former PS 3.4 Annex M)
    goes out of its way not to suggest doing this, and IHE Rad TF Vol 2
    Annex A also ignores Study ID.

    PPS. All this ignores the question of Accession Number, which is also
    at the STUDY level of the model, but is in the worklist, and in all
    but the group case should propagate through the system consistently;
    RIS-centric folks are very big on Accession Numbers and happily
    denigrate Study ID; of course the group case screws everything up
    for Accession Number too, hence the Request Attributes sequence in
    the instances and the recent IHE proposed CP that is going to stuff
    yet more into Request Attributes to better convey the results of
    grouping.

    PPPS. Whether or not to coerce the attributes to consistent values
    for all instances of the same study (or patient) only when exporting,
    or to instead "re-archive" the instances may not seem like an important
    matter, but is crucial for two later scenarios. One is recovery from
    an off-site archive, in which the behavior should be consistent with
    what the local RIS/PACS does. The other is when a PACS is retired and
    the archive is migrated - in both case the "correct" information in
    the database may not be available to correctly coerce the instances.

+ Reply to Thread