Stream: questionnaire
Topic: Linking PHD data to Questionnaire Response
Brian Reinhold (Nov 01 2021 at 14:07):
@Brian Postlethwaite @Eric Haas @Lloyd McKenzie (Picking on the Questionnaire and SDC experts here) What would be the most reasonable way to compose a question that asks a user to take a measurement with a Personal Health Device capable of communicating with a gateway? The idea is to auto-populate the questionnaire response (QR) with the requested measurements as well as link the response to the Observation resources generated from the PHD.
It may sound redundant to have both auto populated values in the QR as well as links to the list of Observation resources, but for most, the auto-populated values will be sufficient but the link to the Observation will provide much more detail including links to the Device resource containing info about the PHD. It may be the case that auto-population stops if more than X Observations are generated.
I also have the issue that some PHDs generate numerous measurements and may have stored measurements. Not sure how such questions are to be posed.
I have been looking at SDC for some help here; what profiles/workflows/ etc. that I could reuse. I did not find anything about linking generated Observations to a QR.
Lloyd McKenzie (Nov 01 2021 at 16:03):
What is the purpose of using the QR if you're gathering the data automatically? Why not directly from Device to Observation? Observation can link to a QuestionnaireResponse using Observation.derivedFrom
Brian Reinhold (Nov 01 2021 at 19:16):
@Lloyd McKenzie My understanding is that taking a measurement will be part of a Questionnaire, and when that request comes, the patient will take the measurement and the values will be auto-populated into the answer. There is a lot more in the Observation, including links to the Device and Patient. The information entered into the QR is just a summary (say just the Blood Pressure Value). For most that is sufficient. For those who need more information or want to investigate further, the QR answer would also reference the relevant Observations. This would be in the context of remote patient monitoring.
Does that make sense?
Lloyd McKenzie (Nov 01 2021 at 20:18):
There's no mechanism to allow autopopulation of the answer into the Questionnaire other than allowing the user to go out and search for them or to close and re-open the QuestionnaireResponse and hope that auto-population recognizes the newly existent data. My question is "why do you need a Questionnaire at all?" Is the patient reviewing/editing the information to be submitted?
Brian Reinhold (Nov 01 2021 at 22:03):
@Lloyd McKenzie
My understanding is that the measurement by the device is only part of the questionnaire. The remote patient also has additional questions posed by the clinician to be answered. One of the questions or requests is to take a measurement with a device. This is a communicating device. The device data gets populated into the response. (Auto population is not the problem - I can already do that but I am not sure how the question would be posed and therefore how the answer would be structured). Would it just be a simple set of valueQuantities as if the user had a non-communicating device and had to enter the results manually? I would also like to provide a reference to the Observation generated by the device in that answer. Not sure how to pose that in the Questionnaire.
Lloyd McKenzie (Nov 01 2021 at 22:18):
There's no mechanism for a device to know what QuestionnaireResponse to put the data into, let alone a safe way for a device to interact with an in-memory QuestionnaireResponse at the same time the user is reviewing/editing it. There's also no mechanism (as yet) to 'invoke' a device to answer a particular question. The closest we have is the auto-populate functionality defined in SDC. However, that typically runs at the launch of the editing process, and only re-runs if there are dependencies on other questions - it doesn't monitor continuously for new data coming into existence.
The best bet is probably to use the candidateExpression extension to allow the user to choose from a set of candidate Observations to choose the one(s) they want included as answers to the QuestionnaireResponse. If you wanted to have additional 'calculated' questions that grabbed the answers from those observations, I suppose you could. Do keep in mind that when a QuestionnaireResponse references an Observation, it doesn't generally 'contain' the Observation. I.e. the submitted QuestionnaireResponse will contain a reference to the Observation, not a copy of the Observation.
Brian Reinhold (Nov 04 2021 at 13:18):
@Lloyd McKenzie Thanks for the response. I was thinking of a 'canned" question which would ask the user to take a measurement. The canned question would have (hidden) codes that would indicate what measurements are to be reported into the questionnaire response. Not exactly sure how to have those entered by the Q creator. The canned question would also have a second (hidden) question asking for a reference to the Observations corresponding to the requested measurements, The final questionnaire Response would be uploaded to the server in a transaction bundle containing both the QR and Observations with the links to the logical id (temp ids to start with). Being rather ignorant about the who Q and QR system I am going to have to do some serious investigation.
Users in the field want something like this - asking patients to take measurements and auto-reporting the results in the QR as well as links to the Observations. 90% of the consumers of the QR will find just the reported measurements in the QR sufficient. For those that need more, they would have to retrieve the Observation resources and other resources that the Observations reference (Device, Patient, other Observations).
Lloyd McKenzie (Nov 04 2021 at 18:16):
Nothing is going to be done by the form filler software that isn't at the direction of the user or isn't automatically populated on launch of the Questionnaire. There's no ability for a form filler to go and grab data that didn't exist at the time the form was launched without a user actively selecting the records.
That doesn't mean we couldn't design something that allowed a user to say "please try populating again" - but they're going to want to have a visual indication that it worked.
What are you plans for 'submitting' the QuestionnaireResponse? Capturing it as the Task.output or using the $submit? The latter doesn't support submitting referenced resources. For the former, you could query them, but they're not necessarily 'pushed'.
Brian Reinhold (Nov 04 2021 at 19:27):
@Lloyd McKenzie At this stage I am just trying to see what options exist. In Denmark they are using Questionnaires (as CDAs) to ask more than just questions, for example giving COPD patients instructions to do something, wait N minutes, repeat something, among several other instructions. They also request measurements be taken by the patient and use a proprietary approach to link the generated Observation to the QR. We are interested in supporting this type of scenario using FHIR and the PHD IG.
Given that, are 'instructions' okay to have in a Questionnaire?
Lloyd McKenzie (Nov 04 2021 at 23:26):
A Questionnaire is a list of items. Some of the items can be display items and can provide instructions. And you can have check-box questions that allow the user to indicate if they did something or not. A user can certainly answer a question by looking up an Observation and selecting the Observation as an answer. But there's no mechanism to have the rendering tool do that automatically other than at form launch.
Mikael Rinnetmäki (Nov 05 2021 at 08:31):
@Brian Reinhold not sure whether this helps, but we've been looking at a similar topic. As app developers, we think of the whole service path, and are not constrained to thinking of the whole process as a Questionnaire. So we can start with an initial Questionnaire and gather the QuestionnaireResponse, and when the time comes (in the logical flow), we move to another part of the app that guides people to upload data from their devices, which are then stored as Observations. After that, we move to a new Questionnaire (or even the same one), and now auto-populate some responses based on the newly available Observations.
Mikael Rinnetmäki (Nov 05 2021 at 08:31):
So, more logic built into the app. We haven't even tried to formalize all that within a Questionnaire.
Brian Reinhold (Nov 08 2021 at 15:11):
@Mikael Rinnetmäki We would like to integrate the process such that the questionnaire might request the patient to take a measurement with a communicating personal health device (PHD). There would be some information in the questionnaire that the application would use to auto-populate the QR with the requested measurements from the PHD. That information would likely be a set of MDC codes which would identify to the application the type of device and the measurement types to be reported. IN addition, we want to link the generated Observation to the QR. This would give the primary data in the QR for the 90% use case and everything you wanted to know about the Observation and Device that generated it for everyone else.
How to integrate those codes and requests into the Questionnaire such that the application can use that data is an unknown. Of course the patient has to take the measurement but once that is done (assuming the application supports the PHD IG and can communicate with PHDs) if the codes are available, there will be no problem auto populating the QR and generating the link to the Observation resource(s).
Lloyd McKenzie (Nov 10 2021 at 15:10):
Happy to see discussion here about possible approaches. We can also talk about it on our Questionnaire call next Thursday.
Raheel Sayeed (Nov 10 2021 at 16:40):
We didn't use automated capture, but our approach involved a ServiceRequest to the patient to use a PHG/PHD resulting in an Observation. And then another ServiceRequest to complete a Questionnaire automated with data from the Observation.
Brian Reinhold (Nov 13 2021 at 15:24):
@Lloyd McKenzie Can you send me an email with a link to this meeting? I would like to get involved. brianreinhold@lnihealth.com
Thanks
Lloyd McKenzie (Nov 13 2021 at 20:21):
@Brian Reinhold The call details can all be found here: https://confluence.hl7.org/pages/viewpage.action?pageId=40743450
Brian Reinhold (Nov 15 2021 at 14:30):
@Lloyd McKenzie Thanks - 5-6 pm thursday EST
Lloyd McKenzie (Nov 15 2021 at 16:55):
y
Diane (Nov 18 2021 at 23:18):
Can you use a series of questionnaires?
Questionnaire #1 Based on your answers above, we need you to take a PHD measurement. Take your measurement and then press Submit to get the next form to help you decide what to do next.
PHD sends the measurement back as a separate QuestionnaireResponse (not as an Observation), based on the form definitions of a Questionnaire #2.
Questionnaire #3 uses x-fhir-query to bring in data from Questionnaire #1 as variable A and data from Questionnaire #2 as variable B then uses initialExpression or calculatedExpression to populate Questionnaire #3. The user can answer more questions and then submit Questionnaire #3.
If an observation is needed, then it can be generated from Questionnaire #3.
Alternatively, you can update Questionnaire #1 with the PHD measurement using PATCH.
Brian Postlethwaite (Nov 18 2021 at 23:28):
The use case I was considering was more around if there is a pre-pop rule for an observation (observationLinkPeriod), then if it doesn't exist, provide the user a way to enter one, then re-fire that specific initialExpression for that item.
Brian Reinhold (Jan 26 2022 at 20:06):
@Brian Postlethwaite I understand the role of the 'code' extension in the examples above, but I am still confused how the renderer is to use the 'name' extension. Do you have ideas on how to get its use in this scenario through my thick head? I thought that maybe I could place a FHIR path as the String which would point the renderer to the element in the resource that has the desired result. So it assumes that when the question is first asked, the resources do not exist, but after the measurement is taken the resource does exist and the fhir path will get you it.
But my understanding is that we cant put a FHIR path in the String.
Assuming the code and name extensions are all we need, what would be the best placing be? I can see an array of extension pairs on the group item, or a single pair of extension for each item.
Lloyd McKenzie (Jan 26 2022 at 20:31):
The name is just a name. Think of it as a variable name. That name will then be used in FHIRPath or CQL appearing in 'expression' extensions nested deeper in the Questionnaire.
Brian Reinhold (Jan 26 2022 at 20:48):
@Lloyd McKenzie I think I need to see it work in practice to get this through my thick head; an actual example of it functioning.
Lloyd McKenzie (Jan 27 2022 at 00:24):
Have you looked at the other population examples?
Brian Postlethwaite (Feb 06 2022 at 23:13):
I think what I'm trying to say is that this doesn't feel like standard behaviours that you'd expect from any generic renderer and would be specific to your implementation.
(I don't believe that we're likely to implement this, and not expexcing that lhforms would do this either)
So you're kinda free to do what you please with your own extensions.
We've made some suggestions on what considerations you might put into your extension design, such as if it should always get a new measurement, etc. Or even if it needs to record the actual thing and attach later on.
It's feeling very application specific to me.
Last updated: Apr 12 2022 at 19:14 UTC
