For what it's worth, I think that *implementers* have been pretty consistent over the years at asking to be able to hide forms and encounters. We've often said "well you really don't want that, because you need a 'break glass' feature" but I don't think they've actually agreed, as much as just not replied. So, I'm curious to hear what response my email to the implementers list gets.
Really the issue is that we have a single patient dashboard page that serves *everyone*, whereas the "break glass" feature is relevant to clinicians but not really to data clerks, registration clerks, social workers, etc. All we're actually talking about here is controlling whether certain types of encounters are visible/editable *on the patient dashboard*. This won't apply to reporting, nor will it apply to using the API to search for obs that happen to be in encounters of filtered-out types. So really I guess we're allowing people to associate an application-level privilege with encounter types, which is respected on the patient dashboard. Personally I think that if implementations are asking for something clearly and consistently, and we have a straightforward way to implement it, we should. They're the ones who know their use cases and organizational setups best. We should inform them about best-practices, but we should trust them to make their own decisions about hiding encounter types on the dashboard. What I *do* think is worth spending extra design thought on is whether the current proposal will work in a future world where we have different patient dashboards for different roles. -Darius On Sun, May 20, 2012 at 12:28 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) < r...@cdc.gov> wrote: > So we’ve heard three different propositions: that filtered encounters > should be excluded without notice, that filtered encounters should be > excluded with notice, that filtered encounters should not be filtered from > treating physicians. This sounds like a business rule that should not be > enforced by the API. This is particularly true when you consider the > problem of running a monthly report of encounters by encounter type or > number of patients by encounter type. Even the blood bank wants to know > how many patients it has seen, and reports this number to the hospital > director.**** > > We could certainly facilitate this request by providing a filtered call > with the optional ability to permit access by a treating physician (I think > the best we can do to represent this concept is to see if the patient has > an encounter where the provider’s person is the same as the user’s person). > Since our objects pretty much all have a Count method, we could report the > difference between that and the number of records returned by the filtered > call.**** > > ** ** > > Darius, HIV and psychiatric data are just as non-disclosable as blood bank > information, and the reasons for blood and HIV overlap. Yet every EMR > seems to have some sort of “break glass in case of emergency” method to get > around this. If you encounter a disoriented patient displaying signs of > dementia, you want to know if they had a history of HIV or psychiatric > treatment.**** > > ** ** > > We got down this path by conceding that role-based or location-based > security was beyond our current capability; but it appears that even > encounter-based security is problematic. We might be better off > researching how security could be remodeled than trying to hack our current > model. For example, it might be better to subclass encounter to blood > -bank-encounter and to use table-per-concrete-class mapping so that > blood-bank-encounter access would require permission to access that table > as well as the encounter table. And then we might need to run all reports > as the daemon user.**** > > ** ** > > *From:* implement...@openmrs.org [mailto:implement...@openmrs.org] *On > Behalf Of *Darius Jazayeri > *Sent:* Sunday, May 20, 2012 1:43 PM > *To:* openmrs-implemen...@listserv.iupui.edu > *Subject:* Re: [OPENMRS-IMPLEMENTERS] [OPENMRS-JIRA] (TRUNK-3377) Should > be able to define a privilege required to view or edit an encounter**** > > ** ** > > Hi All,**** > > ** ** > > From having talked briefly to James, and having talked at length with HISP > India long ago, I think a main use case for not showing encounters to > certain users on the dashboard is to support storing Blood Bank data.**** > > ** ** > > My understanding is that given the way the consent forms work, if you > record blood bank information about a patient, it should be *absolutely* > invisible > to non-blood bank users. E.g. showing "2 encounters hidden" would violate > those terms.**** > > ** ** > > Further, many users (most/all in some implementations) are not clinicians. > If an implementer wants to set things up so that most of their data clerks > cannot see HIV encounters, and not get a tell-tale "hidden encounters" > message, I think we should support this functionality. We can add some > documentation to the Edit Encounter Type page to say it's bad practice to > hide encounters from *clinicians*. But I think we should support the > actual functionality people are asking for.**** > > ** ** > > James and others, would it be okay to show "n encounters hidden" when > some are suppressed? Or do you want to completely hide them?**** > > ** ** > > -Darius**** > > On Sun, May 20, 2012 at 8:33 AM, Ben Wolfe (Commented) (JIRA) < > jira-tr...@openmrs.org> wrote:**** > > **** > > ****Ben > Wolfe<https://tickets.openmrs.org/secure/ViewProfile.jspa?name=bwolfe>commented > on [image: > New Feature]TRUNK-3377 <https://tickets.openmrs.org/browse/TRUNK-3377> *** > * > > *Should be able to define a privilege required to view or edit an > encounter* <https://tickets.openmrs.org/browse/TRUNK-3377> **** > > The encounters tab should say "X encounters were hidden from view" (only > show if any encounters were actually hidden)**** > > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA > administrators<https://tickets.openmrs.org/secure/ContactAdministrators!default.jspa> > . > For more information on JIRA, see: http://www.atlassian.com/software/jira > ** ** > > ** ** > ------------------------------ > > Click here to > unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-implement-l>from > OpenMRS Implementers' mailing list > **** > ------------------------------ > Click here to > unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l]
