[Openid-specs-heart] Ad hoc get-togethers to work on elements of UMA "semantic" profiling

Aaron Seib aaron.seib at nate-trust.org
Mon Jan 25 21:07:56 UTC 2016


    
Thanks guys.  


Aaron Seib at CaptBlueButton
(O) 301-540-9549(M) 301-326-6843
"The trick to earning trust is to avoid all tricks.  Including tricks on yourself."


-------- Original message --------
From: Josh Mandel <Joshua.Mandel at childrens.harvard.edu> 
Date: 2016/01/25  1:43 PM  (GMT-07:00) 
To: "Aaron Seib, NATE" <aaron.seib at nate-trust.org> 
Cc: Adrian Gropper <agropper at healthurl.com>, Eve Maler <eve.maler at forgerock.com>, HEART List <openid-specs-heart at lists.openid.net> 
Subject: Re: [Openid-specs-heart] Ad hoc get-togethers to work on elements of UMA "semantic" profiling 

Aaron,
A key definition to know is "designated record set". The best overall FAQ on this question is:http://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/

Read this page from the top down through (including) the section called "Information Excluded from the Right of Access" for a very good overview on what's in and out.
  -J
On Mon, Jan 25, 2016 at 3:28 PM, Aaron Seib, NATE <aaron.seib at nate-trust.org> wrote:



Do you have a citation to the specific part of HIPAA?  I am curious how actionable is defined.  On the API task force there were a couple of interpretations and I wonder what the sources says and how it is actually applied in the real world today.  Aaron Seib, CEO at CaptBlueButton  (o) 301-540-2311(m) 301-326-6843 From: agropper at gmail.com [mailto:agropper at gmail.com] On Behalf Of Adrian Gropper
Sent: Monday, January 25, 2016 3:25 PM
To: Aaron Seib
Cc: Josh Mandel; Eve Maler; openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] Ad hoc get-togethers to work on elements of UMA "semantic" profiling Me too. 

I would further suggest that we define "entire clinical record" as HIPAA does - meaning all clinically actionable information for that one patient.Adrian On Mon, Jan 25, 2016 at 3:17 PM, Aaron Seib <aaron.seib at nate-trust.org> wrote:I am all for these suggestions.     Aaron Seib at CaptBlueButton(O) 301-540-9549(M) 301-326-6843 "The trick to earning trust is to avoid all tricks.  Including tricks on yourself." 

-------- Original message --------
From: Josh Mandel <Joshua.Mandel at childrens.harvard.edu> 
Date: 2016/01/25 12:59 PM (GMT-07:00) 
To: Eve Maler <eve.maler at forgerock.com> 
Cc: openid-specs-heart at lists.openid.net 
Subject: Re: [Openid-specs-heart] Ad hoc get-togethers to work on elements of UMA "semantic" profiling Hi Eve, A quick tweak on your description of SMART on FHIR scopes, and then a suggesion. You wrote: There, the scope string has been designed to have a complex pattern of "permission/resource.access", or in extended explanatory form, "who-has-permission/to-what-resource.with-what-access", or very roughly in terms of parts of speech of authorization policy, "subject/object.verb". The subject is "patient" or "user". The verb is "read" or "write". The object can be a variety of standard resource strings. (Check me if I'm wrong...) The first piece isn't quite "who-has-permission". Instead, it's "what-level-of-permission", where "level" should be interpreted as "patient-level" or "user-level". In other words, when authorization is given, it's given to "resources belonging to this patient record", or to "resources available to this user". This allows SMART apps to say "I want one record" or "I want all your records" (and "your" is context-sensitive here; but it could be all the records available to a clinician in her practice practice, or all the records available to a parent in her portal account.</end tweak> --- I can see how mapping these terms into UMA concepts like "resource id" and "scope" might feel unnnatural. Here's how I'd suggest approaching the mapping:  * eliminate the "user" vs "patient" prefixes from SMART's scopes * initially, limit requests to one patient at a time (throw away the "user/" concept) * represent each patient's "entire clinical record" as a single UMA resource Then apps can ask for scopes of access into these resources. For example, 
 * an RqP that wanted to all of Patient 123's records would make a request that the RS would associate with its "Patient 123's entire clinical record" resource, and a scope of "*.read".   * an RqP that wanted to know all prescriptions for Patient 123 would make a request that the RS would associate with its "Patient 123's entire clinical record" resource, and a scope of "MedicationOrder.read".  Later on it might be worth bringing back user-level permissions, which would map to new UMA resources (ones that represent "the pile of all  data that User 123 can see" as a single UMA resource). But that's several steps down the road, in my opinion. We could make plenty of progress without it.   -J    On Mon, Jan 25, 2016 at 2:35 PM, Eve Maler <eve.maler at forgerock.com> wrote:I promised to send a description of what elements of UMA semantic profiling might look like, to see who might be interested to get together at times offset from our regular calls to push forward on them. Resource sets and scopes We have become familiar with "scopes" from our draft HEART profile for FHIR OAuth scopes (which, so far, is based closely on the SMART on FHIR work). There, the scope string has been designed to have a complex pattern of "permission/resource.access", or in extended explanatory form, "who-has-permission/to-what-resource.with-what-access", or very roughly in terms of parts of speech of authorization policy, "subject/object.verb". The subject is "patient" or "user". The verb is "read" or "write". The object can be a variety of standard resource strings. (Check me if I'm wrong...) UMA breaks things down a bit differently, and has further options. A "resource set" (often abbreviated simply "resource") is declarable separately from the "scopes" that apply to it; this makes it especially easy to have scopes that are custom to a resource set. Resource sets can be given named "types", so that any resource sets that are of standardized types (e.g. have standard data taxonomies applied to them) can be marked as such, and perhaps given special automated authorization/consent treatment. These data types could connect to security labeling taxonomies as appropriate. Any scopes we define can be declared in such a way that even those not using the official FHIR API (or using an extended FHIR++ API or whatever) could be invited to apply them to their own resource sets, thus encouraging greater interop. Claims to satisfy policy Here's how UMA operates: The authorization server executes a resource owner's requirements for "elevating trust" in the requesting side of the equation before associating authorization data with a token that it gives the requesting party's client app. Then when the client brings the token to the resource server, the latter matches the token's authorization data against the kind of access attempted before letting the client in. We talk about the resource owner's requirements being expressed in "policy", though UMA doesn't actually have a way to express policy on the protocol wire. (Systems may internally use XACML or whatever they wish.) However, the ability of an authorization server to handle resource owner policy-setting and policy decision-making is intertwined with its needs and abilities around detecting characteristics of the requesting side of the equation. That requesting side consists of two parts: the client application and the requesting party (which could be a "natural person" or "legal person"). The biggest element of trust elevation we usually talk about is "claims-gathering", though there can be more to it. Briefly, some of the use cases that can be solved with claims include:Identification: Who is the requesting party?Authentication: How strongly were they authenticated?Attributes: What professional certifications do they have?Purpose of use: What do they promise to do or not to do with my data?----- Perhaps more to come as we discuss and learn, such as potentially profiling "design patterns".Eve Maler
ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
Join our ForgeRock.org OpenUMA community!
_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=BQICAg&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=6l_dXC_ZgvWc8H1KnQO3L8tAaIS6x3NM1L-RYlayLaE&s=QiUBQVZ6Dxoxept-3j2Uqj3z2XlgFF7Hqtwi3_kIyn0&e=

 
_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-heart


--  Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/ 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160125/936b8d3e/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/20160125/936b8d3e/attachment.jpg>


More information about the Openid-specs-heart mailing list