Is StydyInstanceUID replacable? - DICOM

This is a discussion on Is StydyInstanceUID replacable? - DICOM ; I have a question about studyinstanceuid (0020,000d). Is this wholy. or can any system replace this with a uniqe number? I dont talk about series or "image"instanceUID. A vendor say that serie and image instance uid is wholy but study ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Is StydyInstanceUID replacable?

  1. Is StydyInstanceUID replacable?

    I have a question about studyinstanceuid (0020,000d).
    Is this wholy. or can any system replace this with a uniqe number? I
    dont talk about series or "image"instanceUID.

    A vendor say that serie and image instance uid is wholy but study
    instance uid is
    replaceable with another uniqe instanceUID.
    Is this true? and where in the standard is the proof.

    thanks a bilion!


  2. Re: Is StydyInstanceUID replacable?

    DICOM uses the term "Coercing" when an application receiving an IOD
    from another changes the values of elements in the IOD. Section B.4.1
    in DICOM Part 4 discusses this and identifies three elements which are
    allowed by the standard to be coerced: Patient ID, Study UID, and
    Series UID.
    In other sections of Part 4, the standard requires "warning" level
    status codes to be returned by the receiving application when it does
    (or might) coerce elements. This is rarely done, because to do so is
    make your application one which other applications will show has having
    "failed" when they transfer IODs. Most modalities and DICOM interface
    libraries consider a DICOM transfer result to be binary. Either it got
    a status of successful or, any other status, whether informational,
    warning, or error , is assumed to be a failure.
    Also - attributes which are coerced or changed to make workflow "work"
    often include attributes other than the three identitified in Section
    B.4.1. As an example, the IHE Patient Reconciliation profile includes
    provisions for applications to change all the patient identity module
    elements.
    Voice of experience will also tell you, IF YOU CHANGE THE STUDY UID OR
    SERIES UID, CHANGE THE INSTANCE UID TOO!
    If you don't you're asking for data integrity headaches due to
    different copies of the images with the same Instance UID but different
    Series and Study UIDs all your live long days.


  3. Re: Is StydyInstanceUID replacable?

    I think the question needs to be asked why do you wish to change the
    Study UID?

    Unless you are creating a new study from an existing study, I'd suggest
    leaving the Study UID as it was. Other systems may depend on the Study
    UID value for retrieving the data. Same goes for the Series UID.

    TJ


  4. Re: Is StydyInstanceUID replacable?

    The idea of when you might want to change the Study UID is based on an
    old concept that lives on despite newer workflow frameworks that seek
    to repudiate it through a variety of "out of object" associations. That
    is, the idea that images which are associated through having the same
    Study Instance UID form a unit of work that can be routed around to
    different, independent workstations, and can be requested via a single
    Q/R request.

    It also lives on in most DICOM viewing software in that, Study UID is
    basic organization index that most viewers will use when they determine
    which images are brought into a viewing context. So, why change the
    Study UID? Well, when you have images from multiple modalities that you
    want to display together when they're read, you often want/need to
    change the Study UIDs in the images of one modality so they will have
    the same value as the Study UID in the images from the other modality.

    When I was doing integrations in hospitals, the most common instance of
    this was the need to combine CR images and RadFluoro images/cines in a
    single study.But there were others. One hospital routinely did a post
    surgical CR which was combined with pre-surgical MR images.

    The section allowing "coercing" is in a part of the standard which
    pre-dates modality worklist and this is clearly what the authors had in
    mind when they allowed those tags to be changed. Modality worklist has
    reduced but has not entirely eliminated the need to change UIDs in some
    images by making a common UID available on the network for different
    modalities to use when they create the images. But there are still
    quite a number of non-MWL modalities out there and even when the
    modalities support MWL, the requested procedures/schedule steps and
    UIDs on the modality worklist don't always conform to the way the
    doctors in the hospital want the images organized for display.

    Most PACS systems now allow the images from multiple studies to be
    combined in a single viewing context based on rules matching the
    different study images together --ie. they use those "out of object"
    associations I referred to earlier. Others would have the display
    workstations using a descriptor provided by a GPWL interface (a
    standards based version of what PACS systems do in a proprietary
    fashion internally). But as PACS is deployed into smaller instititions,
    in a lot of cases "the PACS" is may be a single, stand alone DICOM
    workstation where Study UID "means" unit of reading; and maybe another
    technician's workstation with a "merge" function to modify UIDs.

    In this environment, when the boss says he doesn't want to have to
    close one study and open another to read a single exam, you look for
    ways to make it happen. Changing the Study UID makes it happen, but at
    a potential cost of data integrity issues -- ie. some images stored
    into the system "disappear" because the PACS sees they've already got
    the same image UID with a different parent Series UID or different
    parent Study UID and reject the object. So, my advice still stands - if
    you're going to change the Study UID in the images (and there are times
    when you need to do this), change all of the UIDs. In some cases you
    may end up getting the same image stored twice with different
    identifiers, but that is preferable to having images "disappear" on the
    way to the bosses workstation or even worse, after the boss has read
    them and they are stored into the archive.


+ Reply to Thread