We are using the Orthanc plugin Docker image version 1.12.6 for integrating OHIF. We encountered an issue where, if the Patient ID is set to NA for certain studies, navigating to the URL:
/ohif/viewer/studyInstanceUIDs={studyInstanceUID}
displays not only the selected study but also the studies of other patients on the left panel, as shown in the attached screenshot. This seems to occur specifically when the Patient ID is marked as NA.
Our main concern remains that using “NA” as a Patient ID is not compliant with DICOM standards, but we want to avoid modifying the Patient ID DICOM tag to introduce a synthetic identifier (e.g., a combination of name, gender, DOB, StudyInstanceUID, etc.).
Could you please advise if there is a known fix or workaround for this issue?
We appreciate your suggestion. We contacted the OHIF forum last week, and after analyzing the issue, they advised us to reach out to the Orthanc discussion forum for further assistance.
I wanted to have a look at this issue, mostly out of curiosity, because I don’t know OHIF at all, but cannot really reproduce it, or maybe I don’t understand it.
When you say “NA”, I assume that you mean that the PatientID tag is not present in some instances, is that right?
I have launched the docker 1.12.6 image and have imported three studies, MAMMO, NEURO and ORTHO. In a few of these instances, I have manually removed the patient ID tag in some instances of the MAMMO study.
It leads to OHIF displaying the MAMMO study twice (just like Orthanc does), because some instances in it have different PatientID tags (which is indeed not DICOM-compliant)
Thank you for taking time to look into this issue.
The scenario I am describing occurs when two different patients (e.g., Patient A and Patient B) have their PatientID set to NA while having distinct StudyInstanceUID values.
In this case, if you navigate to /ohif/viewer/studyInstanceUIDs={StudyInstanceUIDofPatientA}, it displays both Patient A’s and Patient B’s studies in the left-hand panel, even though they belong to separate studies with different StudyInstanceUID values.
The expected behavior would be for it to display only the studies corresponding to the specified StudyInstanceUID in the URL, without including unrelated studies from other patients.
Let me know if you need any additional details or steps to reproduce the issue.
If it is not possible to disable the display of studies from the same PatientID in an OHIF configuration. Then, your only chance is to write an Orthanc python plugin to intercept the QIDO-RS query to Orthanc and make it return an empty result.
I have actually run into the exact same issue. We also have a bunch a DICOM studies with meaningless patient IDs, shared between multiple unrelated studies. That I did not want to all show up in the OHIF sidebar.
So, first thing to realise, as it seems you have done, is that this is intended behaviour on both Orthanc and OHIFs side. The issue is really with our non compliant use of the PatientID field.
In OHIF by clicking the small settings icon above the study list, you can change the study mode. by changing from the default “all” to “primary” it will only show the selected study.
So, my fix was to in the OHIF code change to default mode from “all” to “primary”. This presents the user with only the selected study as a default, while leaving the option to view all open. Which was desirable for me.
For me this was a trivial change to implement as I was already using a self-compiled OHIF, and not the Orthanc plugin. I am not aware of a way to make this change in a pre-compiled OHIF.
Actually, there is a way to fix this without self-compiling OHIF. Or there will be with OHIF 3.10.0, which is not in the Orthanc plugin yet, but I assume will come.
And OHIF will then as a default only shown the user the selected study in the sidebar.
Again, note that this does not work in OHIF 3.9.2, which i believe is the current version in the Orthanc plugin, as 3.10 is still in beta. But, in the future this solution should work and be quite straight forward to implement.
Thank you for the detailed explanation! I had tried this configuration before, but it didn’t work—likely because, as you mentioned, the Orthanc plugin currently uses OHIF 3.9.x. I’ll keep an eye on the 3.10.0 update and revisit this solution once it’s available
Thanks for the detailed analysis! As far as the OHIF plugin for Orthanc is concerned, we can indeed only package official releases of OHIF, as new beta versions of OHIF are frequently available. Do not hesitate to ping us once OHIF v3.10.0 becomes available.