Stream: implementers
Topic: Consent – usable for the admissibility check?
Ardon Toonstra (Dec 18 2019 at 17:02):
Before Patient healthcare data is sent to a healthcare provider, an admissibility check needs to be performed to check if a healthcare professional wants to receive the data. How to express this in FHIR, any experiences?
Is the Consent resource suitable for this? So a query on the Consent endpoint with the Patient identifier is performed to possible receive a Consent resource that states a healthcare professional has given consent to receive the patient data. Wrong use of the Consent? Would Task / ServiceRequest be better?
Any advice is welcome!
John Moehrke (Dec 18 2019 at 17:28):
I don't think that Consent is the right solution. Consent is about the 'patient' expression of consent and rules of that consent. It sounds like you have a similar function where the clinician is expressing their interest (disInterest) and the rules. Is this right?
John Moehrke (Dec 18 2019 at 17:29):
There is some interest in creating a general purpose Permission resource. It would look similar to parts of the Consent resource, but be more focused on permissions and not be specific to Patient Privacy Consent. The security workgroup is discussing this, but have not yet prototyped the Resource.
John Moehrke (Dec 18 2019 at 17:32):
An alternative for your use-case might be a use of the Group, List, or CareTeam resources. Where a Practitioner would publish a list of the Patient(s) they are responsible for. I am not sure which of these three are best, as this is not something have focused on. @Lloyd McKenzie ?
Lloyd McKenzie (Dec 18 2019 at 19:14):
Knowing what patients a Practitioner is responsible for is different from who they want to receive data about. At the complex end, you could have a PlanDefinition that sets the rules for what types of information should flow to which individuals in which circumstances. However, if the intention is that you ask the question "would you like to receive data of type X about patient Y" before you actually send that information, the closest I can think would be CommunicationRequest. The trick is that the acceptance/rejection of the CommunicationRequest is generally done by the expected performer, not by the expected recipient. @Michelle (Moseman) Miller - thoughts?
Eric Haas (Dec 18 2019 at 20:29):
subscription?
Lloyd McKenzie (Dec 18 2019 at 21:03):
That's a technical mechanism to ask for data to be pushed. It's not quite the same thing as "do I have permission to send"
Jose Costa Teixeira (Dec 19 2019 at 07:55):
This seems a case for Permission.
Jose Costa Teixeira (Dec 19 2019 at 08:00):
Permission would state "this party has permission to get the data". It would also include what and how would be done with the data, and justification like a policy or a contract.
Jose Costa Teixeira (Dec 19 2019 at 08:01):
and the evidence which could be the physician's statement that they have agreed to receive the data
Ardon Toonstra (Dec 19 2019 at 14:22):
Thnx all for your thoughts!
- I agree that Consent is not suitable for this purpose... too Patient-focused.
- Group/CareTeam for the purpose of showing which practitioner has which patient is also not correct for this use case.
- Subscription sounds like the other way around indeed.
- Permission sounds ok! But doesn't exists yet.
- I will have a look at the CommunicationRequest.
Ardon Toonstra (Dec 19 2019 at 14:24):
But how about Task? That a healthcare provider / professional system creates Task resources that can be queried to check if data can be sent?
Ardon Toonstra (Dec 19 2019 at 14:25):
Other two options would be to do this with the Basic resource or to do it not in FHIR at all.
Lloyd McKenzie (Dec 19 2019 at 15:06):
Task lets you say "please do", so I suppose you could say "please authorize me sending you data of type x about patient y". The result really should be some resource that represents the authorization, not just a completed Task.
Eric Haas (Dec 19 2019 at 16:37):
The ask was...
check if a healthcare professional wants to receive the data. How to express this in FHIR, any experiences?
I don't think this is a permissions thing as asserted above
It's not quite the same thing as "do I have permission to send"
The provider has access to more patient data than they want to see. So why not use subscriptions to pair it down to what they want to see? The provider doesn't have subscribe herself it could be done by some algorithm or something?
Lloyd McKenzie (Dec 19 2019 at 16:43):
Subscription requires a subscription infrastructure and query capability on both sides. It's a very different workflow.
Jose Costa Teixeira (Dec 19 2019 at 16:45):
@Eric Haas your first comment makes sense, but I was assuming that we wanted to consider the "permission granted - as in, after the request, the physician grants/is granted the right to receive the data". Which I believe is a permission thing.
Jose Costa Teixeira (Dec 19 2019 at 16:46):
My opinion is that we seem to be missing a Permission resource.
John Moehrke (Dec 22 2019 at 15:31):
Before Patient healthcare data is sent to a healthcare provider, an admissibility check needs to be performed to check if a healthcare professional wants to receive the data. How to express this in FHIR, any experiences?
Is the Consent resource suitable for this? So a query on the Consent endpoint with the Patient identifier is performed to possible receive a Consent resource that states a healthcare professional has given consent to receive the patient data. Wrong use of the Consent? Would Task / ServiceRequest be better?
Any advice is welcome!
In thinking about this a bit longer... This usecase is exactly what the Oauth flow addresses. It isn't publishing the rules for others to read and hopefully execute correctly, it is a decision making service that is given parameters of a request, and results in a deny or a permit with a security token proof of permit. @Ardon Toonstra
John Moehrke (Dec 22 2019 at 15:36):
In the OAuth model, there is no need to standardize the rules. One only needs to standardize the parameters and the decisions. Behind the OAuth service API could be proprietary or standards or both. This should be considered first. But sometimes encoding the rules in a standard way is also useful, hence we have Consent and are considering Permission.
Ardon Toonstra (Dec 23 2019 at 12:09):
@John Moehrke , I believe this admissibility check is part of establishing an OAuth token. The admissibility check can almost be seen as a boolean check, in our proof of concept phase. If a healthcare provider gave 'permission' for a certain patient to send him any kind of information this boolean would be true or a FHIR resource would exist. Below a very simplified and quickly to English translated overview of the location of this check.
pasted image
Ardon Toonstra (Dec 23 2019 at 12:11):
@Jose Costa Teixeira , I believe I share your opinion about missing a Permission resource. Is there already any info available on this possible future resource? I am interested to follow the progression and possibly share our experiences.
Ardon Toonstra (Dec 23 2019 at 12:15):
For now, we are thinking of using the Basic resource. It looks like we could meet all our requirements with defining only one extension and selecting the right terminology for the .code.
Jose Costa Teixeira (Dec 23 2019 at 13:17):
Hi @Ardon Toonstra . My initial thoughts are here: http://zeora.net/blog/2019/11/19/permission-is-key/
John Moehrke (Dec 23 2019 at 13:47):
Please do join us in the Security WG. We cover FHIR Security on Mondays (starting up again in 2020).
John Moehrke (Dec 23 2019 at 13:57):
John Moehrke , I believe this admissibility check is part of establishing an OAuth token. The admissibility check can almost be seen as a boolean check, in our proof of concept phase. If a healthcare provider gave 'permission' for a certain patient to send him any kind of information this boolean would be true or a FHIR resource would exist. Below a very simplified and quickly to English translated overview of the location of this check.
pasted image
I am confused as to why you need a FHIR resource. It seems like the need is satisfied by OAuth. What is the communication need for the FHIR Resource? What is your extension on Basic? What actors are accessing it?
Last updated: Apr 12 2022 at 19:14 UTC
