Hello all, Lets say that we create an observation from a questionnaireResponse through a Bot. (ex. Weight) Then the user might update the questionnaireResponse (ex. the weight capture was wrong and they need to update it) In that case we need to have another bot that listen's this change and update the previously created Observation Is there a mechanism that we store the related Observation id back to the Questionnaire response in order to easily make the update (Currently the relation between the questionnaireResponse and the Observation is stored only in the Observation, ideally we would like to have this link in the questionnaireResponse side as well) Any ideas?

You can link the Observation back to the QuestionnaireResponse by using Observation.derivedFrom https://www.medplum.com/docs/api/fhir/resources/observation

Thanks for getting back @reshma! In this case though if get an event that a QuestionnaireResponce was updated how will I know which Observation is related with QuestionnaireResponse. I need to make a query to Observations. I was querious if this is efficient and if I should save the Observation resource id somehow in the QuestionnaireResposnse

QuestionnaireResponse.partOf seems like it might be what you need?

I think partOf could be used if a questionnaire response is part of Observation. In this use case we do something similar to the "patient intake form". From what I 've seen in your side you have 2 implementations: 1. through bots: through a bot you map the response to actual the individual FHIR resources like Patient, Observations, Conditions, Consent etc 2. Directly through provider app. I saw this in the provider app code. that you do the mapping from questionnaire response to fhir resource directly from the client. Questions: 1. I am curious which approach do you suggest (Bot vs client) 2. Currently after the Intake form is used you never go back to make changes there. In my example (when I started this thread), I wanted to know if you can some how we are able to open the form, edit it, and propagate the changes to the respective resources. Hope my long message make some sense 🙂

Hey @Thanos Vidakis , good question! Question 1: I think it depends on the complexity of your form and resources that you are creating. I would actually say that there are three ways to do this. 1. Handling the creation of resources from QuestionnaireResponse directly on the client side If you handle the creation of individual FHIR resources on the client side, you can confirm whether each individual resource is successfully created and display more specific error messaging if something fails. I'd recommend this approach for very simple Questionnaires that don't require fetching any other information or updating extra resources. 2. Handling the creation of resources from QuestionnaireResponse with a Bot, executed synchronously from the client You will know in the Bot's response whether it an error was thrown or not based on the success of the Bot execution, and this is a good modular approach where the Bot handles all the work instead of your frontend, but is slightly more challenging to debug and handle any errors. 3. Handling the creation of resources from a Bot that is Subscribed to QuestionnaireResponse, executed asynchronously I'd recommend this approach for intake workflows with higher levels of complexity because your frontend will not need to wait for all the patient intake work to be processed by your Bot. But, you can't be 100% certain that everything succeeded in the bot execution.

answer to Q2: yes but somehow you need to make the connections of which resource to upsert.

When a user goes back to update something in their patient intake questionnaire, you should create a new QuestionnaireResponse resource, not update the existing one. The QuestionnaireResponse resource is typically considered immutable or write-once in standard FHIR usage patterns because they represent a snapshot in time, so the best practice is always to create new QuestionnaireResponses and Observations. You could always pre-populate a user's intake questionnaire with any resources that may exist that are connected to the Patient. I don't think it is worth trying to keep any resources created tied back to the QuestionnaireResponse. Does that make sense?

Yes it does! 🙂 I ll sleep on it! Just to be more specific about our use case: i was thinking to model Clinical examination through a questionnaire. (lets say pediatrician) each time they see a child in clinic they measure weight and height (plus other variables) lets say that we have those to questions in the questionnaire and the doctor answers the form once. (every time the doctor see a child creates a new examination form) In our use case we would like to store also wight and height as observations What if the doctor makes a mistake and want to change the submission of this questionnaire response? Do we create a new one? if yes how we differentiate this one for a totally new visit/examination And how we will make sure that we will change the wrong weight value? Should we go through the questionnaire or suggest the doctor to go and edit the final weight/observation resource?

Still, I think you should use multiple QuestionnaireResponses. You could link each of those QuestionnaireResponses to an Encounter resource that represents each "visit/examination". So you would know which QuestionnaireResponses are new or a revision for example. So for a single Encounter, you could have something like

// Original response (now marked as error)
{
  "resourceType": "QuestionnaireResponse",
  "id": "exam-response-1", 
  "encounter": {"reference": "Encounter/visit-123"},
  "status": "entered-in-error",  // Key status
  "authored": "2025-05-28T10:30:00Z"
}

// Corrected response  
{
  "resourceType": "QuestionnaireResponse", 
  "id": "exam-response-2",
  "encounter": {"reference": "Encounter/visit-123"}, // Same encounter
  "status": "completed",
  "replaces": [{"reference": "QuestionnaireResponse/exam-response-1"}],
  "authored": "2025-05-28T11:15:00Z"
}

"And how we will make sure that we will change the wrong weight value? Should we go through the questionnaire or suggest the doctor to go and edit the final weight/observation resource? " This is up to you. But generally, if you have a bunch of business logic in your QuestionnaireResponse processing code, and you don't want to confuse the doctor with multiple places to update things, going back to the questionnaire is a good approach. You can always pre-populate it with the last values you filled in

Thanks a lot for the comprehensive answers @finnbergquist ! 🙂 I think what you re describing seems to be the way to go. Will try some of this and I might get back 🙂 Thanks again!!

Sounds good!