Role based access for observation forms in Clinical module

[sushmit (Sushmit Pant)]

Hi @all,

The current functionality of Bahmni does not allow users to access forms based on their user roles as per the assigned privileges

Requirement:

Users should be able to access forms based on their user roles as per the assigned privileges

Flow:

Let us say there are 5 observation forms in the Clinical module and its forms are F1, F2, F3, F4, and F5 and there are 2 users A and B.

Our requirement is to have different access for different users for the Clinical module at the form level.

User A must have access to only F1, F2, and F3.

User B must have access to forms F3, F4 and F5.

Scenarios to consider:

• To have the ability to add new forms having different user access for them in regards to future requirements.
• To make this feature a configuration effort for easy maintenance of the product.

Proposed Solution:

Creating a feature - Role-based access for observation forms in Clinical module.

Feature:

• While creating an observation form the implementers should be able to provide access of the observation form to selected roles.
• There shall be three levels of access for the users to access the observation form: No access, Read-only, Write.
  • No access level does not allow the unauthorized users to read the information on the patient dashboard or view the observation form on the Consultation tab of the Clinical module.
  • Read-only level of access allows the user to see the observation form under the Forms section in the patient dashboard but the user shall not see the form in the Consultation tab of the Clinical module. The user should not have permission to make any changes in the form.
  • Write level of access allows the user to see the observation form in the patient dashboard as well as in the Consultation tab. The user can also make changes in the observation form.

Satvix is planning to partially develop this feature. The scope is mentioned below.

Scope

• While creating an observation form the implementers should be able to provide access of the observation form to selected roles.

Out of Scope

• There shall be three levels of access for the users to access the observation form: No access, Read-only, Write.
  • No access level does not allow the unauthorized users to read the information on the patient dashboard or view the observation form on the Consultation tab of the Clinical module.
  • Read-only level of access allows the user to see the observation form under the Forms section in the patient dashboard but the user shall not see the form in the Consultation tab of the Clinical module. The user should not have permission to make any changes in the form.
  • Write level of access allows the user to see the observation form in the patient dashboard as well as in the Consultation tab. The user can also make changes in the observation form.

[angshuonline (Angshuman Sarkar)]

Please bring this up in the next PAT call. FYI, this is slotted for 0.93. Check BAH-790

attn: @jinal @snehabagri

[jinal (Jinal Sanghavi)]

Hello, this was a functionality that our clients are interested in as well. We can get on a call to discuss your plans further. Some of the items we would need to think about:

1. Privileges to view and edit the form in the display controls
2. Permission to view selective forms in consultation
3. Permission to edit selective forms from consultation
4. Permissions to “add new” forms
5. Extending roles and permissions for Forms 2.0

[sushmit (Sushmit Pant)]

Thanks for the update.

[mksrom (Romain Buisson)]

@sushmit I think this use case would apply to Data Filter module to use as the backend. @mksd, could you invite @sushmit to the demo tomorrow?

[gurkiran (Gurkiran Gill)]

Hi @sushmit

We have followed this approach for one of our clients.

• We created 2 provider attributes (Say P1 and P2) to give access to the 2 types of user roles of the same module that is Clinical in respect to Observation forms.
  • Admin > Manage provider attributes type > Add provider attribute type > name the provider attribute with the data type as Boolean > Save
  • We have used provider attribute because this results in writing less code and it is easy to differentiate different providers.
  • For our purpose we created 2 provider attributes, but for making it for a generic use, we can create multiple according to the providers accessing the observation forms.
  • This was also in respect to the view and edit access of each provider on the display control on the patient dashboard.

Giving the access P1 or P2 to the selected provider “Suhas Kumar”

• For linking the forms with each provider attribute, we have used key value pairs.
• We created 2 key value pairs (as we had 2 types of provider attributes) created in the app.json file of Clinical module. Here we added the configuration for giving or removing access to the forms by entering their fully specified names under these key value pairs.

User/Provider role with access to only Form 1, Form 2, Form 3, Form 4 and Form 5

User/Provider role with access to only Form 7, Form 2, Form 6, Form 4 and Form 5

[gurkiran (Gurkiran Gill)]

@angshuonline as advised, I discussed the approach with @snehabagri.

