[Openid-specs-heart] Resources vs Resource sets

Wed Jul 27 23:49:21 UTC 2016

Exactly John. Toys or not, patient mediated transactions and restricted
use-cases like PHRs are not enough to sustain HEART. We need to accommodate
the full range of patient-directed HIE including, non-HIPAA, wearables, and
42 CFR from the outset.

Adrian

On Wednesday, July 27, 2016, John Moehrke <johnmoehrke at gmail.com> wrote:

> 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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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/97baec91/attachment.html>