Thanks for this, Bob. Well said. Auditing access (i.e., accountability) is the foundation, then restriction (with "glass-breaking" override when the computer is wrong) can help make it easiest for users to do the right thing, while holding them accountable if/when they do not.
-Burke On Mon, May 14, 2012 at 10:28 AM, Bob Jolliffe <[email protected]>wrote: > 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] > > _________________________________________ 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]
