Only the PatientID tag is used to determine match of incoming DICOM data with existing patients.

Google Groups archive
1

Steps to reproduce this issue:

  1. Need two DICOM files (sample attached) with these specifications:

  2. PatientID is blank. (PatientID is a type 2 DICOM tag).

  3. PatientName, Sex and BirthDate are clearly from two different patients.

  4. Files have different StudyUID’s, SeriesUID’s and SOPUIDs.

  5. In my example I have names of “Flintstone^Fred” and “Rubble^Betty”: Here is a summary of the tags:

dcmdump (1/2): CT_1234.1.1.2.1.1.1.dcm

(0010,0020) LO (no value available) # 0, 0 PatientID

(0010,0010) PN [Flintstone^Fred] # 16, 1 PatientName

(0010,0030) DA [19490605] # 8, 1 PatientBirthDate

(0010,0040) CS [M] # 2, 1 PatientSex

dcmdump (2/2): CT_1234.2.2.1.1.1.dcm

(0010,0020) LO (no value available) # 0, 0 PatientID

(0010,0010) PN [Rubble^Betty] # 12, 1 PatientName

(0010,0030) DA [19531002] # 8, 1 PatientBirthDate

(0010,0040) CS [F] # 2, 1 PatientSex

  1. Use and Orthanc server with no current patients (makes it simpler to see problem)
  2. Send the DICOM files to the Orthanc server: “storescu --call ORTHANC 192.168.1.65 4242 CT* -v”
  3. Display the list of patients in Orthanc – there is just one patient:

curl http://192.168.1.65:8042/patients

[ “da39a3ee-5e6b4b0d-3255bfef-95601890-afd80709” ]

  1. Display the properties of this patient: (matches what you see in the explorer in browser GUI):

curl http://192.168.1.65:8042/patients/da39a3ee-5e6b4b0d-3255bfef-95601890-afd80709

{

“ID” : “da39a3ee-5e6b4b0d-3255bfef-95601890-afd80709”,

“IsStable” : true,

“LastUpdate” : “20200622T123419”,

“MainDicomTags” : {

“PatientBirthDate” : “19490605”,

“PatientID” : “”,

“PatientName” : “Flintstone^Fred”,

“PatientSex” : “M”

},

“Studies” : [

“038e34f6-4ca9d397-fc3c67f2-0f0d3099-71be36ad”,

“2129dfc0-4ddd101c-e01d7f91-d40ee8b1-1aab1503”

],

“Type” : “Patient”

}

  1. Do a DICOM query to see list of patients – you only see one patient but it does not match what you see in the Explorer:

findscu -S -k QueryRetrieveLevel=PATIENT -k PatientID= -k PatientName= --call ORTHANC 192.168.1.65 4242

I: ---------------------------

I: Find Response: 1 (Pending)

I:

I: # Dicom-Data-Set

I: # Used TransferSyntax: Little Endian Explicit

I: (0008,0005) CS [ISO_IR 100] # 10, 1 SpecificCharacterSet

I: (0008,0052) CS [PATIENT ] # 8, 1 QueryRetrieveLevel

I: (0010,0010) PN [Rubble^Betty] # 12, 1 PatientName

I: (0010,0020) LO (no value available) # 0, 0 PatientID

I think the main issue I am concerned about here is the fact that Orthanc considers these two DICOM files to belong to the same patient when importing this data. These patients have nothing in common at all. I have seen sites that regularly have blank PatientID’s and this is allowed per DICOM standard as far as I know.

I know of no guidance from the DICOM standard as far as how to decide if incoming data belongs to an existing patient or should be assigned to a new patient. I once asked about this to a guy who regularly attended DICOM meetings and got a blank stare. Different vendors do it different ways. But I believe using PatientID alone for this logic is not correct. Even if it is not blank….it is possible that data from a new patient (maybe a scan arriving to a site from a third party scanner on CD for example) may have a matching PatientID. And there are patient safety concerns if DICOM images are used somehow for the diagnosis and treatment of the wrong patient.

Thanks for your consideration in advance.

Stacy Loesch

OrthancBugReport.7z (1.2 KB)

2

Followup question on this issue - is there any way to control this behavior via the existing plugin architecture?

Stacy.

3

Hi Stacey,

Inside a “domain”, the Patient ID is supposed to be unique. Since “null” is a valid patient ID, I’m not surprised that both files are attached to the same “null” patient (at least that’s how Orthanc is expected to work).

