[Openid-specs-heart] FYI Draft of a FHIR resource called "Consent"
Debbie Bucci
debbucci at gmail.com
Wed Jun 22 23:56:53 UTC 2016
>>>>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/b564c6b5/attachment.html>
More information about the Openid-specs-heart
mailing list