Stream: Argo Patient Lists
Topic: using operation to fetch additional data
Eric Haas (Oct 07 2020 at 20:59):
I had an epiphany while in the shower... since the QR are created on demand, I recommend using the SDC defined operation http://hl7.org/fhir/uv/sdc/OperationDefinition/Questionnaire-populate
Then can use the Q reference from the extension + the Patient id to fetch the QRs avoiding having to add all those pesky extensions on the members.
On the server side behavior is basically the same since are creating on demand QRs anyways and is purer in the sense that is not truly a RESTful Search. On the downside the patient Reference type means it needs to be a Post + Parameters and is not an out of the box search operation that is universally supported.
or... using a new operation that combines the
Bundle in the Group Fetch using that solves the updating the patient list and QR results separately.
Also need a way to discover if PL comes with a Q ...
Josh Mandel (Oct 07 2020 at 21:08):
Interesting! (I need to stop listening to the news in the shower -- depressing and it stifles random epiphany time.)
That said: do we want to commit to "on demand" creation? I was expecting some servers would pre-generate (perhaps at intervals) others might generate and cache; others might generate fresh every time... what's the advantage of locking in a "generate on demand" requirement?
Josh Mandel (Oct 07 2020 at 21:09):
We also talked recently about servers using pagination of search response bundles as a place to enforce rate limiting -- I think you lose this with a custom operation too.
Eric Haas (Oct 08 2020 at 18:54):
I assumed on demand will be the common use case, but I am not fussed if stick to GETs. Are we comforatble with a 1:1 Q to Group?
Isaac Vetter (Oct 23 2020 at 22:17):
Eric, would this operation allow for the requesting of multiple QRs at the same time? Or would it be one patient's QR at a time?
Last updated: Apr 12 2022 at 19:14 UTC
