Re: [OPENMRS-IMPLEMENTERS] [OPENMRS-JIRA] (TRUNK-3377) Should be able to define a privilege required to view or edit an encounter

classic Classic list List threaded Threaded
3 messages Options
Friedman, Roger (CDC/CGH/DGHA) (CTR) Friedman, Roger (CDC/CGH/DGHA) (CTR)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [OPENMRS-IMPLEMENTERS] [OPENMRS-JIRA] (TRUNK-3377) Should be able to define a privilege required to view or edit an encounter

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: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri
Sent: Sunday, May 20, 2012 1:43 PM
To: [hidden email]
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) <[hidden email]> wrote:

Ben Wolfe commented on New FeatureTRUNK-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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

 


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [OPENMRS-IMPLEMENTERS] [OPENMRS-JIRA] (TRUNK-3377) Should be able to define a privilege required to view or edit an encounter

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) <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri
Sent: Sunday, May 20, 2012 1:43 PM
To: [hidden email]
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) <[hidden email]> wrote:

Ben Wolfe commented on New FeatureTRUNK-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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

 


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Michael Seaton Michael Seaton
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [OPENMRS-IMPLEMENTERS] [OPENMRS-JIRA] (TRUNK-3377) Should be able to define a privilege required to view or edit an encounter

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) <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Darius Jazayeri
Sent: Sunday, May 20, 2012 1:43 PM
To: [hidden email]
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) <[hidden email]> wrote:

Ben Wolfe commented on New FeatureTRUNK-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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

 


[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list

[hidden email] from OpenMRS Developers' mailing list
Loading...