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

[John Moehrke]

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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160622/673e9f37/attachment.html>