[BitBucket user: Alain Mazy] [BitBucket date: 2017-07-10.16:06:23] * upload the attached file * you now have one patient 'ORTHO' whose PatientID = 2345 * there is one study in the DB: ``` curl http://localhost:8042/patients/d2f75e82-04fedf2e-acd261e2-461b2964-e3bfd5be { "ID" : "d2f75e82-04fedf2e-acd261e2-461b2964-e3bfd5be", "IsStable" : true, "LastUpdate" : "20170710T175954", "MainDicomTags" : { "PatientBirthDate" : "19720405", "PatientID" : "2345", "PatientName" : "ORTHO" }, "Studies" : [ "f37603bd-c1f318ed-ca55353f-61aa3375-fc7909b2" ], "Type" : "Patient" } ``` * modify this patient to rename it (following the orthanc book recommendation, include the PatientID in the request): ``` curl -X POST http://localhost:8042/patients/d2f75e82-04fedf2e-acd261e2-461b2964-e3bfd5be/modify -v -d {\"Replace\":{\"PatientID\":\"2345\",\"PatientName\":\"ORTHO2\"}} ``` * the request is accepted: ``` < HTTP/1.1 200 OK < Content-Type: application/json; charset=utf-8 < Content-Length: 219 < { "ID" : "d2f75e82-04fedf2e-acd261e2-461b2964-e3bfd5be", "Path" : "/patients/d2f75e82-04fedf2e-acd261e2-461b2964-e3bfd5be", "PatientID" : "d2f75e82-04fedf2e-acd261e2-461b2964-e3bfd5be", "Type" : "Patient" } ``` * there are now 2 studies in Orthanc, one with the 'ORTHO' patient name and one with 'ORTHO2' ``` curl http://localhost:8042/patients/d2f75e82-04fedf2e-acd261e2-461b2964-e3bfd5be { "ID" : "d2f75e82-04fedf2e-acd261e2-461b2964-e3bfd5be", "IsStable" : true, "LastUpdate" : "20170710T180244", "MainDicomTags" : { "PatientBirthDate" : "19720405", "PatientID" : "2345", "PatientName" : "ORTHO" }, "Studies" : [ "f37603bd-c1f318ed-ca55353f-61aa3375-fc7909b2", "a87e76fa-e87bb7d0-ba36c979-5b7833ec-54ec88a2" ], "Type" : "Patient" } ``` We should either: - forbid the request since it will lead to DB - files inconsistencies - accept the request but remove the original studies and rename the patient in DB (this is, I think, the expected behaviour) - carefully document this behaviour.
Created attachment 90 [details] MR000005.dcm
[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.
[BitBucket user: actocoa] [BitBucket date: 2017-07-12.11:45:25]  Hi Sébastien, The duplication, in the screenshot above, was the result of uploading a very same DICOM image for 4 times, when I used the LUA script you gave me earlier. I realized this happened because a new sets of study/series/instance UIDs were assigned to each new duplication when modification was made. Without the original UIDs, ORTHANC can no longer tell if a very same copy of DICOM image is already there in the server. I believe that ORTHANC is a very good choice for clinics as in my case (In contrary, setting up DCM4CHEE was quite a pain). However, the duplication demonstrated above is truly a real world problem. In my clinic, patients usually bring in their image DVDs for advice, which they get from hospitals. Very often, they come back later with a new DVD which contains not only new studies but also the whole series of old ones. Duplication happens when these new DVDs were uploaded. So far, I still couldn't find way to "heal" or circumvent this duplication. I understand the duplication has its own merits, but it could also be a problem in some cases. So... Would it be possible that the duplication be the default setting in ORTHANC but also allow users to disable it? I think it helps definitely if this can be done. Thanks!
Created attachment 95 [details] 2108635977-The%20Duplication.jpg
[BitBucket user: Sébastien Jodogne] [BitBucket date: 2017-07-12.12:22:54] @actocoa Actually, your problem is not an issue within the Orthanc database, but is a UX issue (user experience). All stems from the fact that Orthanc Explorer accesses images starting from the "Patient" level, whereas you would expect the "Study" level. We acknowledge that [queries should be done at the study level](http://book.orthanc-server.com/faq/orthanc-ids.html) as soon as you deal with an application that handles patients from different hospitals. Unfortunately, Orthanc Explorer was not conceived for inter-hospital scenarios. I kindly invite you to read this FAQ: http://book.orthanc-server.com/faq/improving-interface.html The Orthanc project would love to create a more involved user interface than the current built-in Orthanc Explorer. The only problem is that we need funding. Please let us know if your clinic would be interested in getting part in this crowdfunding campaign.
[BitBucket user: Sébastien Jodogne] [BitBucket date: 2017-07-14.09:18:04] fix issue #55 (prevent anonymization/modification to unexpectingly break the database model) → https://hg.orthanc-server.com/orthanc/changeset/53df86a17e99