<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:"GE Inspira";
        panose-1:2 15 6 3 3 4 0 2 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi Eve,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>John<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Eve Maler [mailto:eve.maler@forgerock.com] <br><b>Sent:</b> Saturday, April 18, 2015 11:02 AM<br><b>To:</b> Moehrke, John (GE Healthcare)<br><b>Cc:</b> openid-specs-heart@lists.openid.net<br><b>Subject:</b> Re: [Openid-specs-heart] HEART stepping stones<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>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!...<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Does it make sense to hold the status quo constant given these two "new" (not sure exactly how new) elements?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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?<o:p></o:p></p></div></div><div><p class=MsoNormal><br clear=all><o:p></o:p></p><div><div><div><div><div><p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl<br>Join our <a href="http://forgerock.org/openuma/" target="_blank">ForgeRock.org OpenUMA</a> community!<o:p></o:p></p></div></div></div></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Tue, Apr 7, 2015 at 7:30 PM, Moehrke, John (GE Healthcare) <<a href="mailto:John.Moehrke@med.ge.com" target="_blank">John.Moehrke@med.ge.com</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Hi all,<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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).<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>There are some complexity<o:p></o:p></p><p><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'>         </span>Patient controls<o:p></o:p></p><p><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'>         </span>Professional controls<o:p></o:p></p><p><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'>         </span>Government/Business controls<o:p></o:p></p><p><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'>         </span>Team Controls<o:p></o:p></p><p><span style='font-family:Symbol'>·</span><span style='font-size:7.0pt'>         </span>Medical Safety Controls<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Patients often need guardians: parents, children, spouse, etc. Patients often are helpless, unconscious, incapable.  Yet some patients are very aware, very smart, very capable…<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>So, you can see if we tried to solve all these at the same time we would have way too many variables moving… <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I am not suggesting that we must start with this, just that it seemed the primary interest on the call. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>John Moehrke</span></b><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><br>Principal Engineer: Standards - Interoperability, Privacy, and Security<br></span><i><span style='font-size:9.0pt;font-family:"Arial","sans-serif";color:#1F497D'>Architect </span></i><span style='font-size:9.0pt;font-family:"Arial","sans-serif";color:#1F497D'>|<i> </i></span><i><span style='font-size:9.0pt;font-family:"Arial","sans-serif";color:#131313'>Predix™ </span></i><i><span style='font-size:9.0pt;font-family:"Arial","sans-serif";color:#1F497D'>for Healthcare</span></i><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>GE Healthcare </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>M <a href="tel:%2B1%20920%20912%208451" target="_blank">+1 920 912 8451</a></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-family:"GE Inspira","sans-serif"'><a href="mailto:John.Moehrke@med.ge.com" target="_blank"><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:black;text-decoration:none'>John.Moehrke@med.ge.com</span></a><br><u><span style='color:#4F81BD'><a href="http://www.gehealthcare.com/" target="_blank"><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#4F81BD'>www.gehealthcare.com</span></a></span></u></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><a href="http://ge.com/ihe" target="_blank">ge.com/ihe</a></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-family:"GE Inspira","sans-serif"'>3200 N. Grandview Blvd </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-family:"GE Inspira","sans-serif"'>Mail stop:  WT-881</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-family:"GE Inspira","sans-serif"'>Waukesha, WI  53188</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:blue'>GE imagination at work</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><br>_______________________________________________<br>Openid-specs-heart mailing list<br><a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>