Stream: implementers
Topic: Attach a QuestionnaireResponse to serviceRequest
Tim Berezny (Feb 23 2018 at 19:41):
What is the best way to attach a questionnaireResponse to a serviceRequest?
1) Reference the QuestionnaireResponse from ServiceRequest.SupportingInfo
2) Reference the ServiceRequest from QuestionnaireResponse.basedOn
3) Other?
Note: This is a questionnaire that is submitted with the request, not in response to the request (i.e., the serviceRequest is not being FULFILLED by this QuestionnaireResponse, it's being submitted).
I was considering QuestionnaireResponse.basedOn buy am having second thoughts based on the description which says "Request FULFILLED by this QuestionnaireResponse" ... which is not the scenario.
@Brian Postlethwaite ?
Lloyd McKenzie (Feb 23 2018 at 20:03):
We're planning to talk about Questionnaire-related workflow as part of the Structured Data Capture project.
Where you attach sort of depends on why you're attaching. If it's information to take into account or that is expected to help when executing the request, supportingInfo is appropriate. basedOn is really intended to point to "request" resources - so plans, proposals or higher level orders that help to provide justification/authorization for this particular ServiceRequest. But it might be possible to have an extension pointing to it as a "reason" for the order or perhaps some other sort of link.
Tim Berezny (Feb 23 2018 at 20:22):
Thanks @Lloyd McKenzie , in this case Questionnaire is meant to capture a "Referral Form" used in a eReferral process flow. Let's say i'm referring to meals on wheels, and i want to know a) the patient's food preferences (puree, kosher, etc...), b) If there's a dangerous dog when delivering, c) etc...
i.e., to collect all of the miscellaneous info that gets asked in a referral for things other than your core data like demographics, location, etc...
So yes, it's "information to take into account that is expected to help when executing the request". So sounds like /supportingInfo is the right option then?
Lloyd McKenzie (Feb 23 2018 at 20:52):
Yes. Though be aware that information in a QuestionnaireResponse is more limited in terms of computable interoperability than discrete observations or something like that. (Not saying QuestionnaireResponse is inappropriate for your use-case, just encouraging you to make sure you've thought about the tradeoffs.)
Tim Berezny (Feb 24 2018 at 18:13):
Ok interesting, when using observations in a serviceRequest, should the by referenced by serviceRequest.supportingInfo too?
Lloyd McKenzie (Feb 24 2018 at 19:07):
If it's information included in the proposal/plan/order to aid in the execution of the requested event, yes.
Tim Berezny (Feb 24 2018 at 20:28):
Would the same logic apply to clinical/diagnostics/medications resources that might help inform to serviceRequest, such as an /allergy, or /MedicationStatement, even though those resources exist referencing the same /patient that is referenced by the /serviceRequest?
e.g., reference an /allergy resource in serviceRequest.supporting info?
Lloyd McKenzie (Feb 24 2018 at 21:16):
The way I think of it, "supportingInfo" is intended to provide links to those things the author of the request feels that the filler is likely to need to know/have access to when performing the requested activity (but that don't actually define the requested activity). If you were going to send the request in a messaging or other loosely coupled environment, you'd include all the resources pointed to by "supportingInfo" as part of the message bundle.
Brian Postlethwaite (Feb 25 2018 at 12:44):
Yeah, I think that the QuestionnaireResponse should be attached to the serviceRequest vie the supporting information property.
Last updated: Apr 12 2022 at 19:14 UTC
