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

[Debbie Bucci]

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/31304ce2/attachment-0001.html>