Stream: questionnaire
Topic: SDC Extraction to populate QuestionnaireResponse.subject
Miriam (Oct 16 2019 at 23:42):
SDC form data extraction guide says that "Extraction is a step that only makes sense to occur once a QuestionnaireResponse is completed." Meaning: QR has status "completed" (or possibly "amended"), I think.
When saving the "in-progress" QR prior to doing extraction, I believe it should conform to the SDC QR Profile. The issue I'm facing is that the profile requires QR.subject field to be present and to reference a Patient resource.
So, in the case where the Patient does not yet exist, extraction must occur before populating the "subject" reference field. Any suggestions on how to handle this? I could create a dummy reference that is unresolvable, or not apply the SDC QR profile until extraction is completed, but both those options seem hacky.
Lloyd McKenzie (Oct 17 2019 at 00:28):
To clarify, you're generating the Patient resource via extraction from the QuestionnaireResponse? That's certainly something we hadn't contemplated. I'm comfortable with the notion of relaxing the mandatory to just mustSupport and providing usage notes that it should only be absent when context will allow the Patient to be asserted later in the process. Would you be willing to assert a change request @Miriam ?
Miriam (Oct 17 2019 at 00:37):
Yes that's correct. Great, I'll submit a change request and link it here. Thanks @Lloyd McKenzie
Brian Postlethwaite (Oct 17 2019 at 09:00):
I would want to see this too.
Miriam (Oct 18 2019 at 22:04):
Opened #25032
Lloyd McKenzie (Jan 09 2020 at 22:42):
Question came up on today's discussion. The only time 'subject' cardinality of 1..1 comes into play is when you are actually saving the QuestionnaireResponse in a system. You're free to fill out the QuestionnaireResponse and not specify the subject immediately - so long as you declare the subject before you save. The challenges with not having a subject at all are:
- how do you find the QuestionnaireResponse to keep editing it if you can't search by subject? Do we add an invariant that if there isn't a subject there must be an identifier so you could reliably come back to it again?
- how do you enforce patient privacy expectations if the QR isn't tied to a particular patient compartment? Do we just highlight this as a risk if subject isn't declared and maybe have a best practice constraint that subject should be declared?
We'd like to figure out answers to these questions before approving the change.
Brian Postlethwaite (Jan 09 2020 at 22:53):
You could be storing the qrid elsewhere.
Brian Postlethwaite (Jan 09 2020 at 22:54):
(not that I am, but possible, or maybe as a contained resource?)
Lloyd McKenzie (Jan 09 2020 at 23:15):
So the client would just 'remember' the server-assigned id and use it to retrieve? Contained resource would satisfy the mandatory reference, so that's not a reason for loosening it. Thoughts about the security/privacy aspect?
Paul Lynch (Jan 09 2020 at 23:20):
What is there to retrieve before it is saved? It is still in the client being edited, right?
Lloyd McKenzie (Jan 09 2020 at 23:22):
The request is to allow it to be saved with partial data but no subject. The client would presumably then close and re-open it at some future point.
Lloyd McKenzie (Jan 09 2020 at 23:22):
(Though it could also choose to save it for data recovery purposes.)
Paul Lynch (Jan 09 2020 at 23:24):
I don't understand why you would not have a subject (or having one, why it would not be included). Someone filled out the partial data for a particular person, didn't they?
Lloyd McKenzie (Jan 09 2020 at 23:28):
I think the notion is you start filling out the form and fill in the patient data which then gets extracted to create a contained Patient resource. But really, I'm not totally sure. @Miriam can you provide more details about how you envision this working?
Brian Postlethwaite (Jan 09 2020 at 23:40):
Yes, where the QR is being used to create what will become a potential subject. That I think is the real use case there.
Brian Postlethwaite (Jan 09 2020 at 23:40):
Patient admission form self populated from home, and doesn't have a patient resource yet (or access to it)
Paul Lynch (Jan 09 2020 at 23:51):
It looks to me like there are no required fields in a Patient resource. If that is the case, and empty Patient resource could be created when the form is submitted (or even before, when the form is loaded) and set as the subject so that the QuestionnaireResponse can be generated.
Lloyd McKenzie (Jan 10 2020 at 00:42):
The issue is with the SDC profile - which does make several fields required. @Brian Postlethwaite, so the intention is the QuestionnaireResponse is created, extraction is done to create a Patient resource. The Patient resource gets posted (and cross fingers there are no duplicates found) and then the QuestionnaireResponse is updated to point to the now-created Patient and saved?
In the interim, is the QuestionnaireResponse queriable? What patient privacy protections are enforced?
Brian Postlethwaite (Jan 10 2020 at 01:56):
Don't know, creator only?
Paul Lynch (Jan 10 2020 at 16:12):
@Lloyd McKenzie I don't see an SDC profile of Patient listed here: http://hl7.org/fhir/uv/sdc/2019May/artifacts.html
Lloyd McKenzie (Jan 10 2020 at 16:19):
There isn't one. The question is about the cardinality of QuestionnaireResponse.subject
Paul Lynch (Jan 10 2020 at 16:20):
So, I pointed out that Patient does not require any fields, and you replied, "The issue is with the SDC profile - which does make several fields required."
The idea is that one could create an empty Patient, point QuestionnaireResponse.subject to it, and then fill in the Patient during extraction.
Lloyd McKenzie (Jan 10 2020 at 16:24):
You can't have a completely empty Patient - you always have to have at least one populated non-id element.
Paul Lynch (Jan 10 2020 at 16:33):
I see-- "name.exists() or telecom.exists() or address.exists() or organization.exists()".
Then, an app could ask separately for the patient name to get started, create the Patient with just the name, and then provide a Questionnaire (prepoluated with the name) to collect the rest of the information.
Lloyd McKenzie (Jan 10 2020 at 17:07):
Actually a more fundamental constraint - hasValue() or (children().count() > id.count()). However, you're correct that a largely empty Patient resource - perhaps just a narrative that said "waiting for population" would seem to be feasible.
Miriam (Jan 10 2020 at 18:38):
@Miriam can you provide more details about how you envision this working?
After reading your comments, I agree that 'subject' should continue to be required. Paul's suggestion of requiring the user to enter some minimal patient details prior to beginning the QR makes sense.
Brian Postlethwaite (Jan 30 2020 at 10:35):
How about for generic forms that don't contain a subject?
But for this create me a patient form, still think is better with no subject prop entered.
Brian Postlethwaite (Jan 30 2020 at 10:35):
It's then very clear what is going on. No patient (yet, or perhaps never).
It could be an eval form, and the person is deemed not eligible based on the form, and thus no patient created.
Lloyd McKenzie (Jan 30 2020 at 20:52):
How would you manage access control to the entered data in that situation?
Brian Postlethwaite (Jan 30 2020 at 23:11):
It would be a special case, and likely related to the Q definition itself.
Those with access to the intake/assessment desk/feature
Last updated: Apr 12 2022 at 19:14 UTC
