[Openid-specs-heart] HEART stepping stones

Moehrke, John (GE Healthcare) John.Moehrke at med.ge.com
Sun Apr 19 16:06:34 UTC 2015

Hi Eve,


I am in no way trying to hold the status quo constant. I want us to improve the situation. I am just setting whole landscape so that we are all talking about the same variables.


As you indicate the patient has the right (generally) to a copy of their data. Once they get that data they can do whatever they want, even if it is stupid. I am not trying to protect the stupid.  My point is that they cannot give permissions that they themselves don’t already have. 


I am just saying that across the whole permissions space, there are overlapping but not fully engulfing policy spaces. The patient certainly has as much authority as they have the right to have. However there are things that the patient can not cause to happen. There are things that the provider cannot cause to happen. There are things that the insurance clerk cannot cause to happen. No matter how much these individuals WANT it to happen.


To give an example of what I am trying to say: The patient, no matter how much they want, cannot give permissions to prescribe narcotics. This permission comes from a very different vector. Right?


This is should not be shocking to anyone in any authorization space. Right? Even in a pure OAuth environment where it is simply protecting a Blog; the owner of the blog can grant others access to their blog; but those not given any permissions by the owner of the blog cannot grant themselves edit rights.


The Patient gains the rights to access, once they have that right they can ‘give’ that right to others. But they cannot give permissions that they  themselves don’t have.


So we simply recognize that the body of permissions that we are manipulating are those set of permissions that the patient already has possession of. The only way to change the body of permissions that the patient has is to change regulation. We are not in control of regulations, although we can influence them eventually. So we should not focus on the lack of access. We should focus on the refinement of the permissions they already have. This refinement is ADDING capability, a capability to enable proper access controls; whereas the status quo has data not flowing even when it should, and flowing where it should not due to poor controls. 


Note that there have been many experiments with patient privacy permissions. Some of them have been reversed as they were found to not work well. So we need to be careful when referencing historic documentation. We want to move forward and give more access.




From: Eve Maler [mailto:eve.maler at forgerock.com] 
Sent: Saturday, April 18, 2015 11:02 AM
To: Moehrke, John (GE Healthcare)
Cc: openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] HEART stepping stones


Hi John-- I'm kicking myself for having had to miss what must have been a fascinating discussion on the call you reference. Some questions on your writeup, if I may -- all in the context of my not being a HC subject matter expert!...


In one portion of the use case I was demonstrating this week at HIMSS, the patient has primary access to some electronic data about the functioning of her own body, to which she then grants her doctor access. It would seem that this is a case that draws outside the lines of your hypothesis.


And in a conversation with Mike Davis this past week, I was given to understand that there's a key difference in controls the moment that a patient has been given access to data about him- or herself. That is, Alice has the right to both access that data, and do with it what she wishes. This seems to change a lot of access control equations (even if one could observe that Alice could make poor choices, or want to design a clever UX or educate her to help her make good choices, etc.).


Does it make sense to hold the status quo constant given these two "new" (not sure exactly how new) elements?


Finally, I have a dim recollection of seeing a research paper back when I was a security analyst about a hospital system (somewhere in the Netherlands perhaps? forgive the lack of citation) that tracked the number of exceptions to its access control policies for access to records, and it was over 50% -- the point being that any access control system that is honored more in the breach than in the observance is not doing its job very well. This is surely not a novel situation, in this context or other contexts... If we hold the status quo constant, would we be building on the right system?

Eve Maler
ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/>  community!


On Tue, Apr 7, 2015 at 7:30 PM, Moehrke, John (GE Healthcare) <John.Moehrke at med.ge.com> wrote:

Hi all,


Last week I took on an action item to write up a potential way we could divide and conquer the Healthcare Access Control space. (Sorry, this got far longer than I figured I would write).


What I implored is that the whole Access Control space in healthcare is very complex, and that we might want to focus on one aspect at a time. Eventually working through everything. I don’t mean to limit our goal, just to limit our stepping stones to that goal. I fear that if we don’t do something like this then we will all be solving a different problem and ultimately solving no problem. 


There are some complexity

·         Patient controls

·         Professional controls

·         Government/Business controls

·         Team Controls

·         Medical Safety Controls


Healthcare has very classic Enterprise security needs often managed by classic Role-Based-Access-Control (RBAC). These are cases where Radiologists get ready access to Radiology type stuff. They get to view the information in the health record that might impact their radiology read, they can order more radiology tests, radiology contrast agents, and write radiology reports. The Oncologists get ready access to Oncology stuff, and Dieticians get access to the information they need to make a proper meal for a patient. There are clinicians that are given the rights to prescribe drugs, others that are authorized to prescribe narcotics. It is true that often times in practice everyone has far more rights than they need to have. However academically it is very classic. There are some bright-lines, that is types of data that are very clear what permissions would be needed. One has a Resource-Type, Access-Type (CRUDE), and a User/Role. Because the Profession is the one organizing their own copy of the data, they often have it organized in a way that makes their RBAC easy.


