StudyInstanceUID with different patients


Today I was surprised by the following situation:

The same StudyInstanceUID for different PatientID, example:

Patient: MARIA (StudyInstanceUID =
Patient: JOAO (StudyInstanceUID =

Could someone guide me? What could have happened? Bug

Is it possible to correct?

Thank you!

Orthanc never modifies the StudyInstanceUID unless you use the /anonymize /modify routes. So, I would assume your problem comes ahead of Orthanc in your DICOM data source or whatever.

To correct the issue, I recommend you to read this part of the documentation:

Hello Alain,

Thank you very much for your help, I used this option to modify the tags with patient data and everything went fine, the only tag I could not change was “PatientID”, Orthanc returns “bad request”, what could have happened?

Thank you!

Hi Marcelo,

At what level do you issue the /modify requests ? (patients, studies, instances) ?
Don’t you have any more details from the Orthanc logs ?

Hello everyone

We have a link problem between the ultrasound system and Orthanc. This bug seems random which makes it difficult to fix. Sometimes at the end of ultrasound examinations, the DICOM transfer fails. This seems to happen when there is a larger volume of data than the average. Especially when 3D images are preserved.
The most curious thing is that a secondary manual transfer of the same studies poses no problem.
We are still at the preliminary investigations. The purpose of this mail is to know if other users have encountered this kind of problem. We use Orthanc debian version on Ubuntu server.
Thank you in advance for your feedback !

Have a good day !

B. Boutillier

Hello Alain,

Excuse me…

I made the modification at the “/ studies” level, but it should be “/ patients”, now it worked perfectly!

Orthanc and its community as always sensational …

Thank you very much!


Dear Bertrand,

First of all, make sure you use a 64-bit version of Orthanc (as the 32-bit version may run of out of memory on large studies).

Secondly, you might try and check whether DCMTK’s storescp faces the same problem. The storescp tool only supports DICOM C-Store, but is a really standard piece of software. If the problem also occurs with storescp (which is most probably the case, as Orthanc is built on top of DCMTK), its “-d” debug mode might give you additional information. I suspect either a problem in your network infrastructure (firewall?), or in the source modality.


Here is an SQL query (PostgreSQL only) to get all StudyInstanceUID with different PatientID in your Orthanc database

with dubles as (
  select q.value, unnest(q.ids) as id from (
    select s.value, array_agg( as ids from (
      select, d.value from dicomidentifiers as d, resources as r where true
        and = r.internalid 
        and r.resourcetype=1 
        and d.taggroup=32 
        and d.tagelement=13
    ) as s
    group by s.value having count(id) > 1
  ) as q
select q.studyuid, array_agg(q.patientid) as patientids from (
  select d.value as studyuid, i.value as patientid from dubles as d
  left join dicomidentifiers as i using (id)
  where i.taggroup = 16 and i.tagelement = 32
) as q
group by q.studyuid;