[Openid-specs-heart] FYI Draft of a FHIR resource called "Consent"

Thu Jun 23 03:10:02 UTC 2016

Speaking for myself, the only confusion I have is why there was such a
heated debate around FHIR Consent long before I showed-up on that scene.

I understand that John is trying to tell us that what's happening in FHIR
Consent has practically nothing to do with HEART. He could be right but I'm
still worried.

The reason I'm worried has to do with our discussion in HEART about FHIR
"Resource Types" and OAuth or UMA "Scopes". As far as I'm concerned both
FHIR and UMA are equally immature in the sense that neither one is in
clinical use AFAIK. My fear is that FHIR, by focusing its resource type
design on FHIR Consent will unwittingly do something that makes Scopes and
User Managed Access a lot uglier.

The reason is that there is obvious interplay between the resource types
FHIR defines and the way policies and scopes are understood by the patient.
In one design we might be making the institution's life easier and in the
other design the patient's life easier. I'm not saying that anyone is doing
that on purpose or that it will even happen, but I am saying that we are
not explicitly designing for patient-centered health records and this could
come back and bite us all really badly.

My claim in the other thread about not trying to profile "privacy", is that
designing the FHIR patient-level resource types around UMA is the first
thing to do. Then, we would have a clearer understanding of FHIR "consent"
as it relates to FHIR institutional resource-types (not patient-level) as
well as directories and relationship locator services, and all sorts of
other critical privacy issues in an institutional context that FHIR Consent
may be trying to address.

Adrian

On Wed, Jun 22, 2016 at 10:33 PM, John Moehrke <johnmoehrke at gmail.com>
wrote:

> Debbie,
>
> I do think that somehow I gave you the wrong impression. There is no
> reason why the two systems can't work together. Indeed this multi-layer of
> access control is what  think Adrian is revering to with his Adrian rule.
> (Not the only use of this multi-layer).
>
> Most 'apps', if we are thinking mobile-applications, or even old-style
> fat-clints, won't be the ones using the FHIR Consent rules. These FHIR
> Consent rules would be more likely enforced infront of the departmental
> server. But, this is just one possibility.
>
> I tried very hard to express that even with the FHIR Consent can be used
> in a patient centric architecture...
>
> I was simply trying to in as short of space as possible draw distinction
> between FHIR Consent and HEART/UMA; while also showing they are not in
> conflict; and that they both must be developed for different reasons.
>
> So, what other confusion have I caused?
>
>
> 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 Wed, Jun 22, 2016 at 7:02 PM, Debbie Bucci <debbucci at gmail.com> wrote:
>
>> Correction...Patient input (not info) needed
>> On Jun 22, 2016 7:56 PM, "Debbie Bucci" <debbucci at gmail.com> wrote:
>>
>>>
>>> >>>>I expect that using the UMA mechanism is equivalent to what the FHIR
>>> Consent is attempting to do regarding encoding the rules of data
>>> disclosure. Equivalence is a very loose term. -- VERY LOOSE.. (Adrian will
>>> surely rant here)
>>>
>>> Where in the UMA case it is focused on the technical means of making a
>>> decision and enforcing that decision. In UMA it is the AS
>>> responsibility to deal with the UX and persistence of the rules that it
>>> is enforcing. Meaning in UMA there is no requirement to expose the
>>> rules. This is one architectural model, and one I agree with with "User"
>>> "Managed" "Access".
>>>
>>> Where as in FHIR Consent the goal is to persist the rules in an open
>>> format. Where in FHIR Consent it puts the capturing of the rules
>>> out-of-scope, expecting that the way that the consent is captured will be
>>> the focus of application developers. This is similar as with UMA, but
>>> more explicitly putting the separation at the rule encoding. In FHIR
>>> Consent it also does not indicate how the rules will be processed (decision
>>> and enforcement).  The focus in FHIR on capturing the rules, is that it
>>> is trying to address the needs of healthcare that has highly distributed
>>> systems. That is to say that it is very unusual for one healthcare
>>> organization to have all their data under one service API, thus
>>> controllable by one access control system.  Each department within an
>>> organization likely has one server for their specific data, it is only
>>> conceptually understood as being all related to the 'one patient'. <<<<
>>>
>>> Huh? I'm lost ...
>>>
>>> I get that app developers will need to deal with consent up front and
>>> healthcare orgs must deliver consent as part of the payload .
>>>
>>> From my casual observance , primarily from pending European privacy
>>> requirement (those in the know correct me if I am wrong)  I am aware of a
>>> couple of efforts working to create " privacy managers" to simplify consent
>>> across many sectors for data that is deemed sensitive by the state/country
>>>
>>> A service that may contain my "default" preferences to ease the data
>>> gathering burden on the app  developer or data entry by patient does not
>>> seem far fetch to me.    They seem complimentary. Neither actually
>>> process/interpret the policies.  Adrian will remind us it's ultimately the
>>> RS decision.  Why couldn't UMA (like) workflows exist (perhaps be
>>> beneficial in that environment - where patient info is needed?
>>>
>>> I do believe it was you that urged the group to only focus on patient
>>> perspective.
>>>
>>> I must be missing something.
>>>
>>
>
> _______________________________________________
> 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/20160622/38bb4925/attachment.html>