We have the patient desires. Some patients are very restrictive with their data (tend to be the young), while others are very liberal with their data (tend to be very old). Some want to hide data for whatever reason. The reason is NOT important, but by exposing some examples we get a feel for how widespread the rules might be. They might want to block a period of time, a specific condition or episode, a type of data (HIV results), or block the data from a specific individual.  Again, the reason is not important.  They also might want to explicitly authorize something that is unusual, such as authorizing a research project, or a specific individual. The variance here is very large. Unlike the Professional Controls, the variance is not usually very well aligned with the way the data is organized.


Patients often need guardians: parents, children, spouse, etc. Patients often are helpless, unconscious, incapable.  Yet some patients are very aware, very smart, very capable…


There are Government mandates and Business needs that go beyond either of the above. These are very hard to model as they tend to be special cases. Such as Public-Health-Reporting, where for the sake of keeping the population healthy the government asks that specific analysis of the data be done and that a report be generated. The goal is not specific to one patient, but about a population; however to get the job done one needs to have “Read” access to everything without exceptions. (Note that in any analytics a few exceptions are not important, analytics is robust to small defects). I know that many will argue that I shouldn’t combine Government mandates and Business needs; but the access control need is the same; the difference is in the perceived fairness. I am not arguing that all analytics are equally fair or should be authorized. I am not, I am just pointing out a bolus of types of access control rules that are very different than Professional Controls and Privacy Controls.


The data in healthcare is not as obvious as most industries. Meaning the above all presumes that data are well segmentable into ‘types’. This is not really true, healthcare data has some grey areas. This true of both Professional and Patient control needs. A big example of this is how specific topics become very sensitive over time, then sometimes fall away. Thus the exact same data might be considered normal, or highly sensitive. This is where we bring in very healthcare specific rules engines, the same ones that aid a clinician with diagnosis – aka Clinical Decision Support. These engines use the current rules around ‘what is sensitive’ to seek out and make a current assessment of the data. This current assessment might be represented by metadata tags. Such is the topic of “Data Segmentation for Privacy”, which is simply a set of metadata tag vocabulary that is helpful in virtual segmentation of data that might have different privacy rules applied to it. This same thing can be used for reasons other than privacy. An extreme example is where a lab-result clearly shows a terminal condition, but under medical ethics the doctor is obligated to speak one-on-one with the patient before disclosing the information to that individual. 


A slight variance on this is related to ‘the care team’. When a patient is being treated by a doctor, it is clear that doctor needs access. It should be clear that the nurses in direct contact also need access. It is less obvious that those that receive lab orders, radiology orders, prescriptions, etc also need access. And even less clear that those that are routing the bills to get paid and the one paying the bills need ‘some’ access. When a patient is in surgery, there is a whole team of people involved in the preparation, surgery, and recovery. So there are a whole team of people caring for a patient, some with direct contact with the patient, some with very indirect contact. YET, everyone else that is not on the ‘team’ should have no legitimate reason to access the data, right? This is sometimes referred to the ‘care team’ or ‘legitimate access’.  Unfortunately this is not easy to nail down either. And is only really possible to understand within one healthcare treatment organization. Cross-organizational boundary and it is much harder. Yet care-teams often do cross organizational boundaries. Examples are out-patient, long-term care, radiology centers, physical therapy centers, etc.


Lastly, which some see this as first, is when Professional decision overrides the judgment of the patient due to a clear danger to the patient or care providers. This often called “break-glass” is implemented in many ways. It is agreed in society that there are times when this is allowed. It should always be clear when these cases are allowed, and when they are used. My point is that medical safety override is yet another complexity.


To all of this we have many use-cases: Clinician accessing for treatment, Billing Clerk accessing for Billing, Patient accessing for their own understanding, etc. The ‘user’ can be any persona. And Clinicians are patients too.


So, you can see if we tried to solve all these at the same time we would have way too many variables moving… 


I suggest that we hold most of these ‘constant’, while improving in one place. When I say hold ‘constant’ what I mean is utilize the existing access control system to cover that space. 


On the call, I suggested that we focus on the variability in the Patient Controls space; while holding the Professional Controls and all the care setting stuff constant. Meaning we allow legacy mechanisms, for now, to control access at RBAC, ABAC, Break-glass, and Team. Thus the system that controls Radiologist being restricted to radiology-type data is using classic means, but that which is used to determine if the patient has consented is using HEART. Said another way, the HEART mechanism can only rule over the Patient Controls rules. 


I am not suggesting that we must start with this, just that it seemed the primary interest on the call. 


John Moehrke
Principal Engineer: Standards - Interoperability, Privacy, and Security
Architect | Predix™ for Healthcare

GE Healthcare 

M +1 920 912 8451 <tel:%2B1%20920%20912%208451> 

 <mailto:John.Moehrke at med.ge.com> John.Moehrke at med.ge.com
 <http://www.gehealthcare.com/> www.gehealthcare.com


3200 N. Grandview Blvd 

Mail stop:  WT-881

Waukesha, WI  53188

GE imagination at work


Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150419/b9c06cfd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6966 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150419/b9c06cfd/attachment-0001.p7s>

More information about the Openid-specs-heart mailing list