Stream: implementers
Topic: Searching against [base]
Ken Sinn (Jul 03 2018 at 17:56):
What is the recommended structure of the response when a search is performed against the base URL, i.e.
GET [base]?[parameters]{&_format=[mime-type]}
I was hoping to see some examples of how mixed-type response bundles are structured, but https://www.hl7.org/fhir/bundle-examples.html examples are still in to-do status.
Would it be bad form to have an encompassing bundle, comprised of smaller bundles for each resource type? Or is it preferable to have all resource results in a flat bundle?
Considering it from an implementer's perspective, there might be a preference to have each resource type within its own bundle, but very interested in the community's thoughts on this.
Thanks!
Lloyd McKenzie (Jul 03 2018 at 18:50):
All the resources must be flat in the root Bundle
Lloyd McKenzie (Jul 03 2018 at 18:50):
The only time you'll see Bundles as the entries in a searchset is if your search includes results from the Bundle endpoint
Grahame Grieve (Jul 03 2018 at 20:11):
where's the todo status?
Ken Sinn (Jul 03 2018 at 20:34):
https://www.hl7.org/fhir/bundle-response-medsallergies.xml.html
Ken Sinn (Jul 03 2018 at 20:34):
https://www.hl7.org/fhir/bundle-response-simplesummary.xml.html
Ken Sinn (Jul 03 2018 at 20:46):
In our particular scenario, we have separate DB repositories each for Observations, Immunizations, and MedicationStatements. Each of these exist as a separate API endpoint at the moment, each providing their own bundled searchset responses.
If we want to offer a consolidated [base] endpoint for consumers, does that mean we need a middle layer to call each of these repositories, unpack the response bundles, and repack them into a flattened bundle for the ultimate response? Are there any other options, e.g. using a bundle of bundles? I didn't see anything in the FHIR spec explicitly forbidding this (as opposed to nested contains, which are strictly forbidden).
Lloyd McKenzie (Jul 03 2018 at 21:04):
Search results need to be returned consistently or systems won't be able to process them. When you respond to a query,you're acting as though all of the data resides on your server. The actual organization of the data is opaque to the recipient. All of the URLs need to be expressed as though the data is local. If you feel that's not clear from the current specification, please submit a change request and we'll make things more explicit.
Grahame Grieve (Jul 04 2018 at 18:06):
All of the URLs need to be expressed as though the data is local
Grahame Grieve (Jul 04 2018 at 18:06):
umm?
Grahame Grieve (Jul 04 2018 at 18:06):
because why?
Grahame Grieve (Jul 04 2018 at 18:06):
the rest is true, and you'll need some kind of middleware / proxy to return a search as the client expects.
Lloyd McKenzie (Jul 04 2018 at 18:30):
So when you query endpoint 1, you can get results from endpoint 2?
Grahame Grieve (Jul 04 2018 at 19:40):
sure. we've never said you can't do that, and there are solutions out there doing that
Lloyd McKenzie (Jul 04 2018 at 19:42):
Do we call attention to the fact that it is allowed anywhere? Because some people might find it surprising. (I did :))
Grahame Grieve (Jul 04 2018 at 19:51):
I don't think so
Lloyd McKenzie (Jul 04 2018 at 21:25):
Ken Sinn (Jul 05 2018 at 14:53):
Thank you Graham, Lloyd for your input!
Ken Sinn (Jul 12 2018 at 20:29):
At the end of https://www.hl7.org/fhir/search.html#_type, there is a statement "In other contexts, searches on multiple types may allow resource specific search parameters" regarding searching against the [base_url]/ without specifying any resources.
Could @Grahame Grieve or @Lloyd McKenzie elaborate on the phrase "in other contexts"?
Would a server be allowed to define an endpoint as <http://sampleorg.com/fhir/STU3/?patient.identifier=9900123> , where all resources (of all types) that have search param "patient" would be returned? We know that [baseurl/Patient?$everything exists, but that requires both context-setting as well as returning a Patient resource.
Thanks!
Grahame Grieve (Jul 16 2018 at 00:34):
i'm not sure what 'in other contexts' means in that sentence. I think we're saying that implementers should experiment and make proposals to us regarding this
Ken Sinn (Jul 19 2018 at 19:07):
Thanks, Graham. To your knowledge, would enabling a global search via GET [BASE], allowing for patient identifier search param, break any established FHIR rules?
For example: GET [BASE]?patient.identifier=someuri|910302, returning all resources (of all types) that contain a patient/subject with identifier someuri|910302?
Or was the "in other contexts" on https://www.hl7.org/fhir/search.html#_type specific to the use of _type, and not applicable to the global GET [BASE} search?
Thanks!
Grahame Grieve (Jul 19 2018 at 20:36):
I'm not sure whether that 'breaks any established rules' because I'm not quite sure what the context of the question is. We could not define that without breaking our own rules about what we'll define, but I think that an implementer could define that as an extension. but it is outside what most servers expect - feedback has been strong that system wide searches like this across all resources are very diffiicult, which is why we are explicit about what parameters can be used across multiple resources
Ken Sinn (Jul 19 2018 at 21:23):
Specifically, we want to allow for the global search "GET [BASE}?" with patient.identifier as a search parameter. We're worried that would conflict with statement "When searching all resources at once, only the parameters defined for all resources can be used." (but we were not sure if this may be allowed based on the statement "In other contexts, searches on multiple types may allow resource specific search parameters.
We wanted to confirm that allowing for this search parameter for a global search was not explicitly non-conformant.
Grahame Grieve (Jul 19 2018 at 22:39):
I think that given that wording, it is non compliant if you don't enumerate the types.
Grahame Grieve (Jul 19 2018 at 22:40):
but I think you want Patient/$everything - that's what it sounds like. have you looked at that?
Ken Sinn (Jul 20 2018 at 12:42):
Yes, we have looked at Patient/$everything, but we currently do not serve up a Patient resource yet. Additionally, Patient/$everything (and Patient/[id]/$everything) rely on either the setting patient context or on obtaining the logical ID -- we were hoping to enable access through a patient.identifier parameter instead. We're assessing out different options at this point. Thank you!
Grahame Grieve (Jul 20 2018 at 12:47):
we've not really discussed doing patient $everything by id .... but it's certainly problematic not have patient...
Ken Sinn (Jul 20 2018 at 14:01):
The documentation documents the format as "[base]/Patient/[id]/$everything".(https://www.hl7.org/fhir/patient-operations.html#8.1.18.2) .
Last updated: Apr 12 2022 at 19:14 UTC
