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

[Debbie Bucci]

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/4d7e706d/attachment.html>