A thought on restricting access to patient data using restrict by role or restrict by encounter:
Whereas we (computer scientists) tend to view privacy in absolute terms, health care providers do not necessarily view things the same way. There will always be legitimate reasons why a doctor or nurse may need temporary access to another doctor/nurse's patient's data. Its important in our well-meaning scheming that we don't lock out these legitimate requests. You security gurus will know better, but there is an approach called Optimistic Access Control which works on the assumption that the intent of the user is generally good. Whatever scheme is in place, the system should provide a feature to "break the glass" to gain access to data she might not otherwise have access to. The important thing about OAC is that (i) the user is warned that she is attempting to override her permissions and (ii) that there is a clear audit trail and alerting mechanism. I'm not sure how relevant this is to the upcoming sprint, but if there is discussion around schemes over and above role based access, I think it might be useful to consider this approach. Bob On 14 May 2012 15:14, Darius Jazayeri <[email protected]> wrote: > Daniel is the mentor for that project, and Goutham is the student, so they > should comment on whether the project will cover viewing/editing forms. > > -Darius > > > On Mon, May 14, 2012 at 5:21 AM, James Arbaugh <[email protected]> > wrote: >> >> Hi Darius, >> >> >> >> Thanks for setting me straight. I confused the “Restrict By Role Module” >> with the “Restrict By Encounter Type Module” by the HISP India group which >> would address the needs of TRUNK-1640. We do NOT need the “Restrict By Role >> Module”. >> >> >> >> I recently added TRUNK-1640 as “Extra Credit” on the Filtering Forms on >> Dashboard Design Page because it’s related. The GSoC main project is to >> limit which forms appear in the list of forms that can be filled out. >> TRUNK-1640 is to limit which role is required for given encounter types to >> be viewed/edited. >> https://wiki.openmrs.org/display/docs/Jembi+Html+Form+Entry+Module >> >> Roles Based Form Display >> >> On the form designer, roles can be associated with forms. Roles associated >> with a form can either be associated as a "View" role or an "Edit" role (or >> the equivalent "Both" role). On the patient dashboard, if there are roles >> associated with a form, then the currently authenticated user must have the >> appropriate roles to view and/or edit a form. >> >> Can we make TRUNK-1640 an official requirement for the GSoC project? Or >> is that something that can be addressed through the Roles and Privileges >> Sprint? >> >> >> >> Thanks, >> >> James >> >> >> >> From: [email protected] [mailto:[email protected]] On Behalf >> Of Darius Jazayeri >> >> >> Sent: Thursday, May 10, 2012 7:19 PM >> To: [email protected] >> Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint >> >> >> >> About filtering things by roles... >> >> >> >> Filtering forms by roles and patient characteristics is a GSoC project >> this year (https://wiki.openmrs.org/x/OIW5AQ, student = Goutham Vasireddi) >> so we will not be working on that during the sprint. (But yes, we know it's >> highly voted and much awaited!) >> >> >> >> The Restrict By Role module allows you to use Cohort Builder queries to >> limit the patients a given Role can see. As far as I know, this is the only >> published module that lets you limit the patients that particular users are >> allowed to see, although that's a frequently-requested feature. This was a >> very early module (from 2007), so the code is mediocre, it probably slows >> down your patient searches a lot, and the API has changed since then so it >> probably misses a lot of restrictions. >> >> >> >> [The reason there aren't any other published modules doing this is that >> it's basically impossible to solve the problem generically in a performant >> way.) >> >> >> >> So the question is: are there any implementers out there who would like to >> see us spend some developer cycles doing a modernized version of Restrict By >> Role? It would: >> >> let you restrict the patients that particular users/roles can see based on >> reporting module cohort queries (instead of cohort builder) >> cache query results so it slows things down less than the current module >> does >> >> If there's interest, we can spend some cycles on this during the sprint. >> (And if not, not.) >> >> >> >> -Darius >> >> >> >> On Thu, May 10, 2012 at 3:22 PM, James Arbaugh <[email protected]> >> wrote: >> >> Greetings all! >> >> >> >> One of our highest priorities should be the RestrictByRole module >> capability; the ability to specify which user roles can view/edit which >> encounters. This is important to many based on the number of people that >> have voted (6) for the “Add roles-based form display feature ticket”… >> >> https://tickets.openmrs.org/browse/TRUNK-1640 >> >> …which includes the ability to “filter form viewing and editing based on >> roles”. >> >> >> >> This is also something that comes up frequently on the mailing list and on >> OpenMRS Answers. >> >> >> https://answers.openmrs.org/questions/585/a-way-to-set-role-privileges-to-specific-form-entry-forms >> >> >> >> +1 on improving documentation >> >> >> >> Thanks, >> >> James >> >> >> >> From: [email protected] [mailto:[email protected]] On Behalf >> Of Daniel Kayiwa >> Sent: Thursday, May 10, 2012 5:22 PM >> To: [email protected] >> Subject: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint >> >> >> >> Greetings to you all!!! >> >> >> >> We are soon going to have a sprint on roles and privileges, during which >> we are thinking of dealing with the following topics: >> >> >> >> 1) Make it easy for an admin to see what privileges are needed to perform >> a sequence of actions. >> >> 2) Improve the page a user sees when they fail a privilege check. >> >> 3) Improve documentation on how to use privileges/roles and avoid >> pitfalls. >> >> 4) Implement Organizational Role as designed in this wiki page: >> https://wiki.openmrs.org/display/docs/Organizational+Roles >> >> >> >> Do you feel the above topics address what the community needs, as far as >> roles and privileges are concerned? >> >> Does anyone want a modernized version of the Restrict By Role module? >> >> Do you have anything to say about the Organizational Role API design? >> >> >> >> All questions, comments and suggestions are very welcome!!! >> >> >> >> Daniel Kayiwa >> >> On Behalf of the OpenMRS Community >> >> >> >> ________________________________ >> >> Click here to unsubscribe from OpenMRS Implementers' mailing list >> >> >> >> ________________________________ >> >> Click here to unsubscribe from OpenMRS Implementers' mailing list >> >> ________________________________ >> Click here to unsubscribe from OpenMRS Implementers' mailing list > > > ________________________________ > Click here to unsubscribe from OpenMRS Implementers' mailing list _________________________________________ To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-implement-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l]
