At my company we have some Orthanc servers in production, which are used as PACS for several medic institutions. One recurrent problem reported by the users is the existence of duplicated series, it means, two or more series with the same UUID but belonging to different studies. This problem causes errors on dicomWeb requests, therefore, Ohif viewer crashes trying to obtain the series metadata for study visualization.
We have identified two ways of reproduction of the error, sometimes happen when users split studies in he modality and when users makes recitations of a study. We know that the Orthanc REST API provides the merge/split methods, as described in this thread: Failed http get Request, and it can be a workaround for this problem, but for our context isn´t a solution because the everyday real life operation of our users causes this error so many times and for us isn´t sustainable over time to fix every case.
Have you plans to fix or change this behaviour in Orthanc in the short or medium term?
We FIX things in Orthanc when things are BROKEN in Orthanc which is not clear from your message.
In any way, we can not investigate anything if you don’t provide a minimum of information such as sample data and the OHIF requests that are triggering the issues.
This error occurs when two series (from different studies) with the same SeriesInstanceUID are stored in Orthanc. OHIF fails when calling the following end-point: {URL}/dicom-web/studies/{StudyInstanceUID}/series/{SeriesInstanceUID}/metadata (returns 404)
The error returned by the Orthanc logs is: “Multiple resources match the query (instead of 0 or 1), which indicates your DICOM database breaks the DICOM model of the real world”.
I think it’s a good thing that if Orthanc finds two candidate series it chooses the one with the same StudyInstanceUID or returns the first one (since it has the same SeriesInstanceUID, it’s probably the same series). Same with instances. It’s complex when the system fails because of this (although the responsibility for the duplicate series certainly lies with the person at the hospital who sent it).
I am interested in Rodrigo’s query if there are plans to fix this or how to contribute to the solution.
We can indeed solve the issue by calling tools/find instead of tools/lookup in the LocateSeries method of the DicomWeb plugin. I have added it in the plugin TODO.
Looking back, this error also happens with studies (we’ve had duplicate study cases with the same StudyInstancesUID) and instances. Not just duplicate series.
I’ve encountered a similar issue occasionally when a series get attached to 2 different studies, usually when someone does a merge or otherwise ‘edits’ a study and then forgets to clean up afterwards. What happens in that case is that there is a eye with a slash through the series that is ‘duplicated’ in the stone viewer. That actually does not happen with the old Osimis viewer because I think you fetch by uuid’s there rather than UID’s. Any idea when that might be added to the DicomWeb plugin ?
Note that, if you have 2 instances with the same UIDs at every level: Study, Series and Instance but with different PatientID, the plugin won’t be able to return anything since there would be no way to differentiate them since DicomWeb is only using the Study, Series and Instance UIDs.