<div dir="ltr">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!...<div><br></div><div>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.</div><div><br></div><div>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.).</div><div><br></div><div>Does it make sense to hold the status quo constant given these two "new" (not sure exactly how new) elements?</div><div><br></div><div>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?</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">
<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!</p></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Apr 7, 2015 at 7:30 PM, Moehrke, John (GE Healthcare) <span dir="ltr"><<a href="mailto:John.Moehrke@med.ge.com" target="_blank">John.Moehrke@med.ge.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal">Hi all,<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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).<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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. <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">There are some complexity<u></u><u></u></p><p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>Patient controls<u></u><u></u></p><p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>Professional controls<u></u><u></u></p><p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>Government/Business controls<u></u><u></u></p><p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>Team Controls<u></u><u></u></p><p><u></u><span style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u>Medical Safety Controls<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Patients often need guardians: parents, children, spouse, etc. Patients often are helpless, unconscious, incapable. Yet some patients are very aware, very smart, very capable…<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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. <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">So, you can see if we tried to solve all these at the same time we would have way too many variables moving… <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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. <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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. <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I am not suggesting that we must start with this, just that it seemed the primary interest on the call. <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><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<u></u><u></u></span></i></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">GE Healthcare <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif"">M <a href="tel:%2B1%20920%20912%208451" value="+19209128451" target="_blank">+1 920 912 8451</a></span><u></u><u></u></p><p class="MsoNormal"><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><u></u><u></u></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif""><a href="http://ge.com/ihe" target="_blank"><span style="color:blue">ge.com/ihe</span></a></span><u></u><u></u></p><p class="MsoNormal"><span style="font-family:"GE Inspira","sans-serif"">3200 N. Grandview Blvd </span><u></u><u></u></p><p class="MsoNormal"><span style="font-family:"GE Inspira","sans-serif"">Mail stop: WT-881</span><u></u><u></u></p><p class="MsoNormal"><span style="font-family:"GE Inspira","sans-serif"">Waukesha, WI 53188</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:blue">GE imagination at work</span><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p></div></div><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><br>
<br></blockquote></div><br></div>