I completely agree with Darius that we should aim to support the
features that implementers are asking for, providing best practice
guidance if we have particular recommendations. If we can't agree on a
solution for this in core, it's easy enough to implement this in a
module if this is just about what to show on the patient dashboard. But
is this just about the patient dashboard? What about things like the
cohort builder, reporting module, or other modules that display patient
summaries and/or encounter data. It's basically impossible for OpenMRS
to enforce the right behavior for these with respect to this - modules
often have their own APIs and DAOs and do not go through any core
service to retrieve appropriate data. Do we have any ideas how we would
address these related issues?
On 05/20/2012 05:27 PM, Darius Jazayeri wrote:
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 <mailto: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>
[mailto: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
<mailto: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 <mailto:jira-tr...@openmrs.org>> wrote:
Ben Wolfe
<https://tickets.openmrs.org/secure/ViewProfile.jspa?name=bwolfe>
commented on New FeatureTRUNK-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%21default.jspa>.
For more information on JIRA, see:
http://www.atlassian.com/software/jira
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-implement-l>
from OpenMRS Implementers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l> from
OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto: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]