According to Sneha, the approach for forms 2.0 is still at the idea stage and there is no timeline decided yet for its development. The same approach that we have followed (as mentioned in the above post) can be followed for forms 2.0 as well. So we have raised the PR ( https://github.com/Bahmni/default-config/pull/38/files ).

The same approach can also be followed for role-based access control for display controls on the patient dashboard. But this is an out of scope item for us as of now.

[angshuonline (Angshuman Sarkar)]

@gurkiran I am not convinced of the solution, and think even the community wasn’t (from the last call). reasons

• This is not a generic solution for different types of forms (Forms 1 and Forms2)
• Even for Forms 1.0, it should not be done that way - if at all, the custom attribute should specify the role (rather than specifying providers). As the number of providers keep on increasing, this is not sustainable or maintainable. For display controls, again we wouldn’t want to make it “provider” specific, rather specify “role/privilege”. So, I definitely don’t agree with the solution.
• The reason, we wanted the same approach as in Forms2, was that it will be a single configuration place for both approaches and possibly extended for reporting as well)

[akhilmalhotra1 (Akhil Malhotra)]

@angshuonline Consider a scenario where the requirement is to restrict a Neurologist’s access to forms related to Gynaecology. In the current Bahmni functionality, separate roles are not defined for different specialities. Both of the above mentioned specialists are given a generic role of “Doctor”. In the approach followed by @gurkiran, if the form is not linked to any provider attributes, it is visible to all types of providers that have access to clinical app/consultation. The need to create a provider attribute arises only if the access to a form needs to be restricted.

In the approach you suggested below,

the custom attribute should specify the role (rather than specifying providers). As the number of providers keep on increasing, this is not sustainable or maintainable. For display controls, again we wouldn’t want to make it “provider” specific, rather specify “role/privilege”.

a separate role will need to be created for each speciality.

[angshuonline (Angshuman Sarkar)]

I am afraid I am not convinced.

1. Nowhere in Bahmni/OpenMRS are access directly attributed to a provider/user. ACLs are always based on privileges associated (done through roles assignment for the user)
2. I would argue for maintenance and manageability

• app configurations are not meant to be changeable for specific “users”. app configs are supposed to be generic and if at all, done through privileges - the model that we have followed everywhere.
• if there are 20 gynae docs (and similar in other specialities) - the manageability of editing the configuration by someone who knows the provider id/name and versed with editing and format of the configuration files becomes a challenge. If a doctor now needs access to a specific form, you will need someone with access to the server to access, edit the file.
• on the other side, if you do this via role/privilege for a user, an admin can assign that role - in a generic manner - for users who need such form access. your app config never changes. no server access, no edit of file is required.
• you don’t need to assign always a “doctor” role. I would assume that you create a role “gynaecology-specific-form” and assign that to a doctor/clinician on need basis. or even create a broad role “gynaecology doctor” role, that also inherits the “doctor” role.
• since the association is also there through the OpenMRS ACL model, if anyone needs server side validation, restrictions (or say in combination of location like some projects are doing with DataFilter), this can be done easily (albeit with little modification on Data filter - since its defined as attribute for the concept).

To me, these are better ways of managing access.

[krishnanspace (Krishnan Menon)]

Hey @angshuonline , can we discuss this over the next PAT call?

[angshuonline (Angshuman Sarkar)]

Sure. Please bring it up for discussion.

[snehabagri]

@gurkiran,

I think we also discussed the point that this approach is not extensible and suitable for further enhancements for reports and other areas. Do you have any further points on how you want to make it extensible?

[eddyprasetyo]

I also need this type of feature implemented.

This is my first bahmni project on small clinic, that only have two type of provider, GP and dentist. They need different obs form, and whenever possible, the provider only able to use designed form for them (able to create/edit), but others can only read it (e.g nurse,pharmacyst).

Anyway out of topic what is PAT call? what is it stand for? It’s look like some sort of skype meeting right?

[mksd (Dimitri R)]

Very quick input based on an extremely quick read.

I think we should stick to the same kind of design as to what’s done in the Ref App. The “links” to the the forms are in fact privilege-controlled extensions.

A gynecology link-extension would be restricted to a "Access: Gynecology" privilege. And one would add this privilege to all clinical roles that require access to gynecology areas of Bahmni.

[dmukungi (David Mukungi)]

Here is an approach I am proposing for the Form 2.0 Role Based Access Levels.

Definations of the Access levels i.e (“No access”, “Read Only”, “Write” ) have already been defined by @sushmit in the thread above.

Approach:

