[Openid-specs-heart] HEART profiling for sensitive data

Mon Mar 27 01:47:42 UTC 2017

Hello all,

Several points:

*	Defining a coding scheme is out of scope for HEART.   Others are doing (have done) good work in this area and will continue to vet.    
*	Final solutions will be a combination of policy and consents.  This too is outside of the scope of HEART.
*	Having a service to do labeling is a good idea and would help interoperability, but out of scope for HEART.
*	From what I can see, organizations are working on addressing many of these issues.  We just need to give them enough in our profile to allow them to do their good work.

I don’t know if we have yet thoroughly defined how we will register resources around sensitive data yet.  We have said that the RS will define the resources it has available for the patient, Alice.  But I hope the RS will not be telling the AS what sensitive data it has about Alice.  Instead the RS can tell the AS what sensitive data it supports.  The AS can then make those options available to all patients that have data on that RS.  Alice might deny sharing mental health data even if that does not apply to her at the time she is creating her consent.

The objective is to provide systems that will enable the patient to have control over the sharing of their data at a finer level than they do now.  HEART can only provide the profiles to support this.  There will be many use cases that will need to be addressed in future solutions.

-Nancy

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Aaron Seib, NATE
Sent: Sunday, March 26, 2017 8:59 PM
To: 'Eve Maler' <eve.maler at forgerock.com>; 'Debbie Bucci' <debbucci at gmail.com>
Cc: 'HEART List' <openid-specs-heart at lists.openid.net>
Subject: Re: [Openid-specs-heart] HEART profiling for sensitive data

Eve, you say 

“the RS can mark the resources during registration, but Alice still gets to control access based on the markings if she feels like it.”

I am not sure I follow.  Can Alice accept the markings and indicate she disagrees in certain cases and over-ride the recommendation at a granular level.

More importantly – to me – if there is something that Alice feels is sensitive but the RS didn’t tag it as sensitive does Alice have a way of saying I am sensitive about this diagnosis – or in the case of historically stigmatized diagnosis and treatments – I am no longer sensitive about this and for me I want you to share this even if the reulatory paradigm says you shouldn’t?

Aaron Seib, CEO

@CaptBlueButton 

 (o) 301-540-2311

(m) 301-326-6843

From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Eve Maler
Sent: Sunday, March 26, 2017 8:26 PM
To: Debbie Bucci
Cc: HEART List
Subject: Re: [Openid-specs-heart] HEART profiling for sensitive data

I actually think we're coming close to a happy medium (or something) with what Nancy is proposing, with the sentiment that others are expressing in the thread, and with candidate text that's appearing in our spec drafts now.

Let us assume for a moment that tags (applied by an RS) that obscure what information is "behind" them (such as "this is highly sensitive" without revealing the categories considered sensitive, or "PSY" without spelling out "Psychiatry Related") could receive UX assistance. The cool thing about the ability for a resource owner to control sharing is that such scopes are just made available for Alice's use over at the AS. There's a separation of concerns; the RS can mark the resources during registration, but Alice still gets to control access based on the markings if she feels like it.

And note that we've made a bit of progress since Nancy and I first discussed the topic and put together the initial proposal wording, which flagged potential technical issues. Justin was able to translate our WG discussions into some text, which I recommend we look at specifically to see if we want to change it. I, for one, think it's technically viable.

First: OAuth+FHIR Sec 3 and Sec 4: http://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat=html/ascii <http://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat=html/ascii&url=https://bitbucket.org/openid/heart/raw/master/openid-heart-fhir-oauth2.xml#rfc.section.3> &url=https://bitbucket.org/openid/heart/raw/master/openid-heart-fhir-oauth2.xml#rfc.section.3

Specifically, see the listings of conf/N and so on, and also "Additional confidentiality and sensitivity scopes can be defined by [[ IANA or other registry process ]]."

This section defines five specific OAuth scopes (with a sixth in the next section), and an extension mechanism by which any additional set of scopes can be used from an external specification. (The mechanism is to be determined...) Does it look like this would work for OAuth?

Second: UMA+FHIR Sec 2.2: http://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat=html/ascii <http://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?modeAsFormat=html/ascii&url=https://bitbucket.org/openid/heart/raw/master/openid-heart-fhir-uma.xml#rfc.section.2.2> &url=https://bitbucket.org/openid/heart/raw/master/openid-heart-fhir-uma.xml#rfc.section.2.2

Specifically, this language: "Additionally, the resource MAY use any of the scopes defined in [HEART.OAuth2.FHIR] regarding confidentiality, sensitivity, or emergency (break the glass)."

This section enables usage of scopes in UMA of any of the cross-cutting OAuth scopes defined in (or through) Sections 3 and 4 in the OAuth+FHIR spec. Does it look like this would work for UMA?

Eve Maler
ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Sun, Mar 26, 2017 at 5:02 PM, Debbie Bucci <debbucci at gmail.com <mailto:debbucci at gmail.com> > wrote:

We are trying to finish up the final semantic profile.

HEART profiles does not deal with UI issues

Nor would it define how to technical information is tagged.    

That said, if a resource server is able to tag information - perhaps the AS should be aware. 

I thought John originally suggested we should start focus on the confidentiality code as a start - and I think that is what Nancy is suggesting - with a bit more context.

Terminology may not be perfect and cover all use cases but certainly there is a use case or two that we could give examples for.   The two that Nancy suggest - seem general enough for a good start.  Odds are that patient would understand and could express the level of data (confidentiality code) to release.

ETH – Substance Abuse

PSY – Psychiatry Related 

I have to keep reminding myself that This dance would ONLY occur if the RS relayed to the AS it will support it.     

_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net <mailto: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/20170326/5a04bdc9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20170326/5a04bdc9/attachment.jpg>