OHIF Plugin for Orthanc Displays Multiple Patients' Studies When Patient ID is NA

General
1

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?

image
image1280×654 104 KB

2

Hi @KomalReddySVAIM

You should probably ask this question on the OHIF forum because, from the Orthanc perspective, Orthanc seems to work correctly.

Alain

3

Hi @alainmazy

Thank you for your response.

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.

4

Hello,

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)

image
image1532×717 65.7 KB

Selecting either of the MAMMO study always includes all its instances (8 in total), which makes sense, since they all share the same studyInstanceUID.

However, no other patient is included, at least in this simple test.

Can you please explain how to reproduce the behavior you’re describing, if it’s any different from this?

Thanks

5

Hello @benjamin.golinvaux

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.

6

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.

image
image850×512 39.7 KB

Of course, the right solution is not to use the same PatientID for multiple patients :wink:

7

Well, actually, a plugin can not override another plugin’s route so my last solution won’t work…

So, you may just filter that query out in Lua: Server-side scripting with Lua — Orthanc Book documentation

2 Likes
8

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.

2 Likes
9

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.

If you add a UserConfiguration to OHIF, see: OHIF plugin — Orthanc Book documentation

Then you can add the following to the user configuration:

customizationService: [
    {
      'studyBrowser.studyMode': {
        $set: 'primary',
      },
    },
  ],

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.

2 Likes
10

Thanks for the clarification! I’ll check this out and explore filtering the query in Lua. Appreciate your help!

11

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

12

Hello,

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.

Kind Regards,
Sébastien-

13

Hi Sébastien @jodogne

You said to not hesitate to ping you when OHIF 3.10 was available. OHIF 3.10 has now been released officially.

Regards, Emil

14

Hi Emil,

I actually started working on the OHIF 3.10 integration and then, we had some issues with authorization, we tried to fix them and you know how it goes, we switched to something else :wink:

Finally, I will release OHIF 3.10 as it is (anyway, these authorization issues were already there before).

Stay tuned on the release channel

Best regards,

Alain