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

Mon Jun 27 13:45:34 UTC 2016

I agree with something useful.

Aren't we profiling common resource sets and scopes for a FHIR RS;
Something that could be use generically by all but perhaps  extended if
need be?

I  think FHIR RS shares resource sets/scopes it supports to UMA AS.
Period.  No hints further (c on Adrians list) User sets preferences for
sharing on those resource sets.  If a release seems like a logical RS set -
then let's add to the list.

On Jun 27, 2016 8:49 AM, "John Moehrke" <johnmoehrke at gmail.com> wrote:

> Hi Adrian,
>
> Small but important clarification. The confidentiality classifications I
> gave are universal in healthcare. They are used in all forms of HL7,
> including FHIR and CDA. They are used in DICOM. They are used in IHE
> XDS/XCA and Direct. There is even a mapping to 13606 equivalent risk scale.
> So by starting with this group you are not picking something special for
> FHIR, but you are picking something that works with FHIR and other
> exchanges. In all of these cases this value-set is built right into the
> core of each of these standards.  We could use a smaller subset, like older
> CDA did.  Note this set also supports when data has been de-identified and
> thus moved to a lower risk, where lower risk is an assessment and an
> appropriate movement down the scale. So it even works where
> differential-privacy might move the data down to "M" or "L".
>
> Are we tying to determine the FINAL list of scopes? Or just a starter set
> that seems to be useful? I was hoping we were just looking for something
> useful. I understand that our need is to enable interoperability, as the
> scopes do need to be agreed to by all parties. Thus this starter set just
> gets us back to focusing on the HEART specifics. Scopes are infinitely
> expandable so the starter set can be enhanced or even replaced (deprecated)
> later.
>
>
> 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:03 PM, Adrian Gropper <agropper at healthurl.com>
> wrote:
>
>> Thank you John for making things clear. Changing the subject line of my
>> "Is HEART Profiling Privacy?" thread does not solve the problem but I do
>> appreciate and respect Eve's intent.
>>
>> I'm not sure the OpenID Connect analogy is useful for HEART or for UMA in
>> general.
>>
>> I claim that building on FHIR Confidentiality Classification is beyond
>> HEART's charter. Patient Privacy Rights would love to participate in that
>> discussion with whomever in HL7 wants to join in but it's not easy to see
>> who else would be at that table and I don't see anyone clamoring to charter
>> that group. For reference, I've attache a nice study of what might be
>> involved in such an exercise.
>>
>> I hope UMA does not force HEART to profile privacy. As John makes clear,
>> FHIR resource types are not being designed to make privacy classifications
>> or patient understanding of privacy issues particularly easy or hard. I
>> suspect the same thing is true outside of healthcare.
>>
>> My suggestion does not require that HEART profiles privacy or make use of
>> confidentiality classification. A HEART resource server (a) can publish the
>> list of resource types it supports, and
>> (b) can post to a specific HEART AS which resource types are or are not
>> available for a particular resource registration, and maybe
>> (c) can optionally post explanations, hints, resource type groupings, or
>> examples to the specific HEART AS. This would enable a RS to send the
>> equivalent of their current Release of Information form to the AS.
>>
>> Note that (c) is optional. Whether (c) is there or not, FHIR supports
>> whatever granularity it supports and there's no reason an AS should not
>> choose to take advantage of that.
>>
>> Therefore (a) and (b) together allow any RS to register with any AS and
>> it's up to the AS to map the resource types into policy choices for the
>> resource owner. Rather than HEART profiling privacy, i suggest we allow ASs
>> to compete on how to present the privacy issues to the resource owner.
>>
>> Adrian
>>
>>
>>
>>
>> On Sun, Jun 26, 2016 at 9:21 PM, John Moehrke <johnmoehrke at gmail.com>
>> wrote:
>>
>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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/
>>
>
>
> _______________________________________________
> 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/20160627/21ce6089/attachment.html>