About DICOM Images in Series in Studies in Patients

[Juan Bravo]

Hello all.

I know that two different images can't share the same SOPInstanceUID.
The SOPInstanceUID attribute is unique world-wide..

But what about the SeriesInstanceUID?
Is that also unique world-wide or just unique inside it's root StudyInstanceUID?

Take a look at this example,

Code: Select all

Patient001
{
   Study001
   {
      Series001
      {
         Image001
         Image002
         Image003
      }
      Series002
      {
         Image004
      }
   }
   Study002
   {
      Series003
      {
         Image005
      }
   }
}


Patient002
{
   Study003
   {
      Series001
      {
         Image006
         Image007
         Image008
      }
   }
}

There are two series with the SeriesInstanceUID="Series001" in the same system..
Is that allowed by DICOM if they are in different Studies? Or should the STORAGE-SCP
rename any incomming SeriesInstanceUID if it already exists in the system
in a different study?

Thanks in advance!

[Marco Eichelberg]

All UIDs are world-wide unique identifiers by definition. A Series Instance UID is a worldwide unique identifier for a DICOM series. Since each series "lives" in exactly one study, two series in two different studies can never legally use the same Series Instance UID. A storage SCP should normally not do any "renaming" - unless you really know what you are doing, there is a risk of assigning images to the wrong patient, which might cause you major legal headaches.

[Juan Bravo]

So, what should a storage SCP do instead?
Send a C-STORE-RSP with a failure status?

I've no experience in real-hospital-environment, but our aim is creating a storage server
that would be able to recieve images from A LOT of entities.. so maybe any coincidence
between SOPInstanceUIDs, SeriesInstanceUIDs or StudyInstanceUIDs may occur, but I'm
not sure about that.

[Marco Eichelberg]

So, what should a storage SCP do instead?

That is actually implementation defined behaviour. Refusing the images with a C-STORE-RSP failure is a perfectly valid approach, although it might cause problems to people who have to use non-compliant systems that create such invalid objects in the first place. Accepting the images might be another option, if you can handle the duplicate Series Instance UIDs, which should be possible with the traditional query model, but would be a problem with relational Q/R.