[Openid-specs-heart] Resources vs Resource sets

[Eve Maler]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160727/dbb07f50/attachment.html>