[Insight-users] SOP instance ID conflict

Thu May 26 19:13:25 EDT 2011

Thanks so much, guys, for all the information and for providing a sanity check on
the images.  That was so much more help than I've been able to get from our IT 
team.  I'm going to sit down with them at the terminal tomorrow with one of them 
and this will definitely help as we work through the transfer problems tomorrow.

Thanks again,
Nick

On May 26, 2011, at 6:04 PM, Ryan, William J. wrote:

> Nick-
> 
> I took a quick look and the UID's look valid.  They are all unique
> within this series and are of a valid format (64 chars is the max
> length).  You don't have to worry about the prefix, per se, as long as
> these are unique.  Off the top of my head I don't know how GDCM
> generates new UID's, but you should be able to find a call to generate a
> unique ID.  If nothing else, for testing you could use GDCM to anonymize
> the images and copy the Study/Series/SOP/Frame of Reference UID's out of
> the anonymized files.  (I know it's painful, but that would be a way to
> guarantee uniqueness).
> 
> It's also a possibility that one of your UID's (Study/Series/SOP) has
> been sent for another patient.   If the study uid was copied from a
> different set of images that belonged to another patient, a PACS system
> would typically reject the new images.
> 
> Again, if you can generate new UID's with a tool, you should be able to
> get these to go.  Of course, please make sure to use the same Study UID,
> Series UID and Frame of Reference UID across all the images for the
> series, and then each image needs a unique SOP Instance UID.
> 
> Hope this helps!
> 
> 	Bill 
> 
> -----Original Message-----
> From: Nicholas Tustison [mailto:ntustison at gmail.com] 
> Sent: Thursday, May 26, 2011 3:18 PM
> To: Blezek, Daniel J.
> Cc: insight-users users; Ryan, William J.
> Subject: Re: [Insight-users] SOP instance ID conflict
> 
> Thanks Dan, for your response.
> 
> Yeah, my first guess was that the numbers I'm generating for each slice
> in
> the volume were not actually random.  But I've done it a few times
> specifically
> to make sure that it appears random.  I also thought (not knowing
> anything 
> about DICOM) that maybe I needed to specify a specific prefix but the IT
> people didn't know anything about that.  So I've tried with and without 
> prefices where I've copied the prefices from the input dicom files and 
> I've tried with the default gdcm prefix as you mention but each time
> there's
> a SOP instance ID conflict.  
> 
> Thanks for being willing to look at the images.  Because there's patient
> information, I'll send you a link and a password in a private email.
> 
> Thanks again,
> Nick  
> 
> 
> 
> 
> 
> On May 26, 2011, at 3:49 PM, Daniel Blezek wrote:
> 
>> Hi Nick,
>> 
>> While your UID might look random, if the PACS already has an image
> with
>> that same ID, your C-STORE will be rejected.  Can you re-run your
> processing
>> and verify that a new UID is generated?  dcmdump is very helpful here.
>> 
>> I assume you used GDCM.  This has a unique prefix and so should not
>> generate collisions.
>> 
>> Could you post an image or upload one somewhere?  Sometimes PACS
> errors
>> are not specific enough to understand why an image was rejected.
>> 
>> Best,
>> -dan
>> 
>> 
>> On 5/26/11 6:37 AM, "Nicholas Tustison" <ntustison at gmail.com> wrote:
>> 
>>> Hi,
>>> 
>>> I have an issue where I'm trying to push some processed images back
>>> to PACS at my institution using storescu.  I get no error message
> using
>>> storescu but I can't find them in the database and they appear lost.
>>> The IT people tell me that there is a conflict with the SOP instance
> ID
>>> that is generated for each slice and that images exist already with
>>> those same IDs.  However, I can look at the header and clearly see
> that
>>> it is a randomly generated number.
>>> 
>>> I was hoping to provide my IT people with additional information as I
> don't
>>> think they have much experience with people at the institution
> wanting to
>>> do this type of thing.  I was thinking that perhaps the conflict
> message might
>>> be indicative of an incorrect prefix but that's just a wild guess.
> Has
>>> anybody
>>> else encountered a similar problem?
>>> 
>>> Thanks,
>>> Nick 
>>> _____________________________________
>>> Powered by www.kitware.com
>>> 
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>> 
>>> Kitware offers ITK Training Courses, for more information visit:
>>> http://www.kitware.com/products/protraining.html
>>> 
>>> Please keep messages on-topic and check the ITK FAQ at:
>>> http://www.itk.org/Wiki/ITK_FAQ
>>> 
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.itk.org/mailman/listinfo/insight-users
>> 
>> -- 
>> Daniel Blezek, PhD
>> Medical Imaging Informatics Innovation Center
>> 
>> P 127 or (77) 8 8886
>> T 507 538 8886
>> E blezek.daniel at mayo.edu
>> 
>> Mayo Clinic
>> 200 First St. S.W.
>> Harwick SL-44
>> Rochester, MN 55905
>> mayoclinic.org
>> "It is more complicated than you think." -- RFC 1925
>> 
> 