Sateesh, Your logic seems reasonable, but in practice it's over-simplified. Doctors often work in groups, so at a minimum you would want their partners to be able to see the patient's data when they are covering for him. Also, not all visits are performed through referral – i.e., in some implementations, patients are required to get a referral from their doctor to see another doctor. Then there are patients who change sites without warning, so implementations covering more than one clinic need to allow for this. When you add in the fact that data for doctor groups and referrals are not reliably available within the system (either at all or in a form that the authentication system can use), you may easily end up preventing doctors from seeing patients who they should see.
Rather than trying to manage all of these exceptions, most healthcare systems use trust & accountability in lieu of the arduous and error-prone task of tightly managing access to patient data. In other words, only authorized users (like doctors) have access to patient data and all accesses are logged, so any inappropriate access can be audited. More common data-level restrictions use cases I've seen are: - Using a single server for multiple distinct care systems, where you want, for example, for each clinic only to see their own data even though all of the clinics are sharing the same server. - Restricting direct access to specific types of sensitive data (e.g., mental health records, HIV results, etc.). - Additional warnings/restrictions on data for VIPs (very important persons) – e.g., the country's president is being treated in the hospital and the likelihood of inappropriate voyeurs of his data is higher. For example, the veteran's hospital system in the U.S. presents an extra warning message if you try to access your own medical record or the medical record for a patient who happens to be another doctor like "You should probably not be looking at this. Be aware than your access is being logged and you will be contacted to ensure that you are accessing these data appropriately." Cheers, -Burke 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]
