Stream: implementers
Topic: Consent Document, with Questionnaire(s)
Matthew Koch (Jun 11 2019 at 18:42):
Hi all,
I am looking for some guidance on how to best represent a research consent document. Our consent documents at MSK contain a bunch of text that research participants must read and agree to. Some consent documents ask the participants questions that they respond to. Our consent documents are also logically broken into "sections" (typically a table of contents).
The 3 resources that seem obvious to me are Consent, Questionnaire, and QuestionnaireResponse. Can these be tied to one another to represent what I described above? Keep in mind that I am talking about storing the content of a consent document itself, separated out from the fact that a Patient consented and provided Questionnaire responses.
Lloyd McKenzie (Jun 11 2019 at 18:47):
Questionnaire provides a mechanism to present prompts to a user for a set of data elements and then gathers those data elements (as a QuestionnaireResponse). It can do that for data elements for any resource - including Consent. So it may make for a useful presentation layer for consent information. However, in the end you're going to want that information represented in a Consent resource where you can actually execute logic, search, filter, etc. The Structured Data Capture IG provides guidance on designing Questionnaires where it's straightforward to converta a QuestionnaireResponse into another FHIR resource or set of resources (e.g. Consent).
Matthew Koch (Jun 11 2019 at 19:03):
OK, I will have to look into this. SDC sounds familiar. Is this the link? http://hl7.org/fhir/us/sdc/index.html Is it ready for R4?
One question I have (probably conceptual) - A consent for an oncology study can be long and contain lots of text, and some don't ask questions (they just want a signature.) Just wondering how this could be best represented.
David Pyke (Jun 12 2019 at 17:49):
That's a good question for the BRR workgroup, but if you're looking for that kind of thing, a Contract is your best as it handles signatures.
David Pyke (Jun 12 2019 at 17:49):
Once you have the signature, we are working toward having the Consent resource manage the consent internally
John Moehrke (Jun 12 2019 at 18:47):
I see no evidence that Contract handles signatures any better than any Resource. Besides in this case the signature is likely across the Questionnaire Response as that signature would be easily recorded in a Provenance on that Questionnaire Response instance. That Questionnnaire Response would be the evidence found in the Consent.source[x]. The signature would not be on the Consent (or Contract) resource.
Matthew Koch (Dec 19 2019 at 16:23):
Reviving this because I have another question @Lloyd McKenzie - Could we in theory just use a FHIR Document that includes content in the form of text, questionnaires, etc? https://www.hl7.org/fhir/documents.html
Lloyd McKenzie (Dec 19 2019 at 16:32):
Not sure why you'd need to wrap it in a document. You can use QuestionnaireResponse, but those aren't searchable based on their contained data and wouldn't be recognized by anyone else. QuestionnaireResponse is useful for capturing and displaying data, but unless you're in a closed system where everyone recognizes them, they're of limited use for business process.
Matthew Koch (Dec 19 2019 at 16:33):
We are trying to send a representation of a document itself, which includes (but is not limited to) questionnaires. In addition to questionnaires we have a lot of consent document content we want to represent in a FHIR resource, if possible. This specific use case is not yet dealing with questionnaire response, only the structure and content of a document not yet associated with patient input.
John Moehrke (Dec 19 2019 at 16:43):
that is similar to what I wrote up lately https://healthcaresecprivacy.blogspot.com/2019/11/fhir-consent-mapped-with-bppc.html
Matthew Koch (Dec 19 2019 at 16:48):
That post talks about DocumentReference, which could be useful once we capture informed consent. I'm talking about before that happens, just representing a document.
Matthew Koch (Dec 22 2019 at 17:35):
@Lloyd McKenzie just wanted to hear your thoughts, is Document / Composition something we can potentially use in this scenario? The document we're trying to represent is relatively simple, so it seems that they would work, e.g. a Composition resource with a bunch of section(s), where each section has text, etc.
John Moehrke (Dec 23 2019 at 15:01):
That post talks about DocumentReference, which could be useful once we capture informed consent. I'm talking about before that happens, just representing a document.
as in publishing the overall policy? Yes, that is possible with DocumentReference. Simply don't fill out the .subject as the overall policy is not patient specific. (Or fill out .subject with the Organization, as it is about the organization). This is in IHE covered in the NPFS (Non-Patient File Sharing) implementation guide.
Matthew Koch (Dec 23 2019 at 16:31):
That post talks about DocumentReference, which could be useful once we capture informed consent. I'm talking about before that happens, just representing a document.
as in publishing the overall policy? Yes, that is possible with DocumentReference. Simply don't fill out the .subject as the overall policy is not patient specific. (Or fill out .subject with the Organization, as it is about the organization). This is in IHE covered in the NPFS (Non-Patient File Sharing) implementation guide.
One quick clarification, I thought DocumentReference was supposed to refer to a document that already "exists" in some binary form. What I'm talking about is sort of representative of a data transfer object between two systems - so the idea of having a Document bundle wrapping a composition object with other references seems more apt.
Lloyd McKenzie (Dec 23 2019 at 17:17):
DocumentReference can exist alone. (The name is misleading.). Documents aren't typically the preferred way to share information in FHIR. What is it about your use case that you think makes documents necessary?
Matthew Koch (Dec 26 2019 at 20:21):
We have two systems. One is used to author consent documents, which is used to create the content (e.g. the actual stuff patients read, along with images, etc.) of a consent document related to a clinical trial. The other system is used as a presentation layer for said content, and is used to capture actual consent to the trial for which the consent was authored. The first system needs to "send" information to the second, and a document seems like an appropriate package/mechanism for this, e.g.:
{
"resourceType": "Bundle",
"type": "document",
"entry": [
{
"fullUrl": "https://test",
"resource": {
"resourceType": "Composition",
"section": [
{
"title": "Section 1 Title",
"text": {
"div": "Section 1 html"
}
},
{
"title": "Section 2 Title",
"text": {
"div": "Section 2 html"
}
},
{
"title": "Section 3 Title",
"text": {
"div": "Section 3 html"
}
}
]
}
},
{
"fullUrl": "http://testURL",
"resource": {
"resourceType": "ResearchStudy",
"title": "MED-1234"
}
}
]
}
This is the direction we've been going in. It seems to be valid FHIR, so to us it makes sense as a simple representation of a document for our use case.
Matthew Koch (Dec 26 2019 at 20:33):
Now that I look at both, perhaps Contract is a good option as @David Pyke suggested...
Matthew Koch (Dec 26 2019 at 20:51):
Contract can reference Composition in the same way as Document can (via thefriendly and legal attributes) so I think that may be a better option, now that I am digging in. Thanks! Let me see where we go with this.
Lloyd McKenzie (Dec 26 2019 at 21:28):
Many things that are called "documents" in a clinical environment don't necessarily have to be represented as documents in FHIR. Document is used when you need to package a bunch of resources together and store them as a frozen snapshot. If you can get away with a single resource and not bother bringing Composition into the mix, that's generally better. However, if you need the additional packaging and/or rendering rules that documents provide, they're available for use.
Matthew Koch (Dec 27 2019 at 00:02):
Ok so what I’m hearing is stick to the explicit resources when possible as a rule, use the more abstract stuff when it makes sense. I get that - thanks!
Matthew Koch (Dec 29 2019 at 16:38):
After considering our basic use case I think we’ll pursue the document route after all, due to the flexibility it provides re:composition and the fact that it seems to map very closely to what we’ve got already modeled. If contract makes more sense down the line we will consider.
Last updated: Apr 12 2022 at 19:14 UTC
