[Openid-specs-heart] Resources vs Resource sets

Adrian Gropper agropper at healthurl.com
Sat Jul 30 17:17:17 UTC 2016 

I met Dixie Baker IRL when she gave a great talk about PCOR to the HL7 FHIR
applications meeting this week so I'm adding her to this thread.

Adrian

On Sat, Jul 30, 2016 at 12:52 PM, Danny van Leeuwen <danny at health-hats.com>
wrote:

> 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>
>
> _______________________________________________
> 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/20160730/8f3b3fdd/attachment.html>

More information about the Openid-specs-heart mailing list