Updating Patient Metadata for existing patients?

Google Groups archive
1

Hi,

I want to import lots of old images into Orthanc and was surprised that Patient information seems not to be updated after the Patient has been created.

Is this by design?

And is there a way, via HTTP or a Lua script, to update Patient information without deleting/reimporting all of a patients instances?

The reason this matters to me is because I would like to import all my legacy data into Orthanc, and later fix the issues by updating all the instances that have inconsistencies. (In the future I probably add a Lua script that does this on import [1])

Let's say I have a few instances with the same PatientID, but different patient names:

  img2dcm -k "(0010,0020)"="test" -k "(0010,0010)"="A" a.jpg a.dcm
  img2dcm -k "(0010,0020)"="test" -k "(0010,0010)"="B" a.jpg b.dcm
  img2dcm -k "(0010,0020)"="test" -k "(0010,0010)"="C" -k "(0010,0030)"=20161101 a.jpg c.dcm

When I send the first instance to Orthanc, a Patient is created.

  dcmsend -v localhost 4242 a.dcm
  curl -s "http://orthanc:orthanc@localhost:8042/patients/a94a8fe5-ccb19ba6-1c4c0873-d391e987-982fbbd3" | jq ".MainDicomTags.PatientName"
  #=> "A"

When I send the second instance, it is associated with the same Patient, and the Patient.LastUpdate timestamp is updated.
Patient metadata is not updated however:

  dcmsend -v localhost 4242 b.dcm
  curl -s "http://orthanc:orthanc@localhost:8042/patients/a94a8fe5-ccb19ba6-1c4c0873-d391e987-982fbbd3" | jq ".MainDicomTags.PatientName"
  #=> "A"

Sending a third instance with additional attributes also does not add these attributes to the patient:

  dcmsend -v localhost 4242 c.dcm
  curl -s "http://orthanc:orthanc@localhost:8042/patients/a94a8fe5-ccb19ba6-1c4c0873-d391e987-982fbbd3" | jq ".MainDicomTags.PatientBirthDate"
  #=> ""

Deleting older instances (a.dcm, b.dcm) does not change the Patient data either. The only way I could find to change what is returned in Patient.MainDicomTags was to delete all Studies/Instances and add them again (in a different order)

This was surprising to me. I would have expected the last Instance that is sent to Orthanc to "win" and the patient tags to be updated. (although Patient BirthDate won't change, PatientName is relatively likely to for at least some Patients)

The place where this comes up as an issue seems to be in two places:

- C-Find on the patient level uses the global patient. `findscu -k 0008,0052=PATIENT -k PatientName=B` will not return anything.
  But then, C-Find by Patient name on the patient level is probably a bad idea anyway.

- The web interface looks wrong: http://i.imgur.com/xwfGlo5.png (should the patient information that is displayed here come from the Study?)
  But I'm not going to use the web interface because it doesn't handle the amount of data I'll have inside Orthanc

Poking a bit more, I see that the Patient information in studies is _not_ the global patient but the patient specific to that study, nice!

Thank you,
Levin Alexander (sorry about writing so many emails)

(I'm using "Orthanc version: mainline (20160927T190404)" from the docker image with default settings)

[1] I'm delighted by how easy to use and useful the callbacks look. Looking forward to writing some. :slight_smile:

2

Dear Levin,

Sorry for the delay, your questions were rather involved :wink:

Let me first explain the issue with your test. The problem is that you were creating 3 DICOM files sharing the same “Patient ID”. The DICOM model of the real-world expects that all of the patients sharing the same “Patient ID”, share the same values for their respective “Patient Identification Module” (which includes the “Patient’s Name” tag [1]) and “Patient Demographic Module” (which includes the “Patient’s Birth Date” tag [2]). By construction of your test files, this is obviously not the case, and your test files break the DICOM model of the real-world.

Now let’s dive into how Orthanc reacts to such inconsistencies. When it receives the first “a.dcm” file, Orthanc records the patient’s name and birth date in its index. When it receives the “b.dcm” and “c.dcm”, Orthanc detects it already knows about this patient in its index (as they share the same “Patient ID”). Following the DICOM standard, Orthanc thinks that “b.dcm” and “c.dcm” share the same values for all the patient-level DICOM tags. As a consequence, Orthanc simply ignore those values. Note that Orthanc could reconstruct these tags, however, as you pointed out, the final value would still depend on the order in which the files were imported.

To solve this issue, starting with Orthanc 1.2.0 (to be released in the next few days), the URI “/instances/{…}/reconstruct” has been introduced. This URI will explicitly ask Orthanc to refresh the value of the tags across all of the levels of the DICOM hierarchy, starting from the bottom instance of interest. A sample bash script is attached to the current post, to illustrate how this feature can actually solve your issue.

HTH,

Sébastien-

[1] http://dicom.nema.org/medical/Dicom/2016b/output/chtml/part03/sect_C.2.2.html

[2] http://dicom.nema.org/medical/Dicom/2016b/output/chtml/part03/sect_C.2.3.html

Levin2.sh (1.8 KB)

3

Hi Sébastien,

Sorry for the delay, your questions were rather involved :wink:

Thank you for the considerable amount of time you're spending answering questions here, helping people use software that you wrote and that you *also* provide as Free Software. I'm really grateful for that. Thank you for taking the time.

Let me first explain the issue with your test. The problem is that you were creating 3 DICOM files sharing the same "Patient ID". The DICOM model of the real-world expects that all of the patients sharing the same "Patient ID", share the same values for their respective "Patient Identification Module" (which includes the "Patient's Name" tag [1]) and "Patient Demographic Module" (which includes the "Patient's Birth Date" tag [2]). By construction of your test files, this is obviously not the case, and your test files break the DICOM model of the real-world.

Now let's dive into how Orthanc reacts to such inconsistencies. When it receives the first "a.dcm" file, Orthanc records the patient's name and birth date in its index. When it receives the "b.dcm" and "c.dcm", Orthanc detects it already knows about this patient in its index (as they share the same "Patient ID"). Following the DICOM standard, Orthanc thinks that "b.dcm" and "c.dcm" share the same values for all the patient-level DICOM tags. As a consequence, Orthanc simply ignore those values. Note that Orthanc *could* reconstruct these tags, however, as you pointed out, the final value would still depend on the order in which the files were imported.

Yeah, the issue is mostly that the Dicom Model Of The Real World and my dicom files don't agree :slight_smile: (People marry and change their names, Someone, sometime in 2006, made a typo on a device that didn't support Worklists, things like that)

I didn't mean to say that Orthanc was wrong, I was only surprised by its behaviour.

To solve this issue, starting with Orthanc 1.2.0 (to be released in the next few days), the URI "/instances/{...}/reconstruct" has been introduced. This URI will explicitly ask Orthanc to refresh the value of the tags across all of the levels of the DICOM hierarchy, starting from the bottom instance of interest. A sample bash script is attached to the current post, to illustrate how this feature can actually solve your issue.

Wow, thank you.

Yes, "/reconstruct" will help me fix that issue and fix it in a neat and predictable way.

--Levin