If you don’t trust your patient data, just don’t use them and work at the study level as explained in the orthanc-book:

The patient-level identifiers are not guaranteed to be globally unique, and might collide between different hospitals (that’s what you have with your “null” patient). For this reason, you should always do queries at the study level as soon as you deal with an application that handles patients from different hospitals.

Best regards,

Alain.

4

Alain,

Thanks for your response.

I change my test case slightly to make the PatientID “123456” instead of blank. So we still have two different patients but with the same PatientID. I also attach this data in case you want to see it.

As you suggest I try using findscu at STUDY LEVEL.

• findscu -S --call ORTHANC -k QueryRetrieveLevel=STUDY -k PatientID=123456 -k PatientName= -k StudyInstanceUID= localhost 4242.

I get a list of two studies. The PatientName parameter matches with the name of each StudyInstanceUID that was sent to Orthanc.

• I add –k PatientName=”F*” and I get only the StudyUID for Flintstone.
• I add –k PatientName=”R*” I get only the StudyUID for Rubble.

So from a findscp and movescp response standpoint I don’t see anything wrong with this behavior to queries at the STUDY level.

However in the Othanc web explorer interface only one patient is shown. And it will be easy to view images in the explorer interface thinking you are looking at images of Fred Flintstone when it is actually Betty Rubble. This is what concerns me the most about this test case (and the one with the blank patientId’s as well).

It is also true that from the explorer interface looking at the single patient it is possible to send to a remote modality what you think is all data for Flintstone but you will actually be sending data for both patients. This is a secondary concern I would say.

I also want to make the point that I believe in DICOM when a type 2 value is empty I believe this means “Value Unknown”. So with the blank patientID tags – which are valid – the manufacturer who creates this DICOM is saying they don’t know what the PatientID is. Yet you are then interpreting this blank value as if it is a very significant piece of information. This is what concerns me about the Orthanc response to my first test case here.

Finally I want to mention that I am not working with Orthanc as a user. I am working on Orthanc as a developer at Varian Medical Systems.

Stacy.

OrthancBugReport.3.7z (7.94 KB)

5

Same problem to me!
I have few patiente wirth same PatientID (11111111111) and all of thhis patients is asimilated as one patient.
On orthancserver Webpage if i Do lookup the names is show correctly, but if I enter on one of this patients, will show only one name ( first name entered on this patientID)
If I use Weasis or Radiant to read everything is ok.

miercuri, 24 iunie 2020, 21:51:55 UTC+3, Stacy Loesch a scris:

6

Hi Stacy,

I get your point.

Indeed, given the way Orthanc handles “patients” it might be somehow “dangerous” to work at the patient level in the interface once you have ingested this kind of “borderline” data.

I’m saying “borderline” because I think we could be debating for quite some time if these datas are valid or not and, anyway, there’s always a compromise between the DICOM standard and real life in which all patients of a radiology center can have the same PatientID :frowning:

  • To me, having 2 patients with the same PatientIDs breaks the DICOM model. This means that you can not trust your PatientID and therefore should never work at patient level. As you mentioned, everything works fine at the study level. BTW, in your opinion, what combination of tags would define a patient in this case ? If I can not trust the PatientID, why would I trust the PatientBirthDate or the PatientName (which is very often misspelled BTW)

  • Having some instances with “null” as the PatientID and “null” meaning “I don’t know” is somehow interesting. In this case, we could eventually try to “attach” this instance to an existing study based on the StudyInstanceUID and therefore attach this instance to the right patient. But what if this instance comes first in Orthanc? How would we know the Patient ? Only option is to attach it to the “null” patient and we’re back to square 1.

This is clearly an interesting discussion so I’m open to any suggestion. What would you be thinking of as an alternative DicomHasher method for Study & Patient ?
For the Study/Series/Instances, we could probably remove the “PatientID” from the hash but, for the Patient …

When I was suggesting “sanitize” your data, that’s also something you can do as a developer by running some scripts to validate/modify incoming data. I.e., if you know that the instances with a “null” PatientID always come from a specific tool that is trying to attach it to an existing study, you could get the PatientID from the existing study and inject it in the instance before pushing it to Orthanc.

As a last comment, if there’s really nothing you can do wrt sanitizing the data, I would just “forget” about the patient UI in Orthanc Explorer (which would mean re-build your own interface) and /patients/ API rest routes and eventually forbid C-Find at Patient level … that would bring you in a “safe” territory.

