dcm4chee-arc 5 Patients without studies are not d;eted from the pacsdb database

[leogrande]

dcm4chee-arc 5.17.0

My settings in UI:

Allow Delete Study permanently: REJECTED

Allow Delete Patient: WITHOUT_STUDIES

Delete Patient On Delete Last Sudy: True

Purge Instance Records: True

Purge Instance Records Delay: PT10M

Purge Instance Records Polling Interval: PT15M

In 'Rejection Note' :

Delete Rejected Instance Delay: PT5M

Delete Rejection Note Delay: PT5M

Rejected studies are deleted as expected but the patients without studies (num_studies=0) are still in the database.

Are they supposed to be deleted automatically (without polling interval and purge delay?)?

[vrinda nayak]

What is the Storage Duration configuration of your storage descriptor ?

Study records (and associated patient, if Delete Patient On Delete Last Sudy: True & num_studies=0) are deleted from database, if the storage duration is set to TEMPORARY

[leogrande]

This is a test setup.

The storage duration "PERMANENT"

PERMANENT retains patients without studies and TEMPORARY deletes them (tables 'patient', 'patient_id', 'person_name' ?) from the database (Delete Patient On Delete Last Sudy: True & num_studies=0)?

I have set 'Issuer Of Patient ID Format' : {00100010,hash}-{00100030}

Are those generated issuers for the deleted patients not deleted from the database (table 'issuer')?

I will try it to switch it to TEMPORARY  to test it.

Thank you.

[vrinda nayak]

- PERMANENT retains patients without studies and TEMPORARY deletes them (tables 'patient', 'patient_id', 'person_name' ?) from the database (Delete Patient On Delete Last Sudy: True & num_studies=0)?

Objects and records are deleted from filesystem for PERMANENT storages only if they are marked to be deleted (eg when object is rejected, it is marked to be deleted or same object is received with different MD5 sum, then previous object is marked to be deleted).

On CACHE storages, objects are deleted from filesystem based on configurations done on Storage Descriptor.

On TEMPORARY storages, objects are deleted from filesystem based on configurations done on Storage Descriptor and also records are deleted from database. (If Delete Patient On Delete Last Sudy: True & num_studies=0, patient and its corresponding patient_id and person_name records will also be deleted from database. Issuer records remain in database.)

- Are those generated issuers for the deleted patients not deleted from the database (table 'issuer')?

Issuers are never deleted from database when patient is deleted because the same issuer may be applicable also to other patients!

[leogrande]

In my case, I am using that issuer format (patient name hash - DOB) to help with not unique Patient IDs as per dcm4che recommendations (do not recall that issue number). And I hope that those issuers will not be used for other patients and it doesn't look that it is even possible, but who knows.Thank you.

[leogrande]

What really concerns me about these different storage duration types is that how easily you can lose all your precious data. Just one mistake and all data gone for good (unless you have (and you must have) the db and storage backup).

If you set your storage to TEMPORARY and set the Deleter Threshold your data is preserved. But if you mistakenly/accidentally deleted that Deleter Threshold, you've got this: "...If absent all studies are deleted from cache/temporary storage...". and from the database as well, even if the Retention Policy was set up.

There are no any pop-up alert/warning message. IMO, it shouldn't let the data to be erased without some additional confirmation steps to make sure that a user wants his data to be erased (like a disk formatting).

If the storage was initially set to PERMANENT and there were no any deleter threshold set up, switching to TEMPORARY will do the same.

If the storage is on S3 it doesn't have any estimation of the free storage so setting that deleter threshold doesn't make any sense.

[gunterze]

Guard storage against unintentional deletion on missing deleter threshold configuration #2052