Stream: implementers
Topic: Questionnaire reference in ProcedureRequest
Raheel Sayeed (Dec 11 2017 at 21:19):
I am working on a workflow where in aPractitioner will "prescribe" aQuestionnaire for the Patient. I am using ProcedureRequest for this act. Is there a recommended way to have a reference for Questionnaire resource within the ProcedureRequest?
The reference would be to a Questionnaire resource.
Alternatively, is it possible to have that Questionnaire resource "contained" or embedded within ProcedureRequest?
Dave Carlson (Dec 11 2017 at 23:45):
Hi @Raheel Sayeed There was a related thread in Sept that might consider, using CarePlan and PlanDefinition. See https://chat.fhir.org/#narrow/stream/implementers/subject/CarePlan
Lloyd McKenzie (Dec 12 2017 at 06:29):
In the new ServiceRequest resource (which will replace ProcedureRequest) you can use ServiceRequest.instantiates to point to the URI of the Questionnaire. In STU3, you'd have to use an extension. And that would still give you a problem with containing the Questionnaire. Can you submit a change request referencing this thread so we can figure out better how to address the problem?
Raheel Sayeed (Dec 12 2017 at 15:20):
Thanks @Dave Carlson for replying.
I did look at CarePlan:
The reason I went with ProcedureRequest is that a Questionnaire, for the purposes I'm using it for, is not part of the actual CarePlan. Practitioner could order this Questionnaire to be done even before he sees the patient, sometimes in the waiting rooms.
Raheel Sayeed (Dec 12 2017 at 15:29):
Sure, will do.
Meanwhile, I was using ProcedureRequest.supportingInfo to have reference to Questionnaire/<id>. Not sure if thats the way to go.
Lloyd McKenzie (Dec 12 2017 at 15:44):
It's not ideal. SupportingInfo is more about conveying other clinical data (conditions, recent labs, etc.) that may provide useful context when executing the request. E.g. All of the background information sent as part of a referral.
Eric Haas (Dec 12 2017 at 16:43):
(deleted)
Eric Haas (Dec 12 2017 at 16:43):
(deleted)
Bryn Rhodes (Dec 12 2017 at 16:45):
Isn't that the opposite of what instantiates means though? If I'm reading the use case correctly, the idea is to say that the request is to have the patient fill out the questionnaire, not that the service request is the result of filling out a questionnaire. Am I reading that wrong?
Eric Haas (Dec 12 2017 at 16:46):
you are indeed right. I have removed my suggestion
Bryn Rhodes (Dec 12 2017 at 16:48):
It seems like an extension to ProcedureRequest referencing the Questionnaire would work, and we've needed to do this often enough that it seems like a tracker to add this ability to ServiceRequest in R4 would make sense.
Eric Haas (Dec 12 2017 at 16:53):
I was just about to suggest the same as a standard extension. I think most services are picked from a catalog - ie a code. Unless the catolog folks (@Jose Costa Teixeira @Lorraine Constable ) are thinking we would be referencing the entry directly then I think code|reference(CatalogEntry|Questionnaire|OtherDefinitions)
Jose Costa Teixeira (Dec 12 2017 at 17:09):
The way I read the problem it is like:
We are requesting a procedure.
Part of that procedure is to fill in a questionnaire
That questionnaire is already available/defined.
Is that it?
Lloyd McKenzie (Dec 12 2017 at 17:31):
So the question is whether the order instantiates the protocol or the event resulting from the order instantiates the protocol - I'd always assumed the latter
Lorraine Constable (Dec 12 2017 at 17:48):
As an aside, we CatalogEntry is now EntryDefinition
Raheel Sayeed (Dec 12 2017 at 19:03):
I was just about to suggest the same as a standard extension. I think most services are picked from a catalog - ie a code. Unless the catolog folks (@Jose Costa Teixeira @Lorraine Constable ) are thinking we would be referencing the entry directly then I think code|reference(CatalogEntry|Questionnaire|OtherDefinitions)
This seems perfect for my usecase: https://www.hl7.org/fhir/extension-procedurerequest-questionnairerequest.html
Last updated: Apr 12 2022 at 19:14 UTC
