As a physician to see all the encounters is critical for the longitudinal knowledge of the patient's 'history'. That is, it is an event. What is meant by making it disabled? What is being disabled? The data should remain as entered/acquired. Terry Hannan Sent from my iPad
On 18/05/2012, at 9:17 PM, "Friedman, Roger (CDC/CGH/DGHA) (CTR)" <[email protected]> wrote: > Re persons without privileges not seeing encounters: What do you think is > better, that the encounter info appear on the dashboard but disabled > (greyed), or that it not appear at all? I can imagine a doctor using > somebody else's terminal and not seeing an encounter he knows exists and > losing faith in the system. > > From: [email protected] [mailto:[email protected]] On Behalf Of > James Arbaugh > Sent: Thursday, May 17, 2012 4:53 PM > To: [email protected] > Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint > > Hi All! > > I have commented on TRUNK-3361 and had a short call with Darius to explain > the use-case that we are trying to solve. It has more to do with requiring > permissions for viewing/editing encounters than it does to what users can > fill out a given form. So, after a form has already been filled out (which > we’ll called an encounter at that point and is shown under the > encounter/visit tab on the dashboard). Who has permissions to view it and/or > edit it? So for example, we need to limit the viewing/editing of Blood Bank > encounters to only users of the Blood Bank. And we need to limit the editing > of Lab encounters to only Lab Technicians, but they can be viewable by > doctors. And we need to limit the editing of surgery encounters by Surgery > data entry clerks and surgeons, but all doctors can view them. If a user > isn’t going to be able to view/edit the contents then it need not appear in > the list of encounters. > > The view and edit role and/or privileges could be implemented on the Edit > Encounter Type page rather than on the Edit Form page. The consideration of > doing it on the Edit Form page instead would be if someone needed to limit > viewing/editing of forms in the case of different forms that use the same > type of encounter. > > Thanks for your patience and willingness to help make this needed > functionality a reality. > > Thanks, > James > > From: [email protected] [mailto:[email protected]] On Behalf Of > Darius Jazayeri > Sent: Wednesday, May 16, 2012 7:09 PM > To: [email protected] > Subject: Re: [OPENMRS-IMPLEMENTERS] Roles and Privileges Sprint > > Hi Implementers and Devs, > > James has been pushing for TRUNK-1640 to be included in next week's sprint > (and I don't blame him--it has 6 votes!). But on today's design call, we > looked at the proposed solution in that ticket, and we're not comfortable > introducing it into the codebase with the given design. > > In particular, it wants to create a form_role table that links forms to the > roles that are allowed to enter/edit them. > > Instead, we have a counter-proposal, which I've ticketed at TRUNK-3361. > Instead we would add a form.entry_privilege column, so a sysadmin can create > a privilege for entering a particular form, and assign it to whatever role or > roles they choose. > > James & others: would this solve your use case? If possible please comment on > the ticket. (I'm emailing this to both the implementers and dev lists, so you > won't all necessarily get each others replies.) > > https://tickets.openmrs.org/browse/TRUNK-3361 > > -Darius > > On Wed, May 16, 2012 at 3:12 PM, Ben Wolfe <[email protected]> wrote: > Looking at it briefly TRUNK-1640 looks very similar to what is on slate for > the gsoc project. Both are linked to forms, not to encounter types. > > Ben > > > On Wed, May 16, 2012 at 5:41 PM, Daniel Kayiwa <[email protected]> wrote: > > Hi James, > > We shall not deal with TRUNK-1640 during GSOC because it will broaden the > scope more than what the student is expected to cover in that limited time. > > However, i see it fitting in next week's Roles and Privileges Sprint. > So i think we could consider it as part of what we are going to deal with > during that sprint. > > What do others think? > > > On Mon, May 14, 2012 at 3:21 PM, 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 > > > -- > If we keep uppermost in our minds the unkind and unjust acts of others, we > shall find it impossible to love them as Christ has loved us; but if our > thoughts dwell upon the wondrous love and pity of Christ for us, the same > spirit will flow out to others. > > 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 > Click here to unsubscribe from OpenMRS Implementers' mailing list Want to Get Healthy? The Tasmania Government's Get Healthy Information and Coaching Service(R) provides free information and coaching support to Tasmanian adults who would like to learn healthier eating habits, be more active or achieve and maintain a healthy weight. Call 1300 806 258 between 8am and 8pm, Monday to Friday or visit www.gethealthy.tas.gov.au for more information. CONFIDENTIALITY NOTICE AND DISCLAIMER The information in this transmission may be confidential and/or protected by legal professional privilege, and is intended only for the person or persons to whom it is addressed. If you are not such a person, you are warned that any disclosure, copying or dissemination of the information is unauthorised. If you have received the transmission in error, please immediately contact this office by telephone, fax or email, to inform us of the error and to enable arrangements to be made for the destruction of the transmission, or its return at our cost. No liability is accepted for any unauthorised use of the information contained in this transmission. If the transmission contains advice, the advice is based on instructions in relation to, and is provided to the addressee in connection with, the matter mentioned above. Responsibility is not accepted for reliance upon it by any other person or for any other purpose. _________________________________________ 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]
