Unique ID? - DICOM

This is a discussion on Unique ID? - DICOM ; Hi All! Must a Study-UID really unique in a PACS Archive? We have double UIDs in our PACS and problems... Cheers...

+ Reply to Thread
Results 1 to 14 of 14

Thread: Unique ID?

  1. Unique ID?

    Hi All!

    Must a Study-UID really unique in a PACS Archive?

    We have double UIDs in our PACS and problems...

    Cheers



  2. Re: Unique ID?

    Jens Reinholz wrote:

    > Must a Study-UID really unique in a PACS Archive?
    >
    > We have double UIDs in our PACS and problems...


    Yes. There is absolutely no question about this.

    If duplicate UIDs result in a problem, then the vendor of the
    equipment that is responsible for erroneously creating the
    duplicate UIDs should be responsible for the cost of rectifying
    the problem.

    David

  3. Re: Unique ID?


    In addition to what David wrote: any UID is furthermore supposed to be
    __globally__ unique!! So your study instance UID is not only supposed to
    be unique within this one PACS, it is also supposed to NOT appear in ANY
    OTHER PACS installation of the same vendor. Make sure your vendor knows
    about this fact, otherwise he will run into trouble again later.

    Regards,
    Thomas Wilkens
    OFFIS


  4. Re: Unique ID?

    I think this is a common problem. There will always be situations, in
    which duplicate "unique" ids exists and it costs a lot of timely afford
    in PACS systems to try to prevent the incoming of such violating
    studies.
    Therefore I suggest that the DICOM standard should be adapted to the
    world we have out there...


  5. Re: Unique ID?

    coladrops wrote:
    > I think this is a common problem. There will always be situations, in
    > which duplicate "unique" ids exists and it costs a lot of timely afford
    > in PACS systems to try to prevent the incoming of such violating
    > studies.


    The OSI system for assigning the unique ids is hierarchical and works by
    delegating authorization. I don't see why it is difficult to guarantee
    unique ids; the whole system seems designed to ensure just that (and to
    help identify who is responsible when the UIs aren't unique).

    The OSI UI assignment is IMO not that different to the way in which IP
    addresses are assigned. Yes, every once in a while, people will mess up
    and two machines will have the same IP address (at the same time). That
    is so comparatively rare though that we "rely" on it not happening.

    > Therefore I suggest that the DICOM standard should be adapted to the
    > world we have out there...


    and do what? If you cannot assume that two sets of data about a study
    with UI 1.2.3.4 are about the same study, then either you need to add in
    some additional matching information e.g. ask someone/something if they
    are the same (but then how can you guarantee you get the right answer),
    or you have to abandon the concept of matching based on UIs. Any
    queries would yield useless results e.g. these images may or may not be
    part of the same study. You couldn't even ask for the same data back as
    there could be two datasets with the same UI.

    Alan

  6. Re: Unique ID?

    coladrops wrote:

    > I think this is a common problem. There will always be situations, in
    > which duplicate "unique" ids exists and it costs a lot of timely afford
    > in PACS systems to try to prevent the incoming of such violating
    > studies.


    In an integrated system, in which various objects and states are
    linked by there UIDs (be it image references, PPS references or
    study references), it is important to be able to rely on the
    uniqueness of UIDs.

    As enterprises integrate it becomes even more important that the UIDs
    be globally unique, as intended.

    Whilst it is desirable that a central system (such as a PACS) checks
    UIDs to see that there is no mismatch of other attributes of the
    same entity that already exist, this not only generates a problem
    of what to do when they do not match (set aside for operator intervention
    often disrupts the smooth running of the department), but also becomes
    very expensive in terms of resources and time if performed all the
    way down to the image level (e.g. checking that the pixel data of
    two images with ostensibly the same UID are actually the same).

    > Therefore I suggest that the DICOM standard should be adapted to the
    > world we have out there...


    Rubbish.

    I suggest that customers stop buying poor quality products that are
    not compliant with the standard.

    David

  7. Re: Unique ID?

    David,
    I would be more than happy, if the real world would be as perfect as
    you desire it to be. Unfortunately we have to deal with a lot of
    systems and situations which violate the uniqueness of UIDs. So only
    complaining about it and just saying "rubbish" isn't really helpful. In
    my opinion we have to accept this problem and try to develop solutions
    which work for everyone, maybe in form of a best practise guide how to
    deal with non unique UIDs or how to ensure uniqueness. Please keep also
    in mind, that the UIDs are some very PACS (DICOM) specific stuff which
    is not really accepted and maintained by HIS/RIS systems.

    Alan,
    just think about this: the non uniqueness of UIDs can be introduced by
    a system, which is not responsible for the generation of the UID.


  8. Re: Unique ID?

    coladrops wrote:
    > ...Therefore I suggest that the DICOM standard should be adapted to the
    > world we have out there...


    Then why have a standard at all?

    Tim


  9. Re: Unique ID?

    coladrops wrote:
    [snip]

    > Alan,
    > just think about this: the non uniqueness of UIDs can be introduced by
    > a system, which is not responsible for the generation of the UID.


    Can you give an example of how that can arise?

    Alan


  10. Re: Unique ID?

    Allan, just some examples which come to my mind are:
    A system sending images to a 3rd party and "correcting" or anonymising
    patient demographics data. A system reassining series. A system merging
    patients and afterwards receiving the original study with now different
    patient demographics again. A user choosing the wrong modality worklist
    entry, e.g. if the patient gets a list of studies today and only one of
    the entries is choosen by the "lazy" user.
    In Davids words this might arise from "poor quality software" anyway,
    things like that happen.


  11. Re: Unique ID?


    SomeHuman schrieb:
    > Then why have a standard at all?
    >
    > Tim


    A standard like DICOM is a very complex documentation. Its not
    surprising, that not everyone is implementing the standard perfectly.
    Otherwise initiatives like IHE wouldn't exist. I personally support
    DICOM, but anyway we should be open enough to accept existing problems
    and not flame anyone who is questioning elements of the standard.


  12. Re: Unique ID?

    coladrops wrote:

    > David,
    > I would be more than happy, if the real world would be as perfect as
    > you desire it to be. Unfortunately we have to deal with a lot of
    > systems and situations which violate the uniqueness of UIDs. So only
    > complaining about it and just saying "rubbish" isn't really helpful. In
    > my opinion we have to accept this problem and try to develop solutions
    > which work for everyone, maybe in form of a best practise guide how to
    > deal with non unique UIDs or how to ensure uniqueness.


    I didn't mean to imply that high quality receiving systems should not
    anticipate and deal with bad stuff that comes from poor quality
    implementations. A desirable source of added value perhaps, but not
    something that the standard can legislate.

    Only that the DICOM Standard is not going to be adapted to accommodate
    the needs of poor quality systems by saying that unique identifiers do
    not have to be unique, as you had suggested. That is what I was
    referring to as rubbish, and I repeat it. Rubbish.

    If we weakened the standard requirements every time some incompetent
    bozo released a mistake into the field we soon wouldn't have a standard
    at all.

    The standard does not define an architecture for dealing with failure
    to comply with the interchange requirements of the standard.

    The best practice guide for how to deal with non-uniqueness is to sue
    the crap out of the vendor at fault, and/or not buy their equipment in
    the first place.

    After a few iterations we might then converge on perfection.

    An RFP that requires DICOM conformance by my interpretation requires
    global uniqueness of any generated UIDs, so this is a simple matter
    of contractual violation with potentially expensive consequences.

    > Please keep also
    > in mind, that the UIDs are some very PACS (DICOM) specific stuff which
    > is not really accepted and maintained by HIS/RIS systems.


    Indeed, and if the RIS and HIS don't keep track of UIDs (especially
    study instance UIDs) then the PACS (or at least the MWL SCP) needs
    to keep track of the correlation between Study Instance UID and
    Accession Number or whatever the HIS/RIS system uses.

    > just think about this: the non uniqueness of UIDs can be introduced by
    > a system, which is not responsible for the generation of the UID.


    Any system that changes a DICOM instance in any way (such as the
    anonymizers you mention) needs to take care of the UID issue, or
    should be deployed in such a manner that you can be sure that
    no duplicate instances appear in connected systems that have
    different attributes for the same UID. Same goes for QC systems
    that repair incorrect patient names, etc.

    Ensuring that edits and UIDs are handled correctly in an integrated
    system of heterogeneous components is non-trivial (see for example
    the PIR profile in IHE for one attempt at this).

    PACS administrators should view the introduction of tools that
    are not tested in this regard with extreme concern (e.g. if a
    user wants to save a screen shot to the PACS from some DICOM
    viewer they downloaded from the web and which they can use
    to query and retrieve images, if the saved screen shot does
    not contain UIDs constructed in the appropriate manner, then
    problems with referential integrity inside the PACS may arise).

    Ideally you would not connect ANYTHING to your PACS that allows
    introduction of instances into the database without testing it.
    Easier said than done though.

    But none of this avoids the fundamental concern of the original
    poster that modalities should never generate duplicate Study
    Instance UIDs.

    No excuses are acceptable in this regard.

    I re-iterate that modality vendors that make this mistake should
    be responsible for the cost of dealing with the consequences
    that arise, for example, during migration to a new PACS that
    cares more about uniqueness than the old PACS (those who have
    encountered this situation can tell you about the cost incurred).

    As far as I am aware, most serious modality vendors are extremely
    diligent about this right because they appreciate the severe
    consequences of getting it wrong.

    Be VERY wary of software upgrades to your modalities - there have
    been instances when certain modalities reset a counter on such an
    upgrade and begin reissuing UIDs that have already been used.

    Not generally a problem at the Study Instance UID level if MWL
    is in use, since the supplied UID should be used, but a problem
    at the Series and Instance level.

    David

  13. Re: Unique ID?

    coladrops wrote:

    > SomeHuman schrieb:
    >
    >>Then why have a standard at all?
    >>
    >>Tim


    Quite.

    > A standard like DICOM is a very complex documentation. Its not
    > surprising, that not everyone is implementing the standard perfectly.
    > Otherwise initiatives like IHE wouldn't exist. I personally support
    > DICOM, but anyway we should be open enough to accept existing problems
    > and not flame anyone who is questioning elements of the standard.


    And making medical devices is a serious business, which means that
    implementers should be capable of handling the complexity, and should
    be responsible for the consequences of their actions, or they should
    not be involved.

    IHE exists to deal that fact that DICOM and HL7 do not define an
    architecture. IHE deals with issues of integration at a higher
    level than either DICOM or HL7 by making certain assumptions about
    the workflow in those organizations.

    In the context of this discussion, IHE is totally dependent on UIDs
    being unique as intended, and makes no allowances to the contrary,
    as far as I am aware (it is totally predicated on Scheduled Workflow
    working).

    David

    PS. Of course, anyone who questions elements of the standard should be
    shot, so you are getting off lightly this time

  14. Re: Unique ID?

    coladrops wrote:
    > A standard like DICOM is a very complex documentation. Its not
    > surprising, that not everyone is implementing the standard perfectly....


    While it is true that the standard is complex, the part about the
    uniqueness of UID's is pretty clear...

    >From Part 5 of the 2004 DICOM standard:


    "Section 9 Unique Identifiers (UIDs)
    Unique Identifiers (UIDs) provide the capability to uniquely identify a
    wide variety of items. They guarantee uniqueness across multiple
    countries, sites, vendors and equipment. Different classes of objects,
    instance of objects and information entities can be distinguished from
    one another across the DICOM universe of discourse irrespective of any
    semantic context.

    Note: For example the same UID value cannot be used to identify both a
    study instance (Study Instance UID) and a series instance (Series
    Instance UID) within that study or a different study. Implementers also
    need to be cautioned against building new UID values by derivation (for
    example by adding a suffix) from a UID assigned by another
    implementation."

    Seems pretty clear from this paragraph that the Study Instance UID
    should uniquely identify ONE and only ONE study in the universe
    (excepting other universes of course).

    Tim


+ Reply to Thread