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

Support for quantity breaks will enable separate pricing for products, based on the quantity purchased.

This can be used to give customers a discount for buying multiple items.

At its simplest, quantity breaks involves setting a unit price that applies to a range of quantities e.g.:

In the above, quantities 1-9 are charged at $0.50, and 10-24 are charged at $0.40 and so on.

User Interface Changes

To support quantity breaks, product editing will be changed to:

• order unit prices based on date and increasing quantity
• prevent entry of unit prices that have identical quantities for a given date range
• require a unit price with a quantity of 1 for the current date

Charging and Estimates changes

During charging and estimates, product unit prices will be selected based on the charge/estimate date, and the product quantity.

Product Import/Export

The Product Import/Export support needs to be updated to:

• support importing multiple unit prices with different quantities
• export unit prices ordered on date and increasing quantity

Archetype Changes

The productPrice.unitPrice archetype has an unused quantity node that will be changed to:

• be mandatory
• default to 1

Data Migration

If a productPrice.unitPrice has an existing value for quantity, this will need to be set to 1.

Often users want to be able to control whether new patient visit charges are accumulated on an existing invoice or a new invoice is created for each visit.  This is particularly true in large animal clinics where they may want each visit to be a separate invoice but still want to maintain the individual invoices as In Progress until cross checked before being marked as Completed and billed at the end of the month.

This project involves adding an option to the practice location setup to specify if users will be prompted during check in and consulting to accumulate charges on an existing invoice or create a new one.

Currently customer and patient form templates have to be open office or word documents and are merged as part of the form generation process.

We need to support static non merged customer and patient form content such as pdf, tif etc