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

[John Moehrke]

Hi Dale,

I also participate in HEART, as you can see... (I am responding to the
whole group as the following might not be well understood).

Note that no organization likes using the word "Consent". It is truly a
lighting-rod and never ends well. However reality is that we are indeed
talking about the word Consent in the dictionary definition sense of the
word, and try to avoid the emotional and abuse, all while trying to make
the system better.  More fun, in HL7 FHIR we are just now moving away from
considering these a "Contract", which is also true, but also fraught with
abuse and emotion.

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'.

There is no expectation that FHIR Consent is any less capable of being used
in a Patient Centric way, but it must also be useable in all the other ways
that healthcare needs.

It is very possible that one could use the FHIR Consent resource in a UMA
environment; I just don't see this as a compelling architecture. It could
certainly be a good educational project.

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 4:16 PM, Dale Moberg <dale.moberg at orionhealth.com>
wrote:

> Not yet. Just wanted the group to know of that work in progress. Uncertain
> whether UMA is interested in consent issues yet or not.
> (There has been discussion, exasperation, and a temporary moratorium on
> usage of “consent”]
> There is still considerable discussion of what the hoped for outcome of
> the HEART profiles is to be.
> I noted that there was one expectation expressed in the draft about what
> the outcome should be.
>
>
>
> From: John Moehrke <johnmoehrke at gmail.com>
> Date: Wednesday, June 22, 2016 at 5:11 PM
> To: Dale Moberg <dale.moberg at orionhealth.com>
> Cc: Debbie Bucci <debbucci at gmail.com>, "
> openid-specs-heart at lists.openid.net" <openid-specs-heart at lists.openid.net>
> Subject: Re: [Openid-specs-heart] FYI Draft of a FHIR resource called
> "Consent"
>
> Dale,
>
> I am one of the leads on the FHIR Consent work. There is significant
> editing going on right now. The github site is a perspective into the
> editing process, it is the result of the continuous build. So what you see
> might be good stuff, or might be simply one random thought.
>
> Is there a question?
>
> 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 3:24 PM, Dale Moberg <dale.moberg at orionhealth.com>
> wrote:
>
>>
>> http://hl7-fhir.github.io/consent.html
>>
>> From section 6.7.3
>> […]
>> “ The enforcement of the Privacy Consent Directive is not included, but
>> is expected that enforcement can be done using a mix of the various Access
>> Control enforcement methodologies (e.g. OAuth, UMA, XACML). This
>> enforcement includes the details of the enforcement meaning of the elements
>> of the Privacy Consent Directive, such as the rules in place when there is
>> an opt-in consent would be specific about which organizational roles have
>> access to what kinds of resources (e.g. RBAC, ABAC). The specification of
>> these details are not in scope for the Consent resource. "
>>
>>
>> _______________________________________________
>> 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/20160622/6d09870d/attachment-0001.html>