parent patient id is not the actual patient

Google Groups archive
1

Hello,

I have something akward going on.

I have a new machine connected to orthanc for which I like to archive existing examinations. It is a Zeiss visucam which has mass export functionality.
The issue is that the studies are wrongly allocated to I think the first patient, also looking through the /changes - only a newPatient event is recorded for the first patient, not the subsequentt.

I’m not sure if this is some error at the orthanc end or if the zeiss visucam is at fault.

How do I best debug this ?

Carine

Output of the REST API for this study through /studies/{id}

`

{
“ID”: “f886897e-9ccb1db2-eceb3e0e-bf1a4000-8894a129”,
“IsStable”: true,
“LastUpdate”: “20180723T071501”,
“MainDicomTags”: {
“AccessionNumber”: “”,
“InstitutionName”: “xxx”,
“ReferringPhysicianName”: “”,
“StudyDate”: “20170203”,
“StudyID”: “789”,
“StudyInstanceUID”: “1.2.276.0.75.2.1.20.0.1.170203103551984.1100827.20126”,
“StudyTime”: “103551.0000”
},
“ParentPatient”: “da39a3ee-5e6b4b0d-3255bfef-95601890-afd80709”,
“PatientMainDicomTags”: {
“PatientBirthDate”: “19531209”,
“PatientID”: “”,
“PatientName”: “WUSTLAST^FIRST^^^”,
“PatientSex”: “F”
},
“Series”: [
“7f78e352-6be58921-039969b4-c281f24e-c75e3249”,
“333cf482-bb5a8db5-7bddc66c-cdcdc006-be3e5d5a”,
“bc2610c3-38b5a846-7fd16d5f-5bb2386e-137feba6”,
“8de31a92-a6703185-47ea6d04-c396764a-b2d15c4c”,
“bab59433-862fece3-210b95ce-36b330ce-0be32144”,
“21778e54-a08e1aac-c6057b95-5faca158-539ab827”,
“54011cef-3fa6e600-ce6d25f8-7be920c4-a0279d6c”,
“42a49e29-128da66b-191132da-03345ccc-8c109d2c”,
“4e3d5ac6-7d1198d0-e48fed16-40244f35-4f4edc31”,
“9b5ba4e6-0c39c479-f7d09b73-44736b5a-25c25399”,
“e4e3bfe1-cd202859-e9e30932-d5a0a5e5-977b76d9”,
“216b2014-4aa36164-a76d3de6-e1f8a16a-f4001238”,
“71515415-cfa850d9-a0eca819-7658ed4d-a9f6b274”,
“8bd8df15-2d1a8458-7ca22453-5f60c443-99b9db5e”,
“a5e47002-599b910f-fdd9d35f-d11c484a-7e0eea6c”,
“53b35cfc-048a9302-ee291c4d-7a4238a2-72fcce85”,
“749c67ce-6535610c-25aca3a4-6a2936e0-666e49ef”,
“262cf53f-1a6fa0e4-3fa096ee-3affcf7d-c0e6b797”,
“a2e3b061-812f62a1-cf6adbb9-cf3069e0-c637c4cb”,
“90ec8bfa-0c47285e-4482bb75-e35e0bf1-95e39164”,
“2bc5d3a9-41a8a1b2-43fa4f62-8c75057f-be46d955”,
“65c57f32-a9131eb5-f93224ff-c53356ae-bdf1029f”,
“dced573b-8a111834-3e741310-0e23d41c-8854e164”,
“1a3de447-bbe14afc-a82f6a14-2cba0fca-79ec0788”,
“6971f362-5f053c38-de81b762-42e4e61c-7da32017”,
“518cb297-df609bcd-f0309512-4ef56181-6508da50”,
“3bd4e64b-930d7453-8ead586d-9554c523-704050c7”,
“ae9d3706-1fbc4587-8b46a74e-9cc3f4f1-9919cacc”,
“704d0281-624c1997-b0297c3a-e547485e-aec50050”,
“36f34575-804659eb-b91cd135-da2197c0-5ab31ddf”,
“43e91fda-653ceb20-ef3d5d02-2761305b-a3b5b67a”,
“4f205664-034ff30c-4719fe63-aa191993-260d14f0”,
“55e33979-2e2fe44d-794fa544-69c79f5b-605b8c9c”,
“8637b04f-3210266d-e9daccdb-32f57c32-11ff000a”,
“a1ce7d6a-9861ef00-303c678e-31716d5d-525820b6”,
“72da3da6-23d192c8-42abd6b0-e7f20a18-216168e9”,
“b32df6fd-9c9ffe72-242046e1-6651e214-62fef786”
],
“Type”: “Study”

`

