Stream: questionnaire
Topic: How to Order/Prescribe Questionnaires?
Koray Atalag (Nov 13 2020 at 02:32):
I'm interested to know how administration of a questionnaire is initiated/triggered from EMRs or other existing operational health information systems. For example if a patient is eligible to be recruited to a program where certain questions are to be scheduled and delivered how would that Order be represented using FHIR. For a minimal use case I'm thinking of using a bundle with Patient and CommunicationRequest resources with some extensions to include things like baseline collection date and system specific Ids etc. Basically I though of putting everything not in Patient resource that would be visit/order specific into CommunicationRequest. Though, I suspect this resource would not be supported by many systems so I was thinking of perhaps using Encounter with some use case specific extensions. Obviously depending on the scope of exchange we might need to add other resources to capture provider, organisation, NOK etc.
What's the best practice on this?
Lloyd McKenzie (Nov 13 2020 at 04:16):
To my knowledge, no EHRs currently support external systems asking users to complete questionnaires. The Structured Data Capture IG and several Da Vinci IGs are trying to introduce such a mechanism, all using Task. It'll probably take a while before that actually propagates into real production environments though.
Koray Atalag (Nov 13 2020 at 07:40):
Thanks for the heads up. In that case does my proposal make sense? We're needing to implement this on this side of Xmas.
Lloyd McKenzie (Nov 13 2020 at 14:13):
CommunicationRequest shouldn't be used for this. You're not authorizing the disclosure of a type of information. You're asking someone to fill out a form. Typically there wouldn't be a Bundle - there'd just be a Task identifying a specific owner (who should do the work), the Task.for would indicate the Patient and one of the Task.inputs would identify the Questionnaire. Task.executionPeriod would indicate when the form should be filled out. The details of the Patient, Practitioner, etc. would be by reference rather than passed all at once. (If you're in an environment where the receiver can't query those, then you may need to look at messaging, but messaging should never be a default choice if you can avoid it.)
Koray Atalag (Nov 17 2020 at 09:10):
Thanks Lloyd. Thinking about the actual semantics I'd say this is not a request or order for a patient to fill out a questionnaire. It is rather a request from EMR to our PROMs solution to add a particular patient to a predefined project. Once the patient is added to a particular project our system defines the questionnaires and the schedule by which they'll be sent out to the patients. In essence this is similar to the ADT A01 type of transaction.
If I breakdown the actions I'm needing:
- Create a new Patient in ePROMs solution (ZEDOC) (if already exists then update)
- Add patient to an existing PROMs project (via an agreed Project Id)
- Set baseline data collection date
It'd be fantastic to get thoughts on how to approach this requirement
Lloyd McKenzie (Nov 17 2020 at 14:36):
Right now, we have a couple of 'enrollment'-related resources, but those are currently specific to coverage/insurance rather than to programs in general, though personally I'd like to see them generalized. (As well, there's a need to transition the notion of 'enrollment response' to just 'enrollment' because sometimes enrollment isn't driven by a request.)
You might start a discussion on the #implementers stream because the program definition and enrollment piece isn't really Questionnaire-specific.
Koray Atalag (Nov 17 2020 at 19:49):
That's great, I was thinking about exactly the same resource but then realised the use case was for insurance. Another one that got my attention is the Measure resource, which includes PROMs in its type description. But I reckon this isn't for an action but rather definitional. I can see the enrolment concept would apply more broadly, for example including things like recruiting patients to a smoking cessation programs or blood glucose control mHealth interventions etc. Not sure if there's already a resource for it specifically but should also apply to patient recruitment to a clinical trial as well
Lloyd McKenzie (Nov 17 2020 at 19:58):
Measure is for defining what information should be collected - it has no notion of "sign-up".
Lloyd McKenzie (Nov 17 2020 at 19:58):
You might experiment with EnrollmentRequest and response, and if they're "close", you can submit a change request to have their scope broadened
Koray Atalag (Nov 17 2020 at 20:00):
yeah makes sense, thanks
Koray Atalag (Nov 17 2020 at 20:06):
I reckon for the time being I can create an an extension for baseline data collection date, which probably in the end will most likely not be part of resource proper anyways. The more I think about this I think it is worth having a dedicated resource for enrolling patients to a program that involves data collection points with certain semantics (e.g. pre-visit, baseline, post-op, 30days follow up etc.). Which I believe could be done via a repeating generic date element and through slicing these tags could be added. That's what I'd do with an openEHR archetype
Lloyd McKenzie (Nov 17 2020 at 20:12):
A new resource is definitely an option too. We look forward to your feedback :)
Kevin Mayfield (Nov 18 2020 at 21:05):
Is their a way to order an assement (serviceRequest) and specify the output to be a questionnaire response.
Or would it be better to send a sdc questionnaire?
Kevin Mayfield (Nov 18 2020 at 21:08):
Is it activity definition
Bryn Rhodes (Nov 18 2020 at 23:23):
Projects I've been part of have typically modeled that as a Task with the Questionnaire specified as an input element
Bryn Rhodes (Nov 18 2020 at 23:24):
ActivityDefinition would be if you want to describe the activity of prescribing a questionnaire, independent of a particular patient (so you could put that as a step in a PlanDefinition, for example).
Last updated: Apr 12 2022 at 19:14 UTC
