Stream: implementers
Topic: More controlled inclusion of additional resources in a searc
Michael Calderero (Nov 15 2018 at 09:51):
Hello All,
We have the following use cases below:
1. Get list of patients (possibly with filters e.g. name starts with Y); for every patient get latest 3 upcoming appointments and also get the doctors associated with those appointments
2. For a patient, get the last N observations of code Y for device Z; for every observation get associated encounter
We imagine the two use cases are achievable by firing a bunch of search queries against the REST API and letting the app have some custom logic for each use case, but wanted to cut down on the number of requests to the FHIR server ideally to just one.
- We could use _include and _revinclude but wanted to be in more control of what gets included. E.g. for use case 1, _revinclude'ing the appointment to the patient can be done but I believe we can't specify to filter it to just the latest 3 upcoming apointments (the app will have to filter this out)
- We're not very familiar with GraphQL to determine if this is something that could be achieved with one GraphQL query
- We've looked at GraphDefinition and it seems to come close to doing what we want, but I couldn't figure out if I can sort on a link and filter only the top 3 resource links returned in order to satisfy the e.g. "latest 3 upcoming appoinments" part of use case 1
We could probably implement a custom operation to do just this and make it generic enough so it works with any resource, but wanted to ask here first to determine if someone else already did this before using the FHIR-defined resources, operations, etc.
Lloyd McKenzie (Nov 15 2018 at 10:10):
You should be able to do what you need with only two interactions. The first queries for the list of patients - from which you get a list of patient ids. The second is a Batch of queries, one querying appointments per patient with an _include on Practitioner and the other querying observations with an _include on Encounter. The benefit of doing that rather than a custom operation is that servers and clients are more likely to support the capability without any customization (which should always be your objective if you want to keep implementation costs and timelines small).
I can't speak to how well GraphQL could meet your requirements
Grahame Grieve (Nov 15 2018 at 13:10):
you can do either using graphql or graphdefinition
Last updated: Apr 12 2022 at 19:14 UTC
