Home › Forums › Users › General User's Discussion ›

Re: Access Levels on OpenVPMS

Submitted by Guest on Wed, 23/03/2011 - 12:16
in

Message from Damien Solley dsolley@gmail.com

I agree we need some good defaults for authorities. 

I'm thinking something like: 
* Administrator - unrestricted. 
* Clinician - unchanged, but cannot edit or create other accounts. Able to reverse invoices and payments? 
* Office admin - may be necessary in larger clinics? 
* Nurse - Able to attach documents to histories, create invoices, add to invoices. Cannot edit histories or delete invoice items. 
* Receptionist - very limited permissions, primarily related to creating appointments and invoices etc. Cannot delete items from invoices, edit other accounts, reverse invoices or payments, edit histories. 

Of course the defaults shouldn't be too comprehensive - but should allow modification to suit individual practice preferences. This would need online documentation for implementors. 

On that topic, it would be nice to improve the online documentation for OpenVPMS. We are using an on-site wiki (Dokuwiki) for our notes, perhaps this is something that we can add to the main website? Then registered users can help keep documentation up-to-date.

Damien


On Wed, Mar 23, 2011 at 8:53 AM, OpenVPMS <admin@openvpms.org> wrote:

Hi Sandra,



Sorry missed this one.



The Categories that you mention are very broad groupings that currently only

dictate two things.



Administrtaor - Access to Administration menu and editing products.



Clinician - User is selectable as a clinician in history, invoicing etc.



The permissions on these categories are hard coded into the application so

cannot be modified at the site level.



The way to modify individual users ability to do certain tasks is through

roles and authorities.  These allow you to define which things specific

users can create, edit and delete. Authorities allow you to define the

specific bits of information you can manage and roles group these into areas

that you can assign to users.  A user can then be assigned to multiple roles

i.e receptionist, stock manager etc



Now it was always the intention to build up a set of authorities and roles

that could be easily loaded into OpenVPMs and then used/modified by the

practice to suit their purposes.  This hasn't happened yet mainly due to

finding the time and/or resources to develop and test these.  Currently the

only role available is Administration which allows everyone to do anything.

 The only thing that restricts this is the Categories defined above.



I think we may need to create a development project to get this done.  It

doesn't require any actual development work but just putting together a data

file of authorities and roles and testing these. I would be happy to develop

the initial data file based on input from you guys about the types of roles

and restrictions you want.  I would ask the community for some help to test

these to make sure they dont stop some important functions.  This could be

done in your training/demo systems so it would have minimal impact on your

practice.



Thoughts ?



Cheers



Tony







_______________________________________________

OpenVPMS User Mailing List

users@lists.openvpms.org

To unsubscribe or change your subscription visit:

http://lists.openvpms.org/listinfo/users

Posts from this mailing list can be viewed online and replied to in the OpenVPMS User's forum- http://tinyurl.com/openvfu


‹ Fwd: Viewing RTF files Sold products are not taken from inventory ›

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Access Levels on OpenVPMS

Submitted by tony on Wed, 30/03/2011 - 12:14.

Thanks Damien,

Currently if you don't give someone a role they can view everything (except anything in the administration menu unless they have the administrtaor category assigned) but cannot add, edit or delete anything.  

The administrator Role allows anyone to add, edit or delete anything.

Between these we can create mutliple other roles but these need to be designed carefully as it is not as simple as just adding say an authority to create or save customers but also the other types of archetypes associated with customers i.e contacts, relationships etc.  A authority can be added for specific archetypes or groups of archetypes using wildacrds ie. contact.* means you can create or edit or delete any new contact.

Firstly I will try and get a list of standard authorities together and then we can work on grouping these into the roles you mentioned or something similiar.  When discussing these roles we need to be in an authority mindset i.e.

Receptionist Role:

  • Create and edit customers (including contacts, identities, discounts, patient relationships)
  • Delete contacts
  • create and edit patients
  • create , edit and delete appointments
  • Create and edit Invoices (except finalised of course which is programatically restricted)
  • create and edit payments(as above)
  • Create and edit patient reminders
  • Create and edit customer alerts
  • etc

As far as documentation is concerned I believe the web site supports document authoring and management similiar to a wiki but I think Matt Young the web site administrator can detail that a bit more and maybe work on making it easier to contrubute content to the site.

Cheers

Tony

Syndicate content