# incorrect patient name in zip archive

**URL:** https://discourse.orthanc-server.org/t/incorrect-patient-name-in-zip-archive/2867
**Category:** Google Groups archive
**Created:** [April 14, 2022, 3:45am UTC](https://discourse.orthanc-server.org/t/incorrect-patient-name-in-zip-archive/2867 "2022-04-14T03:45:20Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![Jeremy\_Gray](https://discourse.orthanc-server.org/letter_avatar_proxy/v4/letter/j/9de053/32.png) [@Jeremy\_Gray](https://discourse.orthanc-server.org/u/Jeremy_Gray)
#### Post date: [April 14, 2022, 3:45am UTC](https://discourse.orthanc-server.org/t/incorrect-patient-name-in-zip-archive/2867/1 "2022-04-14T03:45:20Z")

</div>

Greetings,

An incorrect patient name appeared as part of top level folder. I  
never check this routinely, an end-user reported it to me. I have no  
idea if this has happened before and no one has said anything.

Orthanc v1.10.0

Two studies from the same scanner, same RequestingPhysician, were sent  
into Orthanc about 2 hours apart on the same day, no intervening  
studies. I used API calls to get an archive (.zip):  
curl http://{host:port}/studies/{id}/archive --output {file}.zip

First study everything looks correct:  
archive RUGG-Srokova.fMRI97.247ad82c-f00a9a44.zip  
unzips to '04122022 y16 FMRI97'

Second study, different research participant:  
The top level directory name was not updated to reflect new  
PatientName "o21^FMRI92". That is, "y16 FMRI97" in the unzipped  
archive directory name is incorrect, and conflicts with DICOM header  
values for this study

archive RUGG-Mingzhu.fMRI92.85cfa436-45ca84a5.zip  
unzips to '04122022 y16 FMRI97'

$ dcmdump RUGG-Mingzhu/MR000039.dcm | grep -i fmri  
(0008,1030) LO [Mingzhu^fMRI92] # 14, 1  
StudyDescription  
(0010,0010) PN [o21^FMRI92] # 10, 1 PatientName  
(0040,0254) LO [Mingzhu^fMRI92] # 14, 1  
PerformedProcedureStepDescription

The next (3rd) study was the next day, different RequestingPhysician.  
Unzipping revealed no obvious issues.

Re-downloading an archive of the second study, the wrong directory  
name remained in the new archive.

I do have --verbose log data if some part of that might be useful (43M  
and I'd have to dig through).

Thanks for giving it a look,

--Jeremy

---

<div class="post-metadata">

### Author: ![jodogne](https://discourse.orthanc-server.org/user_avatar/discourse.orthanc-server.org/jodogne/32/1511_2.png) [@jodogne](https://discourse.orthanc-server.org/u/jodogne)
#### Post date: [April 16, 2022, 9:00am UTC](https://discourse.orthanc-server.org/t/incorrect-patient-name-in-zip-archive/2867/2 "2022-04-16T09:00:44Z")

</div>

Dear Jeremy,

Unfortunately, we cannot provide any help without a minimal working example:  
[https://book.orthanc-server.com/users/support.html#discussing-a-minimal-working-example](https://book.orthanc-server.com/users/support.html#discussing-a-minimal-working-example)

Please share a set of DICOM files, and the exact sequence of “curl” command lines to reproduce your issue.

Kind Regards,  
Sébastien-

---

<div class="post-metadata">

### Author: ![Jeremy\_Gray](https://discourse.orthanc-server.org/letter_avatar_proxy/v4/letter/j/9de053/32.png) [@Jeremy\_Gray](https://discourse.orthanc-server.org/u/Jeremy_Gray)
#### Post date: [April 17, 2022, 12:53am UTC](https://discourse.orthanc-server.org/t/incorrect-patient-name-in-zip-archive/2867/3 "2022-04-17T00:53:58Z")

</div>

I’m now confident it was operator error at the scanner console. But a good thing is that this incident has made me aware that I need the MR techs and researchers to use globally distinct PatientID values.

No further investigation requested from this list. I could send two image files, one from each participant, but thats not necessary.

I discovered that they have the same PatientID, despite having different PatientNames in the DICOM headers. It looks like the MR tech entered the date (04122022) into the PatientID field by mistake. That value was the scan date (April 12, 2022). The two scans were on the same day, so the same date was entered for each participant. This resulted in Orthanc correctly treating them as different studies from the same ParentPatient (“Patients are identified as the SHA-1 hash of their PatientID tag (0010,0020)”)

With two instances / images, one from each research study participant (short file names 85c.dcm, 247.dcm named after the ParentStudy):  
$ dcmdump 85c.dcm | grep PatientID  
(0010,0020) LO [**04122022**] # 8, 1 PatientID  
$ dcmdump 247.dcm | grep -i PatientID  
(0010,0020) LO [**04122022**] # 8, 1 PatientID

$ curl -X POST [http://localhost:8041/instances](http://localhost:8041/instances) --data-binary @247.dcm  
{  
“ID” : “fb5267bb-fa0016af-cc3d1b1e-ef270fc1-531a6e5b”,  
“ParentPatient” : “ **7f337b77** -b7492d6d-08e31993-20f4d666-2faa50ed”,  
“ParentSeries” : “dba38c78-10221b2a-63606e88-cca06a74-5d05ec6d”,  
“ParentStudy” : “247ad82c-f00a9a44-309c05bf-c65cbe3c-d594e78f”,  
“Path” : “/instances/fb5267bb-fa0016af-cc3d1b1e-ef270fc1-531a6e5b”,  
“Status” : “Success”  
}

$ curl -X POST [http://localhost:8041/instances](http://localhost:8041/instances) --data-binary @85c.dcm  
{  
“ID” : “b47373d4-45655c27-ae12c53d-d425c9aa-57dd030e”,  
“ParentPatient” : “ **7f337b77** -b7492d6d-08e31993-20f4d666-2faa50ed”,  
“ParentSeries” : “2ca6df3e-c8b6754d-08c72ef8-9d717e4f-a9b5ad59”,  
“ParentStudy” : “85cfa436-45ca84a5-783b8dc8-4888ca84-8e0cedaa”,  
“Path” : “/instances/b47373d4-45655c27-ae12c53d-d425c9aa-57dd030e”,  
“Status” : “Success”  
}

$ curl [http://localhost:8041/studies/247ad82c-f00a9a44-309c05bf-c65cbe3c-d594e78f/archive](http://localhost:8041/studies/247ad82c-f00a9a44-309c05bf-c65cbe3c-d594e78f/archive) --output 247.zip  
$ curl [http://localhost:8041/studies/85cfa436-45ca84a5-783b8dc8-4888ca84-8e0cedaa/archive](http://localhost:8041/studies/85cfa436-45ca84a5-783b8dc8-4888ca84-8e0cedaa/archive) --output 85c.zip

When I unzip the two Zip files, the directory name is the same: its the PatientName from the first image that was sent into Orthanc. If I reverse the order of upload, it switches the name.
