[Openid-specs-heart] Resources vs Resource sets

Wed Jul 27 23:32:49 UTC 2016

+1 Eve.

Partly because of the Precision Medicine Initiative and partly because
non-patient directed exchange is collapsing under its own weight, most of
the attention is on increasing the responsibility and therefore
transferring risk onto the patient.

I was at the HL7 FHIR applications conference today and it's interesting to
see how OpenID Connect and patient-directed apps are slowly gaining
traction. UMA and HEART need to look forward to picking up where FHIR loses
steam. We need to be clear about how we handle scopes relative to whatever
FHIR does and how that responsibility is partitioned between UMA.next and
HEART.

Adrian

On Wednesday, July 27, 2016, Eve Maler <eve.maler at forgerock.com> wrote:

> We're all trying to figure out how to square "risk/reward" challenge --
> and hey, both patients and providers have 'em. :-) (That was actually the
> subject of my recent keynote
> <https://www.youtube.com/watch?v=BiRr5Uk9PNI&feature=youtu.be> at the
> European Identity and Cloud conference, where I used HEART as a
> centerpiece...) Thought it might be interesting to share this quote:
>
> *"The value of keeping some personal information protected, and the value
> of it being known, are almost entirely context-dependent and contingent on
> essentially uncertain combinations of states of the world. Privacy
> sensitivities and attitudes are subjective and idiosyncratic, because what
> constitutes sensitive information differs across individuals."*
>
> -- The Economics of Privacy, Alessandro Acquisti et al., March 2016
> <http://people.duke.edu/~crtaylor/Privacy_Survey.pdf>
>
> Confidentiality codes are just a bureaucratic best guess at what some
> patient will consider sensitive. We're entering a realm of directed sharing
> that lets the patient override the RS's risk management strategy through
> confidentiality codes because the patient has more say than they used to.
>
> We're at a technical cusp because we need to figure out whether the
> override mechanism is implicit ("I don't care how you, RS, classified this
> data -- I want it shared anyway by virtue of my 'consent power'") or
> explicit ("I want you, RS, to *reclassify* this data in some fashion").
>
> I strongly suspect it's the former.
>
>
> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
> Technology
> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
> *ForgeRock Summits and UnSummits* are coming to
> <http://summits.forgerock.com/> *Sydney, London, and Paris!*
>
> On Wed, Jul 27, 2016 at 4:04 PM, Adrian Gropper <agropper at healthurl.com
> <javascript:_e(%7B%7D,'cvml','agropper at healthurl.com');>> wrote:
>
>> Go Aaron!
>>
>>
>> On Wednesday, July 27, 2016, Aaron Seib <aaron.seib at nate-trust.org
>> <javascript:_e(%7B%7D,'cvml','aaron.seib at nate-trust.org');>> wrote:
>>
>>> The consumer always has the right to have access to data about them.
>>>
>>> They have the right to direct you to share it with the third party of
>>> their choosing regardless of what bright lines have been burned into the
>>> brains of security and privacy professionals who have been relied upon to
>>> exchange data in compliance with the law when the scope  of exchange was
>>> entirely about sharing with another covered entity.
>>>
>>> I urge anyone who hasn't gotten the message to look at OCR's guidance
>>> from this year.
>>>
>>> It frightens me to think there are folks who work in this space and feel
>>> they have the paternalistic power to tell someone what they are allowed to
>>> do with their rights.
>>>
>>> If HEART isn't about embracing the promise of consumer directives it is
>>> a waste of time.
>>>
>>> Aaron Seib
>>>
>>> The trick to establishing trust is to avoid all tricks.  Especially
>>> tricks on yourself.
>>>
>>>
>>> -------- Original message --------
>>> From: Eve Maler <eve.maler at forgerock.com>
>>> Date: 7/27/16 4:54 PM (GMT-05:00)
>>> To: "Glen Marshall [SRS]" <gfm at securityrs.com>
>>> Cc: HEART List <openid-specs-heart at lists.openid.net>
>>> Subject: Re: [Openid-specs-heart] Resources vs Resource sets
>>>
>>> This is a great discussion from my perspective. We've come to the nub
>>> here -- about what "patient centricity" means, risk appetite of the service
>>> operator/institution, and other matters.
>>>
>>> I don't know how it works in health IT regulatory regimes and am eager
>>> to find out. But in some other existing and emerging regulatory regimes,
>>> gathering individual consent is a key consideration -- and fast becoming
>>> *the* key consideration -- in mitigating organizational risk for data
>>> transfer. That is, if the customer/consumer/end-user consents, that trumps
>>> other constraints.
>>>
>>> UMA's proposition, of course, goes farther than enabling "reactive"
>>> consent, by enabling "proactive" consent as well -- what might be called,
>>> ahem, "consent directives" :-), or authorization policy, or sharing
>>> instructions, or delegation of access, etc.
>>>
>>> In other words, it's now possible to ask people what they want shared,
>>> and then *do what they say* (within the law). The benefits go beyond
>>> compliance, all the way to demonstrating trustworthiness and "building
>>> trusted digital relationships".
>>>
>>> It seems that confidentiality codes are first and foremost a tool of
>>> compliance, not of Alice's wishes. We have two humps to get over in
>>> leveraging them:
>>>
>>>    - Use cases: If the FHIR API server/UMA resource server were to
>>>    transfer these codes to the UMA authorization server, what use are they to
>>>    the AS and/or to the patient/UMA resource owner?
>>>    - Logistical: Is this transfer even in scope for HEART?
>>>
>>>
>>>
>>> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
>>> Technology
>>> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
>>> *ForgeRock Summits and UnSummits* are coming to
>>> <http://summits.forgerock.com/> *Sydney, London, and Paris!*
>>>
>>> On Wed, Jul 27, 2016 at 1:03 PM, Glen Marshall [SRS] <gfm at securityrs.com
>>> > wrote:
>>>
>>>> The boundary of existing regulatory mandates for privacy and security
>>>> is a bright line.  It defines the minimum we in health IT must achieve.
>>>> Anything beyond that either anticipates regulatory change or states an
>>>> objective or some sort.
>>>>
>>>>
>>>>
>>>> In the case of covered entities’ objectives, we can assume they have
>>>> performed HIPAA-required risk analysis and set risk management policies
>>>> accordingly. I believe that OAuth and UMA operate most effectively in a
>>>> such a businesslike risk-mitigation environment, where the semantics of the
>>>> security and privacy metadata are unambiguous.
>>>>
>>>>
>>>>
>>>> When we honor patient-specific privacy choices, we ignore covered
>>>> entity risk assessment and in-common semantics.  Patients are under no
>>>> obligation to perform a formal business risk analysis or articulate it in a
>>>> commonly-understood way.  Their choices may be realistic or not, articulate
>>>> or not.  We have no simple objective basis to assess, let alone enforce,
>>>> them.
>>>>
>>>>
>>>>
>>>> It is a philosophic ethical question as to how we honor patient privacy
>>>> choices.  It is not clear to me that the health IT marketplace is ready to
>>>> answer it.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Glen F. Marshall
>>>>
>>>> Consultant
>>>>
>>>> Security Risk Solutions, Inc.
>>>>
>>>> 698 Fishermans Bend
>>>>
>>>> Mount Pleasant, SC 29464
>>>>
>>>> Tel: (610) 644-2452
>>>>
>>>> Mobile: (610) 613-3084
>>>>
>>>> gfm at securityrs.com
>>>>
>>>> www.SecurityRiskSolutions.com <http://www.securityrisksolutions.com/>
>>>>
>>>>
>>>>
>>>> *From:* Openid-specs-heart [mailto:
>>>> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Aaron Seib
>>>> *Sent:* Wednesday, July 27, 2016 14:25
>>>> *To:* Adrian Gropper <agropper at healthurl.com>; Salyards, Kenneth
>>>> (SAMHSA/OPPI) <Kenneth.Salyards at samhsa.hhs.gov>
>>>> *Cc:* HEART List <openid-specs-heart at lists.openid.net>
>>>> *Subject:* Re: [Openid-specs-heart] Resources vs Resource sets
>>>>
>>>>
>>>>
>>>> I don't understand why we would even ask the consumer what their
>>>> preference is if they can't change a default used by a Covered Entity?
>>>>
>>>>
>>>>
>>>> That is the entire point.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Aaron Seib
>>>>
>>>>
>>>>
>>>> The trick to establishing trust is to avoid all tricks.  Especially
>>>> tricks on yourself.
>>>>
>>>> _______________________________________________
>>>> 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/20160727/9c9db2a9/attachment.html>