What rules govern overwriting SOP Instance UIDs - DICOM

This is a discussion on What rules govern overwriting SOP Instance UIDs - DICOM ; Radiographers at my institution recently sent images from eFilm to GE PACS and Conquest. Unintentionally the radiographer had encrypted the patient demographics before sending. Images were then resent with patient name and id etc. as standard. PACS and conquest appear ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: What rules govern overwriting SOP Instance UIDs

  1. What rules govern overwriting SOP Instance UIDs

    Radiographers at my institution recently sent images from eFilm to GE
    PACS and Conquest. Unintentionally the radiographer had encrypted the
    patient demographics before sending. Images were then resent with
    patient name and id etc. as standard. PACS and conquest appear to
    have updated the images with the second set (which is what we want).

    Is it usual for a Storage SCP to overwrite a SOP Instance UID with
    (presumably) another image having the same SOP Instance UID?

    Thank you

  2. Re: What rules govern overwriting SOP Instance UIDs

    Hello Chris,

    the DICOM Standard explicitly states that there shall be *no* valid
    assumption on what happens with a SOP Instance received twice.

    In DICOM, a SOP Instance is one and only one distinct Object. If the
    same object is received again, it does not make any difference if it is
    replaced or rejected (what many other SCPs do). As long as the SOP
    Instance UID is the same, the object is the same, full stop.

    If you want to have something permanently changed in an Instance (that
    is known outside your box), then you have to create a new instance,
    preferably in a new Series (else it could confuse some software that
    finds two different instances representing information from exactly the
    same position etc.).

    In consequence, no changes of any clinical relevance shall be applied to
    an existing instance. The reconciliation of erroneous data is an
    exception here, but that is why this shall only be performed in the
    Image Archive itself (as of the IHE Patient Information reconciliation
    use case) and the Image Archive shall be the one and only distributing
    system for clinical imagine information.

    In a nutshell: Changes applied to an existing Instance are disposable.
    If you want them to be persistent, you will have to create a clone.

    Said that, one may understand why there are "Softcopy Presentation
    States" in DICOM: If you only change something like the Center/Window or
    add a graphical annotation, it is more economic to store that in a
    Presentation state referring to the original pixel data image.

    The behavior you experienced matches your use case, so you are lucky.
    But do never rely on this with any other vendor or system!

    Just my EUR 0.02 ;o) - hope this helps.


    Regards,


    Peter

    chris_taylor5000@yahoo.co.uk schrieb:
    > Radiographers at my institution recently sent images from eFilm to GE
    > PACS and Conquest. Unintentionally the radiographer had encrypted the
    > patient demographics before sending. Images were then resent with
    > patient name and id etc. as standard. PACS and conquest appear to
    > have updated the images with the second set (which is what we want).
    >
    > Is it usual for a Storage SCP to overwrite a SOP Instance UID with
    > (presumably) another image having the same SOP Instance UID?
    >
    > Thank you


  3. Re: What rules govern overwriting SOP Instance UIDs

    So do you suggest that GE PACS and CONQUEST overwrite images if
    another arrives with the same SOP Instance UID?

+ Reply to Thread