changing a patientname/id, delete the original?

When the api is used to change the patient id and/or name, the dataset is copied (I think). Are there reasons not the delete the original dataset? It’s QC datasets so I’m not worried about patient names etc.
And if the instance is renamed through a lua script, is the instance copied as well?

Indeed, when performing modification at series/study/patient level, the original remains as is in the database and a new series/study/patient is created in the DB. The reason is that modification/anonymization are mainly used to anonymize/pseudonymize data before sharing them i.e for a clinical trial, for a second opinion … in these cases, we usually want to keep the original data.

When performing a modification at the instance level, the original remains as is in the database and, actually, the modified version is not saved in the DB but returned to you in the response of the REST API.

So this will only result in multiple db records? The dicom files itself are not copied? Suddenly my hard drive was full, but I’m not sure whether it’s the result of modifying a lot of studies.

No, dicom files are created with the new DICOM tags so they do consume twice the space.
But, if you don’t need the original data anymore, feel free to delete it after the modification.

Ok, so a final check then. I’ve written a script which fires OnStableStudy:

  1. the corresponding patient is found with the api (/studies/id)

  2. the studyinformation is checked (/studies/id/shared-tags)

  3. I define the proper patient name/id whith some rules

  4. With RestPostApi the patient is changed

  5. with RestPostApi the patient is deleted

I suspect this will not result in double dicom data, but is that correct?

Yep, that looks good.
A few remarks though:

  • You should use RestDeleteApi to delete, not RestPostApi
  • Since you’re implementing your code in the OnStableStudy, you should modify/delete the study and not the patient (just in case another study for the same patient is being received while your code is being executed)

I understand your suggestion to modify the study, but that is not working due to a few reasons:

  • it is not possible to replace the PatientID, that will result in a bad parameters response, only the patientname can be changed.
  • the patientName is only changed for the study, when viewing the patient through the api, it will still show the old name. So the browser still shows the old patientname, not the new one.
  • or should I fire a second script OnStablePatient, updating the patientName and ID based on the studies in that patient?

Yes I’m using RestDeleteApi, typo.

Ok, I get your point.

I usually prefer to modify data at instance level (you’re basically free to modify anything at that level).
In another thread, you had a script to modify instances in the OnStoredInstance callback; that’s probably the way to go.

You can still use the OnStableStudy later on to perform anything else like forwarding the modified data or …
Note that, to differentiate the original data and the modified data, you might want to add a custom metadata to the modified study such that your OnStableStudy callback can easily make the difference between the original and the modified study.

Note that, in the OnStableStudy, you can also loop over every instance and modify them one by one.
However, lua callbacks are “blocking” Orthanc so its usually recommended to make them “short”.

I’m basing the correct patientname/id on the stationname, but unfortunately there are some datasets (secondary captures for example) which do not have such a field. Therefore, I am unable to use the OnStoredInstance-way.

Would my OnStablePatient approach work? And what happens when a patient is edited, which contains multiple studies? Will all those studies be duplicated as well? Because that would mean a bigger hard drive probably?

Indeed, the problem with the OnStablePatient approach is that it will duplicate all existing studies each time you modify the patient. So it will fill your storage.

Actually, in the current Orthanc version, you’re indeed not able to modify the PatientID when modifying a study. So it currently prevents you to work with OnStableStudy too… Note that we can fix that limitation but you would have to wait for the next release (unless you’re ready to work with a mainline version).

I can suggest 2 workarounds:

  1. Setup with 2 orthancs:
  • Orthanc A

  • receives the data from your modalities,

  • modifies the data in the OnStablePatient,

  • forwards the data (original and/or modified) to Orthanc B

  • deletes the patient

  • Orthanc B is your long term storage. A is supposed to be empty most of the time.

  1. Modify instance per instance in the OnStableStudy. This will probably “lock” orthanc for a few seconds but that might still be good enough

I added a OnStablePatient script, because in my use case unedited patients will contain just 1 study normally (maybe 2). So doubling that wont matter. However I was wondering, what happens to the ID’s.

First a script changes the patientId of a study, and thus the study is copied with a new ID and the old one is deleted.
Then, when the patient is stable (a second study might have joined), the patientID and patientName of the patient are changed, resulting in a new copied patient and the old one is deleted. Are the studies belonging to that patient then renamed again or not?

So make my question clear, is it A or B?

Option 1:
patientA + studyA → patientA + studyB then
patientA + studyB → patientB + StudyB

or Option 2:

patientA +studyA → patientA + studyB then
patientA + studyB → patientB + StudyC

If it’s option 2, I should delete studyB…

Hi Jaap,

Sorry, I think I’m lost !

A few things:

  • if you modify at patient level, it will create a new patient and new studies for all the studies attached to the original patient (and keep the original patient and studies).
  • if you modify at study level, it will just create a new study in the same patient (since right now, it’s not possible to modify PatientID at study level) and keep the original study.

If, in the future, we do support modifying PatientID at study level:

  • if you modify at study level, it would create a new patient and attach to it the newly modified study (and keep the original patient with all its studies).

Don’t hesitate to play with the API as well with only a few patient/studies, it might make things clearer.

If you feel the need for Orthanc to support PatientID modification at study level, just tell us and we’ll try to implement it.

Best regards,

Alain.

Hi Alain,

your answer is crystal clear. I solved my problem, by running a second instance of orthanc with a different configuration. The Orthancprocess, changes the different fields and then sends the patient onwards. Seems to work like a charm. One thing is a mystery though. Where are the log files of this second instances? A standard install logs to /var/log/orthanc/ (I’m using Ubunut 18.04), but I don’t know how to view the log of the second instance.

Hi Jaap!

As for the log files’ location, it depends on how Orthanc was started, its command line parameters. If no parameters are passed, it logs to the standard output, which might be suboptimal.

You might want to revise the second instance’s startup routine (scripts, systemd configuration, etc).

HTH,
Luiz

Hi Luiz,

I daemonized, my second Orthanc with systemd (https://book.orthanc-server.com/faq/debian-daemon.html). Can I state the location for log files there? I not very familiar with services.

Hi, Jaap!

I can’t quite look at it right now but I believe the parameter is “–log-file=[…]” (minus the quotes). You can add it in the ExecStart variable of the systemd service file.

HTH,
Luiz