[Openid-specs-heart] Resources vs Resource sets

Sat Jul 30 16:52:06 UTC 2016

Challenging threads to follow, yet we seem to be approaching the meat: *No
data about me without me*. Does all this discussion about giving
permissions also relate to being *notified that data about me is being used*?
I was on a PCORnet Grand Rounds yesterday where there was a robust
conversation about both with a recognition that both are tough and the
industry is adolescent at best (my words).  I applaud that HEART is having
the detailed conversation that the Patient-Centered research community is
ready to hear. I'm still treading water in my understanding, but it's great
that my nose is above. Onward

On Wed, Jul 27, 2016 at 7:49 PM, Adrian Gropper <agropper at healthurl.com>
wrote:

> 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> 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
>>>
>>>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>

-- 
Danny van Leeuwen
617-304-4681

*Blog www.health-hats.com <http://www.health-hats.com/> discovering the
magic levers of best health*
Twitter <https://twitter.com/HealthHats>
LinkedIn <https://www.linkedin.com/in/healthhatsdannyvl>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160730/a37e72ae/attachment.html>