Expected behavior: I have a DICOM RT database: each folder is the RT image set of a specific patient, that is, 1 CT, 1 RTSTRUCT, 1-n RTDOSE, 0-n RTPLAN. Each DICOM series is in its specific subfolder. I open patients one by one using “Load DICOM data > Import > Load”.
When I load a new patient, I expect to visualise it in the Slicer viewers. If necessary, I delete the old patient from the data tree (“Subject Hierarchy”). I precise that I use Slicer only for visualisation, I modify no data, I write nothing.
Actual behavior: However, some patients are loaded as other patients. E.g., I load Patient187, I visualize what I need to visualise, then when I load Patient188 different buggy behaviors happen:
sometimes the patient just does not load (it says “0 new series” etc.), everything behaves as if Patient188 was Patient187 (at the image and metadata level)
sometimes, if I remove Patient187 from the database before loading Patient188, then Patient188’s metadata are loaded correctly but its images are actually those of Patient187
sometimes, Patient187 is not even the real Patient187 when I compare its images to what I get from other DICOM viewing softwares or from other Slicer installations on other computers
These bugs are very worrying. My intern is using Slicer to make quality control and I am afraid that many patients were badly reviewed because the loaded images were actually not those of the corresponding patient.
All that you describe indicate that the data sets have inconsistent/missing UIDs. Did you modify the images in any way after you retrieved it from the treatment planning system? Have you anonymized the images? If yes, what software did you use for that?
Also make sure that you use latest Slicer Preview Release. We have made lots of improvements in DICOM support in recent years.
I agree with Andras, most likely explanation is that the data is incorrect somehow. That said, if you ever see issues like this please share data that can be used to recreate and debug the issue. We take these matters very seriously, so perhaps you can inspect the error logs for anomalies that should be flagged as warning dialogs.
Indeed the data were modified after retrieval. They were anonymized when transferred from the healthcare center to the data curator for storage on external servers. I will check the UIDs and the anonymisation process with the curator.
I was afraid that Slicer Preview Release might be too unstable to be used but I will try on your advice.
I thought about sharing data but I’m not sure about my rights to do so, even if the data were anonymized.
That sounds like a good plan. For sure don’t share anything unless you are sure it’s okay. If you are still running into issues see if you can recreate the issue with a scan of a phantom.
I have checked the UIDs of the images causing these buggy behaviors (SOP Class, SOP Instance, Study Instance, Series Instance, Frame of Reference): none are the same for the buggy images that I have detected.
I reviewed the anonymization process with the data curator: only the SOP Instance UIDs are modified and the assignement process ensures no duplicates.
After deletion of Documents/SlicerDICOMDatabase and reinstallation of Slicer Stable Release 4.10.2, my intern wasn’t able to reproduce the bug on some patients but it seems to remain on a few others.
All of this makes me think that the initial problem is due to Slicer. I stay confused by point 3.
For your record: when trying Slicer Preview Release 4.11.0 on macOS 10.14.6, my intern says the software bugs on start and that she doesn’t succeed in installing the SlicerRT extension. I don’t have enough time to dig into this problem though.
If you have data sets to reproduce the problem then it is great, it means that the problem can be easily fixed. If the problem is indeed due to a Slicer bug, then most likely it is already fixed in Slicer-4.11, so it would be great if you could switch to that and ask your intern to report here any problems.
I reexperienced the bug today on an Ubuntu 18.04 installation of Slicer 4.10.2. I was able to fix it by deleting Documents/SlicerDICOMDatabase without uninstalling Slicer. I think I can regard this as a solution. It is good enough in my use case.
Small update: A new quality check on the database has shown that some very specific pairs of patients whose images stayed the same after the deletion of DICOMSlicerDatabase were actually real duplicates. That is, the person who uploaded the DICOM data on our servers erroneously uploaded patient A’s images for both patient A and B. This was the source of the unexpected behavior listed in point 3 of my answer of June 16.
So I reaffirm the validity of deleting DICOMSlicerDatabase to solve the initial problem.