Stream: social
Topic: Ephermeral resources
Andy (Jan 30 2019 at 00:49):
How bad is it to generate ephemeral resources in a search result? we're searching a system that aggregates underlying data into a fhir model, but there's no actual ID to associate with all of that information, except the query string
Grahame Grieve (Jan 30 2019 at 01:16):
what do you need to do with the id?
Andy (Jan 30 2019 at 01:18):
In this case the it's because i'm returning a resource that has a Patient, with _include=Patient, and need a way to link them up
Grahame Grieve (Jan 30 2019 at 01:18):
just within the request?
Lloyd McKenzie (Jan 30 2019 at 01:20):
In the future, this sort of question is best raised on #implementers. Social is non-implementation related stuff.
Andy (Jan 30 2019 at 01:20):
the response has [{ resourceType: "other", patient: { reference: "Patient/Ephemeral_ID"} }, { resourceType: "Patient", id: "Ephemeral_ID" }]
Andy (Jan 30 2019 at 01:20):
and it's so the client can link them up. is this ok in fhir? (noted @Lloyd McKenzie )
Lloyd McKenzie (Jan 30 2019 at 01:25):
There's no resource named "other", so regardless of whether the ids exist or not, it's not legal FHIR. And providing a list of ephemeral ids that can't actually be queried doesn't seem like it's going to provide much value...
Andy (Jan 30 2019 at 17:46):
edit: what the heck is this chat client
Andy (Jan 30 2019 at 17:46):
sorry, "other" was an example of any other resource, say Coverage, that has a patient reference. since they're both coming back in a bundle, with _include=Patient, the client needs a way to follow the reference in a search result
Lloyd McKenzie (Jan 30 2019 at 17:51):
Would the Coverage resources be ephemeral or just the Patients? If so, have you considered a "contained" Patient?
Andy (Jan 30 2019 at 17:56):
in this case they are both ephemeral, in the sense that if we gave them a real ID, we wouldn't be able to link that ID back to anything in our underlying data store
Andy (Jan 30 2019 at 17:57):
the business case is an API that returns information about a patient and coverage from an API in the same response
Lloyd McKenzie (Jan 30 2019 at 18:19):
That sounds like you're doing more of an operation than a query. How are you searching?
Andy (Jan 30 2019 at 18:41):
With query parameters like first name. it doesn't have side effects
Lloyd McKenzie (Jan 30 2019 at 18:52):
If your objective is to let people query as they wish, you can't count on specific search parameters being used and you can't count on data being retrieved using _include. If your objective is to create a defined set of behavior that clients will customize their solutions to talk to, then you're effectively defining a custom operation - so you may as well expose your capability that way.
Last updated: Apr 12 2022 at 19:14 UTC
