[Openid-specs-heart] Considering profiling resource sets/scopes for the "before first visit" sharing scenario

Eve Maler eve.maler at forgerock.com
Sun Jun 26 16:18:59 UTC 2016


This message is intended to give shape to our profiling efforts. I
apologize in advance if I "step in it" due to my lack of HL7 or FHIR
knowledge. :-)

Given our first sharing scenario
<https://bitbucket.org/openid/heart/wiki/Alice_Shares_with_Physicians_and_Others_UMA_FHIR>
(in
the latest use case) of providing basic data before a first visit, are
there various subsets or supersets of such data, e.g., in different
jurisdictions, that Alice would be expected to provide, or one obvious and
universally understood data set? I'm guessing that payment data is one
subset of data that doesn't apply in some jurisdictions, whereas quite a
lot of "medically related data" would generally be considered desirable to
share if available.

What I'm going for here is: If you could have a system of "keywords"
representing virtual clipboard-type data sets and how you want them shared,
what's the smallest arrangement of keywords that would do the trick?

By (very rough) analogy, look at how OpenID Connect standardizes client
requests for claims using scope values
<http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims>. It
rolls up multiple identity claims under single scope names, so that
"openid" gives the client full access at the UserInfo endpoint, "profile"
gets access to 14 specific claims, "email" gets access to two claims, etc.

UMA gives us two dimensions to play with, so it could be like this:

Potential resource sets to access (I'm totally making this up! for all I
know, HL7 figured this out 10 years ago and it doesn't look anything like
this...):

   - BasicVirtualClipboardData
   - FinancialVirtualClipboardData (or a unique version per jurisdiction?)
   - AllVirtualClipboardData (an aggregation of the two of them)

Potential scopes of action across them (same for each one? it doesn't have
to be that way, and other resource sets might have deidentified-read
options or something...):

   - read
   - write

Note that the scope work already begun in our OAuth FHIR profile, coming
from the SMART on FHIR work, gives us ideas for things like a "read" verb
and a "write" verb, but for right now, we can think outside the box if
that's the right thing to do.


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


More information about the Openid-specs-heart mailing list