Hi Chidi and Sandro,
Apologies if I sound opinionated below, but I think that there are some serious issues raised here.
To be honest, the whole scenario here seems like an accident waiting to happen. Mucking around with DICOM UIDs is not a good idea generally and vastly increases the complexity of auditing studies. Golden rule: one XNAT session = one DICOM StudyInstanceUID. XNAT's prearchive rightly flags up issues when this is not the case if one imports data into XNAT via the DICOM receiver. Just because the images are created "within" XNAT via a container and placed directly in the archive, doesn't mean we should be treating them differently. Whenever we have locally attempted to violate this and merge more than one StudyInstanceUID into a single session, it has not ended well.
There are two solutions here:
1. I think that the cleanest all round is to have the defacing container create a completely new XNAT session for the same subject. Just name the new session something like <ORIGINAL_SESSION_NAME>_defaced. I can't remember whether adding a session via the container services will automatically trigger a call to the JSON generation for the viewer, but if it doesn't then you may need to use the REST API call I pointed to above.
Once you have it in a different session, the viewer will handle everything just fine. You can display all imaging sessions for a patient. The sidebar will give you expander boxes for each session and you can drag the images you want next to each other in the viewer. Job done.
This has the added advantage that you can share the newly created session with another project where only the defaced images are seen.
2. Have the defacing container create additional defaced images and add them to the original session, but with the same StudyInstanceUID and completely new SOPInstanceUIDs. This leaves the original images intact, which is what you need for auditing purposes. In this scenario, you will definitely need to make a call, as above, to regenerate the session JSON for the viewer. This situation is very close to what happens when an MR scanner performs a "retrospective recon" and sends a set of reconstructed images to XNAT, which may arrive later than the originals, meaning that the original session has already been finalised in XNAT before they reach the prearchive.
In your case, you might need to think carefully about what date you insert into the DICOM files for the defaced images. Personally, I'm not a massive fan of having an XNAT session containing DICOM files with two different dates, but I don't worry about this quite as much as having different SeriesInstanceUIDs.
Best wishes,
Simon