Output of /patients/{id = parentpatient from above study}

`

{
“ID”: “da39a3ee-5e6b4b0d-3255bfef-95601890-afd80709”,
“IsStable”: true,
“LastUpdate”: “20180723T071728”,
“MainDicomTags”: {
“PatientBirthDate”: “19261002”,
“PatientID”: “”,
“PatientName”: “ADRILAST^FIRST^^^”,
“PatientSex”: “M”
},
“Studies”: [
“44f66761-fe06ec49-549e0f05-a73a3604-8a2e8c4a”,
“f886897e-9ccb1db2-eceb3e0e-bf1a4000-8894a129”,
“ea0833bf-456c0c64-0d9c386a-7521f1a9-1216df8b”,
“7a4dcd27-36a5162f-d7b1cff8-77aab56d-1972628b”,
“c63969f4-e3ab9d76-7eb1e743-82d877be-1caed94e”
],
“Type”: “Patient”
}

`

2

Ofcourse and then when you spell it out … you see the flaw … patientID is not filled out as the birthdate is used as the pseudo id on the system …
PatientID is blank - thus the same …

Sorry for the distraction - hopefully another newbee might find this usefull :smiley:

Thx
Carine

3

Hello,

There is a known issue whereby when multiple DICOM instances declare
different patient data for the same patient (i.e. same patient ID)
Orthanc will pick only one of them as reference when exposing the
patient data on the /patients resource.

(Orthanc derives its own patient IDs from the DICOM patient IDs.)

Another more intuitive way of looking at it: multiple DICOM studies
probably mistakenly reuse the same patient ID.

If that's the case, either:

- Consider improving data quality by reassigning Patient IDs
(0010,0020) so they're unique.

- Use /studies exclusively to retrieve patient data.

Some notes for future considerations:

- After perusing the standard quite quickly it feels to me that patient
IDs needn't be unique (not even locally) so long as the "Issuer of
patient ID" is different (one could then argue that Orthanc should
include that data in the Patient ID hash, but this would be
disruptive). Even then I'm not finding immediate confirmation about
that requirement. This means your data isn't necessarily "bad", and
there is no straightforward solution to this problem.

- It might be possible for Orthanc to return a list of unique patient
entries for a given patient ID (or patient/issuer ID pair) on the
/patients resource instead of just one, and in a backward-compatible
way. Anyone willing to have a think about that is welcome to it
(consider design, implementation cost and runtime cost angles).

Until then, one should be very careful when using the /patients
resource, and prefer other resources instead.

4

Hello,

As a correction to Thibault’s answer, since Orthanc 1.4.0 (released last week), Orthanc Explorer has the possibility to browse the content of Orthanc by studies (check out the newly-introduced “Studies” tab in Orthanc Explorer):

In this “Studies” tab, even though your patients share the same “Patient ID”, they will appear separated.

For those interested, the facts that DICOM “Patient IDs” are not unique, and why the “/studies” REST URI should be privileged in multi-hospital scenarios, are explained in the Orthanc Book:
http://book.orthanc-server.com/faq/orthanc-ids.html

HTH,
Sébastien-