We've had these discussions recently as part of an ethics project, trying to empower patients to control access to their data in an ethical and safe manner. Hiding parts of clinical data from a clinician can adversely effect their ability to provide proper care. Patients do this all of the time by deciding what to tell their doctor and, at times, may jeopardize their care in the process... but that's their choice. Hiding parts of known data in the EMR without the provider knowing it is being hidden can be equally dangerous.
We decided that it is better to let the provider know that they are only seeing part of the data, so they can at least know that they are not seeing everything. In some cases, this is straightforward -- e.g., our system in Regenstrief will hide mental health notes from many providers. You can see a visit occurred, but not the note. If you selectively mask certain data, then a malicious user can sometimes infer the content by applying different search filters (search for "gonorrhea positive" and a masked result shows up, search for "gonorrhea negative" and it the masked result does not show up). I would recommend being very careful on masking data and, when you do so, let the provider know that data are being masked -- e.g., showing "You do not have privileges to see this encounter" in place of a masked encounter. Then use auditing & accountability as your primary means of securing data. When a user accesses data they should not, confront them and, if they do not have a good reason, punish them appropriately. Most providers & patients are trying to do the right thing. Cheers, -Burke On Friday, May 18, 2012, Hannan, Terry J wrote: > 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<https://tickets.openmrs.org/browse/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<https://tickets.openmrs.org/browse/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<https://modules.openmrs.org/modules/view.jsp?module=restrictbyrole> > 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!!!**** > > **** > > _________________________________________ 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]
