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

Adrian Gropper agropper at healthurl.com
Mon Jun 27 13:47:38 UTC 2016


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/91c5b724/attachment.html>


More information about the Openid-specs-heart mailing list