[Openid-specs-heart] HEART stepping stones

Eve Maler eve.maler at forgerock.com
Sat Apr 18 16:02:06 UTC 2015


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
>
> John.Moehrke at med.ge.com
> *www.gehealthcare.com <http://www.gehealthcare.com/>*
>
> ge.com/ihe
>
> 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
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150418/791bfb26/attachment-0001.html>


More information about the Openid-specs-heart mailing list