Click or drag to resize
Security Record Delete

[This is preliminary documentation and is subject to change.]

This topic describes the algorithm that determines, whether the user may update a (patient data) record (= form instance).

Access to delete a record is computed almost in the same way access to update a record.

The only way to delete a patient data record from the user interface, is to open it (from the Patient Record Tree) and then click the "Delete" button in the form. I.e. in order to delete a record, you must read it first.

This implies, that if the user does not have access to read a record, (s)he cannot delete the record. Check Security Record Read for algorithm for read access.

  • First steps in the "allow delete" algorithm depend on whether the logged in user is an employee or a patient:

    • Employee user:

      • If the user does not have permission to delete records, then obviously delete access is denied, and the below steps are skipped.

      • When the user has delete permission, delete access depends on the value of AccessModeWrite:

        • All: all users have access - so delete access is granted.

        • All other values: The organizational unit of the record is compared to the set of org.units associated with the user. If the record's data owner is in the set of org.units associated with the user, delete access is granted.

    • Patient user:

      • Delete access is granted iff PatientAccessMode=Write.

  • If the current record or any of its ancestor records is closed, access to delete the current record is denied, and the below steps are skipped.

    • Refer to Status Closed for details on how it is determined that a record is "closed".

  • If computation "Delete" is defined, this computation is evaluated. If it returns false, update access is denied.

  • Per default it is not allowed to delete a record, that has child / descendant records created (except child records created as a result of an ArrayTable element in the form, (implementing a 1:N relation inside the form).

    However, if computation "CascadeDelete" is defined, this computation is evaluated, and if it returns true, "cascade delete" access is granted. This has the effect, that pressing the "Delete" button will delete any descendant records (recursively), and finally delete the current record.

Access to delete record is NOT visible in the Patient Record Tree. I.e. it cannot be determined from the Patient Record Tree, whether the current user has delete access. If user has read access, but not delete access, records may be opened normally using the Patient Record Tree, but the "Delete" button in the form will be disabled.