[Openid-specs-heart] Resources vs Resource sets

Adrian Gropper agropper at healthurl.com
Wed Jul 27 23:04:22 UTC 2016


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
> <javascript:_e(%7B%7D,'cvml','eve.maler at forgerock.com');>>
> Date: 7/27/16 4:54 PM (GMT-05:00)
> To: "Glen Marshall [SRS]" <gfm at securityrs.com
> <javascript:_e(%7B%7D,'cvml','gfm at securityrs.com');>>
> Cc: HEART List <openid-specs-heart at lists.openid.net
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','gfm at securityrs.com');>
>>
>> www.SecurityRiskSolutions.com <http://www.securityrisksolutions.com/>
>>
>>
>>
>> *From:* Openid-specs-heart [mailto:
>> openid-specs-heart-bounces at lists.openid.net
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','agropper at healthurl.com');>>; Salyards,
>> Kenneth (SAMHSA/OPPI) <Kenneth.Salyards at samhsa.hhs.gov
>> <javascript:_e(%7B%7D,'cvml','Kenneth.Salyards at samhsa.hhs.gov');>>
>> *Cc:* HEART List <openid-specs-heart at lists.openid.net
>> <javascript:_e(%7B%7D,'cvml','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
>> <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/f3056477/attachment-0001.html>


More information about the Openid-specs-heart mailing list