1. Overview

OpenVPMS currently has several approaches for defining security permissions, depending on the part of the application where they are used. Permissions may be set by assigning:

1. roles to users.

These roles specify authorities to create, save and remove archetypes.

2. user type classifications to users.

In 1.8, the only recognised user types are Administrator and Clinician.

The Administrator type enables:

• access to the Administration workspaces
• customer and patient merging
• account checks
• product edit/delete/copy

The Clinician type identifies the user as a clinician, in order to restrict entry to clinician fields.

3. by assigning a user level to users

This is used to restrict the reports that may be run by users.

This project will:

1. unify roles and user type classifications, so that all permissions are managed by assigning roles to users

This will require the creation of new authority types that may be assigned to roles.

2. create workspace authorities; a workspace will only be available if the user has the appropriate authority
3. only enable New, Edit, and Delete buttons if the user has the appropriate archetype authority
4. when listing archetypes for New, only list those that a user has authorities to create
5. assign authorities to workspace operations; an operation will only be available if the user has the appropriate authority.
6. rationalise archetype authorities; the authorities to create and save are essentially the same - it makes no sense to have a create authority and no save authority
7. enhance error messages so that it is obvious why an operation has failed when a user doesn't have authority
8. create a default set of authorities for new installations
9. migrate existing data to the new format
10. change the way temporary documents are managed, so users aren't required to have authorities to remove documents
11. remove the Administrator user type. Administrator permissions will be handled via authorities

2. Authorities

2.1 Archetype authority

Currently, there exists one authority type 'security.archetypeAuthority'.

This determines what archetypes can be created, saved and removed.

This will be changed to only determine what archetypes can be created and removed.

It will not be used to determine if a user can retrieve/view particular objects. E.g. it will not be possible to use archetype authorities to prevent a user from viewing unit prices associated with a product, or querying

2.2 Workspace Authority

A new 'security.workspaceAuthority' will be created that determines the workspaces a user can access.

2.3 Workspace Action Authority

A new 'security.workspaceActionAuthority' will be created that determines the actions a user can perform in a workspace, and the archetypes that these actions may be performed on.

These correspond to the buttons that will be displayed in each workspace.

The archetype can be used to limit which archetypes may be operated on by an action. E.g., to prevent users from creating Investigations and Medications from within Patient - Medical Records, the following could be defined:

i.e, allow all patient history archetypes to be created, except medications and investigations.

2.4 Authority Precedence

If a user has two authorities that intersect, the most specific one applies. E.g, given:

the authority "Medical Record 2" is used as it is more specific than "Medical Record 1".

3. Default Authorities

3.1 Archetype Authority

The existing Archetype authorities will be used.

3.2 Workspace Authority

The following Workspace authorities will be defined:

3.3 Workspace Action Authority

The following Workpace Action authorities will be defined:
 

NOTES:

• patient.history new/edit/delete/print authorities apply to both Patient - Medical Records and Patient - Problems
• the default patient.history new authority excludes act.patientMedication and act.patientInvestigation as these are not invoiced
• the product.information viewpricinggroup authority is used to change the pricing group when querying products. When enabled, it allows users to see product prices at other practice locations when Pricing Groups are in use.

4. Default Roles

The following roles will be defined:

4.1 Administrator Role

The administrator role gives a user access to all aspects of OpenVPMS.

4.2 Base Role

This role defines archetype authorities common to a number of roles.

4.3 Clinician Role

This role should be assigned to clinicians, in conjunction with the Base Role.

4.4 Reception Role

This role should be assigned to receptionists, in conjunction with the Base Role.

4.5 Product Administrator Role

The product adminstrator role can be used to administer products and batches.

4.6 Stock Administrator Role

The stock adminstrator role can be used to administer suppliers and stock and perform orders and deliveries.

4.7 Back Office Administrator Role

This role enables statement and reminder generation, reporting and till operations.

5. Document Authorities

In order to download PDF documents generated via reports, all users must have new and delete Archetype authorities for the document.other archetype which is currently used to store all documents.

A new "document.temporary" document archetype will be created for this purpose, and all users will be granted authorities to create and delete these.

This will enable delete authorities for document.other to be removed from users who shouldn't be able to delete documents, but should be able to print them.

6. Data Migration

6.1 granted_authorities table

This change will require structural changes to the granted_authorities table:

• 'service_name' column is dropped
• 'archetype' column is renamed to 'authority'
• 'method' column is renamed to 'action'

6.2 Archetype authorities

All archetype authorities with 'save' action will be removed.

6.3 Document templates

The entity.documentTemplate acts need to be updated to link to the appropriate security.reportAuthority authorities.

6.4 Administrators

Users with an ADMINISTRATOR lookup.userType will be assigned the default Administrator role.

The ADMINISTRATOR lookup.userType will be deactivated.

7. Exclusions

This project will not address:

• report authorities