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

Mon Jun 27 13:58:52 UTC 2016

Hi Adrian,

I would agree HEART shouldn't be 'profiling', as in defining formal
constraints, on FHIR resources available nor scopes available...  I agree
with you that these things are discoverable in FHIR using the FHIR
conformance mechanisms, there is no need to constrain by HEART rules.

Were we really profiling these? I thought we were looking for an
instructive set to use in explanations, examples, and test-bench.

so, what we might have here is a different understanding of the word
profiling. Formal profiling is to place constraints that can't be violated.
I think this is what Adrian is pointing out and rightfully getting worried
about.  Where as some people will use the word profiling in a more informal
way, more as a sample use-case. We should use the word profiling only in
the formal sense. This formal meaning does cause future trouble when life
changes, but then you just define a new profile... However that doesn't
mean we should formally constrain something that is not necessary to
formally constrain, when we really only want to put out a useful subset.

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 Mon, Jun 27, 2016 at 8:47 AM, Adrian Gropper <agropper at healthurl.com>
wrote:

> Hi John and Debbie,
>
> Let's stipulate the universality of the confidentiality classifications.
> My question remains: What are we profiling and why?
>
> To put this in specific FHIR and OAuth terms:
>
> - Would a FHIR resource server offer different patient-level resource
> types to an authorization server controlled by a patient vs. one controlled
> by a licensed practitioner?
>
> - Is there an objection to offering the full set of FHIR patient-level
> resource types for an AS to apply policy to whether or not a particular RS
> chooses to also bundle resource-types based on confidentiality
> classifications or any other business logic they choose?
>
> Adrian
>
> On Mon, Jun 27, 2016 at 9:45 AM, Debbie Bucci <debbucci at gmail.com> wrote:
>
>> 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
>>>
>>>
>> _______________________________________________
>> 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/20160627/866c27b1/attachment-0001.html>