Security Model

Vision security uses a hierarchical model to represent the individual modules within Vision. Think of this model as a tree (albeit, upside-down). The root of the tree is the module itself, for example, Consultation Manager. When we expand the root, we see other functions within the module. If these functions can also be expanded (ie refined into more detail), they are called branches - if they cannot, we call them leaves.

Groups and users added at the root have access to all parts of the tree. This is for convenience, so you do not have to define what parts of a module a group can or cannot access.

Groups added to branches or leaves have access granted by their position in the tree. The first level of branches from the root is the least secure, and the leaves are the highest. This is illustrated overleaf for Consultation Manager.

For example, if you expand Consultation Manager, you will see the group of Clinical Managers, who currently are allowed access to all functions within Consultation Manager. There is a further option of Read Only - this is the lowest category of security, someone who can look at Consultation Manager but not make any entries.

Once again, where you see , you can expand the list further.

The default situation, illustrated above with Consultation Manager, where the Clinical Managers group is in the immediate level beneath the Consultation Manager heading, gives all Clinical Managers all rights.

Visualise the tree being upside-down, the root being Consultation Manager.

The users or groups here have access to all of Consultation Manager, ie the root represents the least secure access. The leaves are the most secure access to the module.

A path traversing the tree from the root to a leaf moves through increasing access restriction, from the least secure at the first branch to the most secure at the leaf. Paths in the tree are set so that rights follow system logic.

For example, to delete data we must first lock the relevant patient record, so the Delete Data node is a child of the Lock Patient node.

Users added at the root node are given access to everything within the tree. This all rights permission granted at the node will be checked first. If a user or group is found here, then they are assumed to have all rights and checking stops.

If a user is not found at the root, checking begins at the first level of the tree. Groups/Users found here are assumed to have incremental rights.

Incremental rights grant permissions to all nodes between the node to which the group/user is added and the root, but a group/user is refused access to anything in its sub-tree. The permissions of a group/user are determined by the path that is traced between it and the root. Those permissions are not changed by any permissions that may be granted to other nodes along the path from its node to the route. Permissions only apply to the path from the node to the root; they do not include all other nodes on that level.

For example, a group/user added at the Lock Patient node would have access to Lock Patient and Consultation Manager, but not to other nodes.

A group/user added to Start Consultation would have access to Start Consultation, Lock Patient, and Consultation Manager, but not to Delete Data, Edit Data, Delete from Problem Group, which are on the same level but not on the path.