This describes the algorithm that determines, whether a user is allowed to read a given record (= form instance):

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

  • Employee user:

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

    • When the user has read permission, read access depends on the value of AccessModeRead:

      • All: all users have access - so read 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, read access is granted.

  • Patient user:

    • Read access is granted iff PatientAccessMode=Read or PatientAccessMode=Write.

• Finally, if computation Read is defined, this computation is evaluated. if it returns false, access is denied.

If read access is granted, the record is shown as a hyperlink in the Patient Record Tree.

If read access is denied, the user interface in the record tree may be configured in two ways depending on the value of AccessModeDenied:

• Hide: the record is not shown in the Patient Record Tree.

• Hide: the record is shown as a "hint" (grayed and inactive node) in the Patient Record Tree.

Note
The properties AccessModeRead, AccessModeDenied, and PatientAccessMode may have the values Inherit. This means that the "effective" values are "inherited" from the parent table.

Note
Even if read access is granted, the corresponding record may not be shown in the Patient Record Tree, This would happen if computation Visible is defined and returns false. In other words: that a record may be read does not necessarily mean that it is visible in the Patient Record Tree. The data may be visible "embedded" in a parent form, e.g. using the SubForm mechanism.