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

Mon Jan 25 20:43:41 UTC 2016

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
>
> @CaptBlueButton
>
>  (o) 301-540-2311
>
> (m) 301-326-6843
>
> [image: cid:image001.jpg at 01D10761.5BE2FE00] <http://nate-trust.org>
>
>
>
> *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
>
> @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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.bitbucket.org_HEART_openid-2Dheart-2Dfhir-2Doauth2.html&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=6l_dXC_ZgvWc8H1KnQO3L8tAaIS6x3NM1L-RYlayLaE&s=DX7NZxWP_wwUTEJo8zlYCoEY7XOB5GBatwQ3HF2KPl4&e=> (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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__forgerock.org_openuma_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=6l_dXC_ZgvWc8H1KnQO3L8tAaIS6x3NM1L-RYlayLaE&s=r0SdYnRaAJ6Hd0OvanbSEKUaCxpyJpn4pKx8AGOkf40&e=>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=Zuber2bEm2oNWuLNkPrIDiojbSW0yLabWElsMbuOJ3E&s=nPfKx9ftf0TuXI7qC5Ugq8op_DMv_oRTONR85yHGVCw&e=>
>
>
>
>
> --
>
>
>
> 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/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=Zuber2bEm2oNWuLNkPrIDiojbSW0yLabWElsMbuOJ3E&s=zHr-Asc3QsheUFWMssLC-V_ZCM6yEmAyWW3Ipy_fZb4&e=>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160125/38bc7520/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/38bc7520/attachment.jpg>