Message249

Author admin
Recipients
Date 2017-07-11.20:30:22
Content
[BitBucket user: Sébastien Jodogne]
[BitBucket date: 2017-07-11.18:30:22]

This request does not lead to any database inconsistency, it really creates 2 separate studies under the same patient (because they share the same identifier):

```
$ curl http://localhost:8042/studies
[
   "f37603bd-c1f318ed-ca55353f-61aa3375-fc7909b2",
   "2e8d3ccb-d166c44e-99219197-87e84326-7c44bbc4"
]
```

The actual patient for those studies can be retrieved as follows (the `/studies/{...}/module-patient` URI implements the expected "demangling"):

```
$ curl http://localhost:8042/studies/f37603bd-c1f318ed-ca55353f-61aa3375-fc7909b2/module-patient?simplify
{
   "PatientBirthDate" : "19720405",
   "PatientID" : "2345",
   "PatientIdentityRemoved" : "YES",
   "PatientName" : "ORTHO"
}
$ curl http://localhost:8042/studies/2e8d3ccb-d166c44e-99219197-87e84326-7c44bbc4/module-patient?simplify
{
   "PatientBirthDate" : "19720405",
   "PatientID" : "2345",
   "PatientIdentityRemoved" : "YES",
   "PatientName" : "ORTHO2"
}
```

As written in the [Orthanc Book](http://book.orthanc-server.com/faq/orthanc-ids.html), you should always favor study-level queries to avoid such problems.

That being said, one might add a `Force` Boolean to the JSON query, that must be set to `true` as soon as one tries and modifies one of the identifier tags (`PatientID`, `StudyInstanceUID`, `SeriesInstanceUID`, and `SOPInstanceUID`) to prevent any such advanced, non-natural modifications.
History
Date User Action Args
2026-07-29 15:51:20adminlinkissue55 messages
2026-07-29 15:51:20admincreate