To have forms tied to privileges that we will use to validate to either “Read only” or “Write only”.

Steps.

The system administrator will be required to create a privilege in the Openmrs back end that will be tied to a specific form as either “Read Only ” or “Write Only”.

Assigning the Access Control to Forms.

(Done in the Form Builder Interface).

The access level of a form will be defined during the form creation process. The privileges can also be added or modified during the process of editing the form.

The feature will give provision to search for a privilege and then append check-boxes i.e (“Write”, “Read”) in a tabular format adjacent to the privilege. (The search field will automatically populate privileges based on the search).

The system administrator can then proceed to check against the privilege the desired access level.

Note: Forms not assigned to either “read” or “write” privilege will not be displayed to system users by default. They will only be accessible to users with administrator roles who can then assign the forms to a group of users.

Consider the case below:

E.g: Assigning Access level To a “TB Form”.

Step 1: Create three Access levels in the back end.

• Read and Write TB Form.

• Write TB Form Only.

• Read TB Form Only.

Step 2: Assign the Roles in the Form Builder view Page.

The system administrator will then check the desired access level against the searched privilege as indicated in the screenshot below:

Note: A single privilege can be assigned to multiple forms.

[michaelbontyes]

Hi all,

Following-up on discussions during the latest PAT calls about the level of granularity and possibly, restrict access at a concept level, I would like your opinion on the approach below:

Context

• For security compliancy reasons, it would be necessary to restrict access at a level concept;
• The first difficulty is that some concepts are generic and used across multiple forms;
• The second difficulty is that asking end-users/admins to grant access to concepts is really granular, work intensive and less sustainable in case of form/concept changes;
• Also, a sustainable feature should ideally be as transparent/intuitive as possible for end-users/admins, rather than adding up work and maintenance.

Define Permissions
Like suggested in @dmukungi’s latest post, a system administrator would define the access levels to a specific form for a user through a permission UI in the Implementer Interface of Bahmni.
Vice versa, it would be possible to view the list of users assigned to a form.

Filling-out a form
Any user with a write permission granted for a specific form beforehand will be allowed to fill it out. The observations would be saved along with the form name (existing column “form_namespace_and_path” for example).

Secure by design
By default, it’s not possible to read (or write) an obs if permissions to the parent forms are not granted.

Restriction/access logic
When trying to retrieve observations (in a form, display control, report, export, etc.), the query would verify that the current user has access to the form name associated with each concept record. It means that restrictions would be based on obs + form names, rather than concepts.

Diagram example

@dirkg

[mksd (Dimitri R)]

Hi @michaelbontyes,

When I read this my feeling is that a number of things are conflated.

If your bottom line is that you want to restrict data access to users. In other words if you need certain obs to become inaccessible for certain users, then IMHO the simplest way to achieve this is to stick to Core’s data model.

Obs pertain to encounters, and access control to encounters is natively supported in Core and can be reinforced with low-level data ex-filtering. Let me be clear that I say this because of my understanding of your need as quoted here:

@michaelbontyes

When trying to retrieve observations (in a form, display control, report, export, etc.)

If the above could be a viable approach for your needs, then managing access to forms just becomes a mere UI thing (as it should be btw) on top of the above.

Now I know that you operate within Bahmni and this will make a number of things more or less difficult depending on how strong your data protection requirements actually are.

Happy to take the pure data filtering conversation elsewhere if @dirkg and you find that this could be the way forward.

[angshuonline (Angshuman Sarkar)]

@michaelbontyes Can I request you create a different thread for this? I think this would sidetrack the topic it was created for. IMHO, what you are asking for requires a much longer and wider discussion. I would like to comment on many things that you and Dimitri wrote (possibilities, impossibilities etc) - but lets do this on a different thread.

[buvaneswariarun]

This is regarding program-based access to forms. There is a requirement to restrict forms to programs, more specifically to the workflow state the program belongs to. This is taken up as a part of the above-mentioned feature [form based access to forms BAH-790] and hence is discussed here.

There are two approches though of,

1. In the form_privilege table [to-be introduced as a part of the feature], a separate column needs to be introduced, which captures the program_workflow_state_id , thereby restricting the forms only to that particular program workflow.
2. Since program workflow state is also a concept, we can add the form names as attributes to the workflow state and can show, only those forms when the program is created/edited.

Would like to discuss and evaluate both the approaches, pros/cons of the same and come up with a most generalized solution.