Good point Sateesh, that is probably more common a use-case than my example. Although whether we add the ability to restrict at a hospital level or a provider level, we have the same problem:
There isn't a way to mark a patient's health center. The workaround some people have used are either using a new person_attribute_type or a post-data entry query of "if this patient has ever had an en encounter at location x". There isn't a way to mark a patient's provider(s). The workaround is similar in that a person_attribute_type could point at a provider. If we add this as one of the simple options for data restriction we'll need to add a core method of storing the info AND help users migrate their workarounds into it. Ben On Thu, Apr 19, 2012 at 12:56 AM, Sateesh Babu <[email protected]>wrote: > In my view a patient is always related to a doctor and not a hospital and > has utmost authority on his/her data. > In this aspect, if Patient_A was checked upon by Doctor_X in Hospital_H, > then the Patient_A record should be accessible by only Doctor_X unless and > until the Doctor_X has referred Patient_A to other doctors in Hospital_H > > It would surely be not correct to allow each and every doctor in the > OpenMRS installation to allow access to all patient records > > -- > Sateesh > > On Wed, Apr 18, 2012 at 10:56 PM, Ben Wolfe <[email protected]> wrote: > >> (moving to dev list) >> >> Wayne >> >> My biggest fear is that If we were to implement data level permissions it >> would slow the system down significantly. >> >> Data level permissions starts off easy: >> Restrict patient with location = X to users with privilege >> can_see_patients_at_location_x >> >> However, making that generic gets complicated: >> >> restrict table y where column_z = X to users with privilege >> can_see_table-y_where_column_z_is_X >> >> I'm sure there would be a way to store that so that an admin can specify >> that. However, we'd then have to modify all core api calls to obey that >> principle. Reporting would be the real slow-down. >> >> If we could identify the 90% use-case for data level permissions that >> might be doable. How would you be using it? aka what are you restricting, >> when, and to whom? >> >> Examples: >> 1) Provider at hospital Y can only see patients if they have ever had an >> encounter at location Y >> (if making most generic: how to know if a provider is "at" hospital Y?) >> >> 2) Provider of specialty A can only see patients if they have had an >> encounter with encounter_type A, Aa, or AAa >> >> 3) User can only see data that they are the "creator" of >> >> Ben >> >> On Wed, Apr 18, 2012 at 12:54 PM, Wayne Chelliah <[email protected]> wrote: >> >>> Hi Ben >>> >>> Just following up on our conversation from last week. Can you please >>> help me understand what are some of the specific challenges with the >>> OpenMRS architecture that make data level permissions difficult? >>> OpenMRS can use roles and privileges to restrict access to pages, forms >>> and encounters. But can we restrict access to groups of data that span >>> multiple encounters? >>> >>> Regards >>> Wayne >>> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list > > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' 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]