Best regards,

Alain.

7

If you can not trust the PatientID, don’t work at Patient level and perform your queries at STUDY level. That’s probably what Weasis and Radiant do.

8

Alain,

I definitely agree that an alternative DICOM hasher should not include the patientID at the Study/Series/Instance level. You read my mind on that one.

And I agree that the patient hashing is tricky. As you suggest (probably based on my other issue report) it is best to first look to see if the StudyUID already exists and then you just match to whatever that StudyUID’s parent is. But then after that it is not clear exactly what to do…

I will talk this issue over with a few colleagues of mine and get back to you with a specific proposal for you so we can discuss it then.

If we did want to create an alternative DICOMHasher exactly how would it be implemented? As a plugin replacement of existing hasher? Or through some configuration switch?

Stacy.

9

In fact my problem is the follow:
I make in every night archive for the studies made a day before. I use ArchiveStudiesInTimeRange.py, a little modified to add in name of archive: date, time, studyID, PatientName, PatientID;
Everything is ok, except patient name… look at the output below

root@pacs2:~# python ArchiveStudiesInTimeRange.py http://192.168.10.52:8042/ 20200621 20200621 /mnt/arhiva19

Downloading 20200621-160851.000-26021-POPESCU ION-1111111111111.zip
Downloading 20200621-172233.000-26023-POPESCU ION-1111111111111.zip

root@pacs2:

The real name of this two patients is not POPESCU ION… but everything else is correct; If I open this archive and load studies in a reader (Weasis , Radiant…) it show correct name of the patients
Can you give me a clue how to modify ArchiveStudiesInTimeRange.py file?
Thanks

joi, 25 iunie 2020, 12:48:12 UTC+3, Alain Mazy a scris:

10

Hi Stacy,

From the study, you could go to http://localhost:8044/studies/038e34f6-4ca9d397-fc3c67f2-0f0d3099-71be36ad/module-patient?simplify that returns the patient-module of the study itself which is correct with your test data. Then, you could eventually query all studies with the same PatientName/Sex/BirthDate to get the related studies.

For how to implement another DicomHasher, that’s a tricky question ! Right now, it’s actually too “far” from the ServerContext so it’s not really suited to neither a plugin nor a configuration. I would say that you should first experiment by modifying the current one and see how it goes then we could discuss how we could implement it.

Please keep us up to date of your findings ! I’m currently in an analysis phase for a large DICOM archive and this is typically the kind of problem we’ll encounter. My idea was not to have any “patient” at all in this system and always go back to the studies for all queries (i.e: if you search for patients: first search for studies that match your patient criteria and then just group the results “by patients” …). It’s probably too late to implement this change in Orthanc but who knows …

Best regards,

Alain

11

Hi Adrian,

Same for you, if you use /studies/…/module-patient instead of /studies/…/patient, that should do the trick

If this does not solve your issue please start another thread. This one contains 2 interleaved conversations which is not ideal :slight_smile:

Best regards,

Alain.

12

Hello all, my name is Frederick and I’m running Orthanc for a small medical office in Maine. We have two OEC x-rays that send images to an Orthanc server running on my PC.

My question to the group is related to this discussion, so I thought I’d ask it here first.

Is it possible to set up Orthanc to index patients based on Patient Name and DOB instead of Patient ID?

I ask this because historically our OEC x-rays have pre-populated the Patient ID tag with a unique ID, however a newer machine (OEC One) does not. In the real world, we do not have patients that overlap by name and DOB, so entering a Patient ID is superfluous anyway. Now that we actually have to enter it, we have extra work to do for every patient. If no Patient ID tag is entered, files for all patients with no Patient ID are sorted into the same index folder on Orthanc.

Frederick

13

Hi,

No, it is currently not possible.

In your case, I would strongly advise you to use the “Lookup page”, search for patient name and click “Do lookup” but indeed, this can still lead to confusion for patients with same name and different DOB.

14

Thank you Alain.

Would you be referring to the Query/Retrieve button?

When I enter this function, for some reason I can not select a DICOM server (there is nothing in the drop down box, it’s empty). Searching for known patients by name gives "error during query (c-find).

Frederick

15

I’m referring to the Orthanc “home page”: https://demo.orthanc-server.com/app/explorer.html