This is how the system determines, whether the user is allowed to create (patient data) records:

• 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 create records, then obviously create access is denied, and the below steps are skipped.

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

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

      • All other values: Check on the organization depends on the table's relation to organizational unit, configured in The Structure File on StructureElement Reference.

        • Default scenario (each table has one relation to OrgUnit.

          • OrgUnitRelation=None

            Records do not have any relation to organizational nut, so the organization check is omitted. I.e. all users have access to create records.

            OrgUnitRelation=Select

            This denotes an "encounter" (that is: an organizational unit must be selected when creating a record). The system computes a set of possible data owners (= all org. units, that have been marked as "data owner" for the current table/form). This set is compared with the set of org.units associated with the user. If the intersection between these sets is empty, access to create record is denied.

            OrgUnitRelation=Inherit

            This denotes a child form to an "encounter" (that is: the form to be created is a child form below previously created encounter, that per definition defines a data owner (an organizational unit).

            When OrgUnitConfigure=false, the set of legal data owners for the new record is determined by the encounter.

            When OrgUnitConfigure=true, the set of legal data owners for the new record is the intersection of the data owners defined by the type (=table) of the encounter and the data owners configured for the subform. I.e. it is only possible to narrow the set of legal data owners.

            Either way (as for the encounter), the set of legal data owners is compared with the set of org.units associated with the user. If the intersection between these sets is empty, access to create record is denied.

        • "External references" (each table may have 0-N relations to OrgUnit):

          • For each relation, it is checked if the relation is inherited from parent table). If relation is inherited, the OrgUnit value to store is this relation is taken from parent record, and further checking on OrgUnit is skipped.

            If relation is NOT inherited, the record to be created is an "encounter" (= the topmost level in the hierarchy, where user must select relation to OrgUnit), and checking proceeds.

            For each relation, a set of possible OrgUnit objects (e.g. data owners) is computed and compared with the user's relations to OrgUnits. The intersection of these two sets is computed.

            If a relation is required, and the computed intersection is empty, then creation of record is denied (no OrgUnit to select between).

  • Patient user:

    • Write access is granted iff PatientAccessMode=Write.

• If any ancestor record is closed, access to create new child 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 the table (defining the type of the record to create) is marked as closable, the system checks whether there already exists an open record in the given context. This check depends on the value of the field SingleOpenMode.

  SingleOpenMode=None

  No check for existing closed records, i.e. it is allowed to have multiple open records.

  SingleOpenMode=All

  The system checks all existing records of the same type (table / form) on the patient. If an open record (i.e. with StatusClosed=false) exists, access to create a new record is denied.

  SingleOpenMode=CheckDataOwner

  The system checks all existing records of the same type (table / form) having the same data owner (organization "owning" the record) as the new record. If an open record (i.e. with StatusClosed=false) exists with the same data owner, access to create a new record is denied on this data owner. But creating new record may be allowed with different data owners.

• Finally, if create access has not been denied by the above steps, and computation Create is defined, this computation is evaluated. This computation is specified by a TOPICA Basic expression. If the evaluated value is false, access to create new record is denied.

  The configurator may use this computation to further restrict the access to create a new record. Note that it is not possible to grant access to create a record, if this access has been denied by one of the mechanisms described above.

When the logged in user is allowed to create a record, the Patient Record Tree displays a create-command (as a hyperlink),

When create access is denied, the AccessModeDenied value controls what is displayed in the tree:

• Hide: create command is hidden (invisible).

• Hint: The create command is shown as an inactive "hint" (NOT a hyperlink).

Note
The properties AccessModeWrite, 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 "create link" may not be shown in the Patient Record Tree, This would happen if computation Visible is defined and returns false.