Stream: questionnaire
Topic: Extracted Observations and deleting a QuestionnaireRepsonse
Paul Lynch (May 24 2019 at 18:06):
If I save a QuestionnaireResponse and its extracted Observations, HAPI FHIR does not allow me to then delete the QuestionnaireResponse unless I also delete the Observations (which are associated with the response via the "derivedFrom" field). Is that really the desired behavior?
Lloyd McKenzie (May 24 2019 at 18:09):
I don't think so... @James Agnew ?
James Agnew (May 24 2019 at 18:25):
The public HAPI FHIR server does enforce referential integrity. This seems like good behaviour to me, why would you want to allow people to delete data that other data references?
There is a setting in HAPI FHIR to disable this on self hosted servers though.
I've been thinking it might be nice to have a "delete and cascade" function though to help with cleanup processes..
Paul Lynch (May 24 2019 at 18:39):
In the case, the reason is that I used a Questionnaire for the purpose of creating Observations, and then I wanted to delete the QuesionnaireRepsonse so it didn't show up in the client application. However, I wanted to leave the Observations around for pre-popluation. I am not sure this counts as a real use-case though.
James Agnew (May 24 2019 at 20:12):
If you're intending to delete the QRs, why are you creating other resources with links to it though..? Wouldn't it make more sense to not create those links? Or to use canonical references instead?
Paul Lynch (May 24 2019 at 20:50):
The SDC spec (http://hl7.org/fhir/uv/sdc/2019May/extraction.html) says "Observation.derivedFrom - set to a reference to the QuestionnaireResponse". It looks like QuestionnaireResponses are not one of the resources that have canonical URLs (https://www.hl7.org/fhir/resource.html#canonical).
Grahame Grieve (May 24 2019 at 21:03):
I do wonder what the value of having 'derivedFrom' is if you're going to delete the questionnaire response
Paul Lynch (May 24 2019 at 21:36):
Well, I suppose it lets you know that a certain set of Observations were all generated from the same QuestionnaireResponse.
Grahame Grieve (May 24 2019 at 21:36):
why not keep the QR then?
Paul Lynch (May 24 2019 at 21:40):
I was trying to get rid of clutter. After a lot of testing, my client was showing a large number of QuestionnaireResponses, about half of which had Observations. I wanted to keep the Observations around for pre-population (for further demos and testing). Anyway, I have now changed my delete process to delete any associated Observations first. I just have to be careful not to delete the last QR of its type.
Grahame Grieve (May 24 2019 at 21:42):
so it's a limitation in the resource model. I want you only to show QRs that haven't been post-processed.... but post-processing recording is not a feature of the QR. I guess that I would use tags (Resource.meta.tag) for this use case
Brian Postlethwaite (Jul 17 2021 at 03:58):
The other thing would be when you are Deleting that QR, scan for all those obs, then update them to remove the reference, or update it to derivedFrom.identifier (and maybe update display), rather than derivedFrom.reference.
Then delete the QR, this would give you the best of both worlds, still having the Obs, the "logical link" to the non existing QR, and noQR baggage.
Last updated: Apr 12 2022 at 19:14 UTC
