Hi Bruke, Below is how I see the scenarios
On Thu, Apr 19, 2012 at 7:00 PM, Burke Mamlin <[email protected]>wrote: > 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. > Two policies would work here: * One policy could be that all doctors in a site should be able to view all the patient records that have encounter recorded in that site * If the patient changes site, then the patient should allow the new site doctors to access the patients record. This is given the basis that the patient has utmost authority on his/her data. > > 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. > Inappropriate access is one, which could be tracked and audited, but misuse of the information is another. In India, for example, people are sensitive interms of letting someone in their relative circle to know about their health condition (and the someone could be a doctor registered in openmrs). Not only this, legally, it is not okay to allow anyone and every one to view the patient record, though it is a doctor. > > 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. > > Clinic/hospital level access would not work, since doctors keep on moving between hospitals professionally. And no matter how much we do not want, hospitals are run like businesses. So a hospital that have N number of registered patients, does not want this data to be available to doctors not belonging to that hospital. BUT a patient can always choose to move from one hospital to another and from one doctor to another. > > - Restricting direct access to specific types of sensitive data (e.g., > mental health records, HIV results, etc.). > > Yes, and again this has to be at the doctor level > > - 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." > > Warnings would not help, but complete restrictions are required. > > > Cheers, > > -Burke > -- Sateesh > > 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 >> > > ------------------------------ > 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]
