FHIR Chat · Consent Qs: specifying recipient and source[x] vs. policy · implementers

Stream: implementers

Topic: Consent Qs: specifying recipient and source[x] vs. policy


view this post on Zulip Morten Ernebjerg (Mar 21 2018 at 09:32):

I am trying to understand how the STU3 Consent resource could be applied to a use case in which a patient explicitly opts in to granting a particular organization access to certain information. After reading through the documentation for Consent, two questions regarding the use of specific fields remained:

1. Specifying the recipient of granted rights: On an initial reading, I would have assumed that the recipient of the granted rights (in my case, the organization that is granted access to patient PHI) should be specified in the actor field. However, in the simple opt-in General Consent example, the actor field is not used - indeed, it is not quite clear to me who the recipient is and where this is specified at all (through the link in policyRule? through the sourceAttachment?). So my question is: given that the recipient of rights granted already exists as a FHIR resource, is actor indeed the right place to specify him/her/it as the recipient of the granted rights?

2. Use of source[x] vs policy Though they are of course different, both source[x] and policy seem to provide ways of stating what the consent actually means, broadly speaking. Are there any simple rules of thumb for when to use one vs. the other vs. both? E.g. is the difference that policy should refer to what the consent says in general ("consent template") whereas source[x] should refer to a specific instance of a consent signed by a particular patient? Or is it rather than policy will be general applicable laws whereas source[x] is the particular formulation with which the patient is asked to grant specific related rights?

I know Consent isn't exactly the easiest of resources, but I was hoping there may be some broadly applicable rules-of-thumb....

view this post on Zulip Grahame Grieve (Mar 21 2018 at 11:18):

@John Moehrke @David Pyke

view this post on Zulip David Pyke (Mar 21 2018 at 11:31):

For 1. you'd use actor with a reference to the organization. Perhaps we should examine the definition ("Who|what controlled by this consent (or group, by role)") of that.

For 2. The simple rule of thumb is: Source is the document/resource/etc. that shows the actual consent language that has been signed by the patient. Policy is the relevant laws/regulations that the patient's consent is subject to. For the latest version, in build.fhir.org we've cleaned up the codelists a bit for policy.

view this post on Zulip John Moehrke (Mar 21 2018 at 15:48):

I think the use-case that Morten expresses in 1. is has not been fully reviewed. The use-cases so far have been a case where the Organization obtaining the consent is the organization authorized by the consent. So it would be good to define a use-case that explicitly is captured by a different organization, but where the consent captured will authorize other(s) organizations. This would be a good example to analyze, and to express for readers to understand. (similar use-case was brought up by Grahame yesterday on the security call).

view this post on Zulip Morten Ernebjerg (Apr 02 2018 at 08:20):

@David Pyke Thanks for the tips, that was very helpful!

@John Moehrke Yes indeed, we are considering usecases where a single consent could cover multiple organizations, of which only one would be the obtaining org. For me, an important overarching question is how to use Consent to make the the relation between the involved entities (represented as FHIR resources) as explicit as possible - for humans and machines - without using policyRule & XACML etc.

view this post on Zulip John Moehrke (Apr 02 2018 at 12:44):

I recommend you write a paragraph explaining your use-case and critical factors. Submit that as a ballot comment or gForge tracker item. The committee will then work on improving the Consent resource, and your example will become one of the examples forever in the specification.

view this post on Zulip Morten Ernebjerg (Apr 05 2018 at 08:15):

Interesting idea - we still need to nail down the details of the use case ourselves, but maybe once we are done, we can submit it.


Last updated: Apr 12 2022 at 19:14 UTC