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: [email protected] [mailto:[email protected]] On Behalf Of Darius Jazayeri Sent: Sunday, May 20, 2012 1:43 PM To: [email protected] 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) <[email protected]<mailto:[email protected]>> wrote: [https://tickets.openmrs.org/s/en_US-yq2h8l/649/92/_/images/omrs-comm-badge-200x50.png] [https://tickets.openmrs.org/secure/useravatar?ownerId=bwolfe&avatarId=10196]Ben Wolfe<https://tickets.openmrs.org/secure/ViewProfile.jspa?name=bwolfe> commented on [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<mailto:[email protected]?body=SIGNOFF%20openmrs-implement-l> from OpenMRS Implementers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
