[Openid-specs-heart] Resources vs Resource sets

Wed Jul 27 22:16:45 UTC 2016

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 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

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/41affd2c/attachment.html>