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

John Moehrke johnmoehrke at gmail.com
Mon Jun 27 01:21:44 UTC 2016


Hi Eve,

It would seem that we would indeed have this figured out. But reality is
that we never quite talk about it so bluntly, mostly because classifying
healthcare data is so very hard. Further the various ways that would be
logical don't fall nicely upon the logical ways that data can be segmented.
That is the way that people would like to segment their data is according
to how sensitive it is; yet this doesn't align with FHIR resources, or
departments, or function, etc...  Plus data changes sensitivity based on
current medical knowledge (HIV was very sensitive a few years ago, today it
tends to trend closer to normal data).

So the best I have to offer is the _confidentiality classifications we have
in the security-tags: It is a scale that centers around Normal - that group
of data that everyone agrees is the typical healthcare data (mathematically
normal). Think of it as a risk scale of 6 different risk quantum. All data
MUST have one of these values assigned to it.
   http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html

so U, L, M, N, R, V --- definitions are on the page above.

Is this a good solution? NO! but it does exist today.

More on my blog article

https://healthcaresecprivacy.blogspot.com/2015/07/how-to-set-confidentialitycode.html
or
  https://healthcaresecprivacy.blogspot.com/2016/01/fhir-oauth-scope.html

John

John Moehrke
Principal Engineering Architect: Standards - Interoperability, Privacy, and
Security
CyberPrivacy – Enabling authorized communications while respecting Privacy
M +1 920-564-2067
JohnMoehrke at gmail.com
https://www.linkedin.com/in/johnmoehrke
https://healthcaresecprivacy.blogspot.com
"Quis custodiet ipsos custodes?" ("Who watches the watchers?")

On Sun, Jun 26, 2016 at 11:18 AM, Eve Maler <eve.maler at forgerock.com> wrote:

> 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!*
>
> _______________________________________________
> 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/20160626/eddbdab5/attachment.html>


More information about the Openid-specs-heart mailing list