Stream: implementers
Topic: Consent Template & ResearchStudy
Patrick Werner (Apr 11 2022 at 15:17):
What is the best practice to link needed Consent to ResearchStudy (seeing Consent as definitional im this context)?
Just put an extension on ResearchStudy with valueUrl pointing to to the same url as Consent.policy.uri ?
For Consents we are pointing in Consent.policy.uri to the (paper) Consents the patient had agreed to.
Patrick Werner (Apr 11 2022 at 15:27):
As inclusion and exclusion criteria are captured through ResearchStudy.enrollment -> Group.characteristic, another option could be to use Group.characteristic.valueReference.identifier and use the Identifier of the Consent here.
John Moehrke (Apr 11 2022 at 15:32):
@Patrick Werner This has not been fully defined, due to the need for use-cases to do the use-case analysis. I suspect that there will need to be extensions in FHIR R4, with updates to the Consent in R5. So I think it is very useful that we work on this together.
Patrick Werner (Apr 11 2022 at 15:33):
Happy to work on this one. Also adding @Stefan Sigle @Stefan Lang @Martin Bialke
John Moehrke (Apr 11 2022 at 15:33):
I expect that an instance of a ResearchStudy defines a specific study? Thus a Consent by a Patient to participate (allow their data to be used) would indicate that ResearchStudy instance somewhere. There is not an obvious place in FHIR R4, except possibly using .provision.data
David Pyke (Apr 11 2022 at 15:35):
There is currently an extension added for R5 that allows ResearchStudy to be added to .provision and a workflow extension that can be used against R4
John Moehrke (Apr 11 2022 at 15:37):
so the workflow extension is used to indicate "this workflow is permitted/denied"?
David Pyke (Apr 11 2022 at 15:38):
It's a general extension that indicates context.
John Moehrke (Apr 11 2022 at 15:39):
but is that the meaning it holds when used in a Consent.provision?
David Pyke (Apr 11 2022 at 15:39):
That would require policy to define. It's not a direct Consent extension.
John Moehrke (Apr 11 2022 at 15:40):
okay, then it is not really useful in this case. right?
David Pyke (Apr 11 2022 at 15:40):
Personally, I would use it as in .provision to work as a context element, just as the R5 extension is used
Patrick Werner (Apr 11 2022 at 15:43):
John Moehrke said:
I expect that an instance of a ResearchStudy defines a specific study? Thus a Consent by a Patient to participate (allow their data to be used) would indicate that ResearchStudy instance somewhere. There is not an obvious place in FHIR R4, except possibly using .provision.data
not sure if i understood correctly. Yes each study is an Instance of ResearchStudy, in Consent we are pointing to paper consents via: Consent.policy.uri
What i am searching for: how to express: This study needs the following (abstract) Consents.
I think using Group.characteristic.valueReference.identifier and point to the Identifier of the Consent template here would be the easiest for now. Only downside would be, that the Group resource would point to needed consents, and not the Study.
BUT, the upside is: you could express abstract consents which prevent participants from joining (if this even is a use case)
David Pyke (Apr 11 2022 at 15:45):
You probably don't want to point to Consent in that situation. Likely pointing directly to the consents needed, via DocumentReference or another resource would likely be a simpler set. Consent really isn't designed to be used as a list of requirements
Lloyd McKenzie (Apr 11 2022 at 15:51):
Consent should definitely point to ResearchStudy. (Many point to the 1, new points to the old - and there will be lots of consents for a single study, and the study will - by definition - exist before the consents can exist.
David Pyke (Apr 11 2022 at 15:51):
It can. There's an extension for R5
John Moehrke (Apr 11 2022 at 16:00):
The Consent.policy.uri could point at the specific blank paper form that the patient puts ink onto. Thus if the ResearchStudy also points at that same URI somehow; then you have your linkage. You can easily query on Consents that point at that URI and ResearchStudys that point at that URI.
John Moehrke (Apr 11 2022 at 16:00):
this is treating the .uri as a definition resource
Patrick Werner (Apr 11 2022 at 16:05):
John Moehrke said:
this is treating the .uri as a definition resource
Will implement it like that. Are there plans for a definitional Consent Resource (or an type element: instance|definition) ?
John Moehrke (Apr 11 2022 at 16:11):
There is not yet work toward that, but that is indeed what I have always expected the Consent.policy element was pointing at.. might be just a uri, or might be something more...
Brian Alper (Apr 11 2022 at 18:33):
In research we recently did using FHIR Resources for all the research steps we have ResearchSubject Resources with ResearchSubject.study.reference(ResearchStudy) and ResearchSubject.consent.reference(Consent) so there is not a direct reference between the Consent (individualized) and the ResearchStudy. The Consent.sourceAttachment and ResearchStudy.relatedArtifact can both reach the same 'definitional Consent document' ---- not 100% sure if we are using Consent.sourceAttachment appropriately but it was an online study so the 'blank form' is both the consent document and the source in this case.
Patrick Werner (Apr 12 2022 at 07:33):
David Pyke said:
You probably don't want to point to Consent in that situation. Likely pointing directly to the consents needed, via DocumentReference or another resource would likely be a simpler set. Consent really isn't designed to be used as a list of requirements
To be more flexible i prefer to point to the policies included in the consent. This enables candidate searches by policy instead of Consent. Consent to me is a collection of policies a person consents.
Patrick Werner (Apr 12 2022 at 07:39):
Instead of URI a CodeableConcept is probably easier to use to create a system filtering patients by their consents.
We are now using:
Consent.provision.provision.action.coding to capture the policies inside a Consent.
& Group.characteristic.valueCodeableConcept for Groups pointed to by a research study.
John Moehrke (Apr 12 2022 at 13:06):
Im wondering... are you trying to put many consents into one instance of the Consent resource? That is not the design, the design is for each to be different Consent. Thus each consent can be individually evaluated, individually revoked, individually expired, etc.
Last updated: Apr 12 2022 at 19:14 UTC
