[Openid-specs-heart] Resources vs Resource sets

Wed Jul 27 23:45:15 UTC 2016

Adrian, this is why I am pushing for HEART progress, because SMART is now
powerful to take us beyond toys.

John

On Jul 27, 2016 6:32 PM, "Adrian Gropper" <agropper at healthurl.com> wrote:

> +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>
>> wrote:
>>
>>> Go Aaron!
>>>
>>>
>>> On Wednesday, July 27, 2016, Aaron Seib <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
>>>>>
>>>>>
>>>>
>>
> _______________________________________________
> 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/75e43b62/attachment-0001.html>