Are duplicate UIDs flagged as conflicts?

[akluiber]

If I import a session whose images (and thus UIDs) are the same as another existing session in the project (under different subject/session IDs), should that new session be flagged as a conflict in the pre-archive?

For some reason I thought this was how it worked, but as I'm testing out scenarios with DQR, dicom receivers, and the compressed uploader, that doesn't seem to be the case.

I'll often receive lists of subjects/exams from a study coordinator, and I am tasked with pulling, and archiving the images for them. I've run into a couple instances where human error has resulted in the same patient exam being archived under multiple different subjects/sessions by accident.

Thanks.

- Alex

[Charlie Moore]

Hi Alex,

Session labels are required to be unique in a project, but XNAT makes no such requirements about UIDs. There's a couple reasons I can think of for that:

1. Some historical workflows required "splitting" a study into 2 XNAT sessions, each with the same Study Instance UID.

2. If a study is archived with missing data, project owners often rename it to something like "101_BAD" to have a backup of the data while they attempt to reimport it. The idea is once the data is all properly received, they'll delete the "BAD" version.

Thanks,

Charlie Moore

[Rick Herrick]

In development we'll routinely send the same session to XNAT again and again. The study instance UID is stored with image sessions as the uid property, but there's no uniqueness constraint on that column.

You will get a session conflict when sending data to XNAT when that data matches an existing session (i.e. same project and session label) with a different study instance UID. But no issues with replicating them across sessions.

--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/992b3859-e038-4e5b-b04f-7c449974d535n%40googlegroups.com.

[akluiber]

Understood, and it makes sense. However, if I desired to ensure that UIDs were in fact unique project-wide during import, any suggestions on the best way to accomplish this? I was thinking either an event service to flag the archived session somehow, or maybe a Custom Import Processor make more sense?

[Kate Alpert]

It depends a bit on what you want to happen to the "duplicate" (per UID) sessions and how you upload to XNAT. If you want to just ignore duplicates (or send an email or something), and you exclusively upload to an XNAT SCP receiver (or via REST and you can set Custom-Processing=true as a query param), then using a Custom Import Processor "AfterProjectSet" should work really nicely. If you want the duplicates stored within XNAT for download/review/reupload, and you want to support any means of data upload (compressed uploader, XNAT Desktop Client, etc), then performing an event-service triggered validation post-archive would make more sense.

Best,

Kate

[Guus Kolpa]

On a note related to this question:

I've recently uploaded DICOMs from the same study with different SeriesUID, but the same SeriesNumber. They come out as '101-MR1', '101-MR'2, etc.

I've noticed that the scan with the 'earlier' (as string) SeriesUID has the -MR1:

104-MR1
2.25.203192574062651230130199065447959661432

104-MR2
2.25.278111159036974730534955735575753976121

450-MR1
2.25.182854373632389687258215751006694271474

450-MR2
2.25.4447262028262868263205759029401578027

451-MR1
2.25.270618894473012108851615032663077185547

451-MR2
2.25.98152183116881899939331757207128379338

Can you confirm that this behaviour is consistent?:

'If two scans have the same series number, they are sorted by SeriesUID (as strings), and are given -MRX suffixes in that order'

I've looked at the Java code but I'm not fully confident in that.

Hope to hear from you soon! 

Kind regards,

Guus