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

[John Moehrke]

Don't look too closely at FHIR Consent right now. We need a few months
before it is reviewable.  It will be in the fall ballot.

John
On Jun 23, 2016 5:05 AM, "Debbie Bucci" <debbucci at gmail.com> wrote:

> Thanks John.
>
> I understand services so when you say enforced in front of a departmental
> service - I see that as being generated going out the door and processed on
> delivery as part of the payload.
>
> I would hope that personal data store apps that choose to include clinical
> data on behalf of their consumers would realize they must include FHIR as
> part of their suite of services .   A PDS generating a fhir consent
> resource based on patient preferences/policies managed by UMA seems like a
> viable option.
>
> To go beyond one patient I have seen - suggested architectures that would
> aggregate consent to perform broader research on populations.  That sample
> architecture suggested using UMA to both replicate and keep policies in
> sync.
>
> In HEART we keep dancing around consent and delegation  but have not made
> any progress to move it beyond discussion.  If generating/consuming  a
> consent fhir resource meets the clinical data use cases  we are most
> concerned with then we should probably take a closer look.
>
> Deb
> On Jun 22, 2016 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.
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160623/f3a65ffd/attachment.html>