Stream: implementers
Topic: GCP Search via request body
Hue Nguyen (Sep 12 2020 at 08:41):
Hi, My name is Hue.
I'm using GCP Healthcare API
I wanna do FHIR search via request body.
For example, I have 100 Patient IDs from 1 to 100 and name= Jame condition. How can I search on 1 request?
- Id is uuid with 36 character. That mean 100 ids will be 3600 character
- maximum URL length is 2048
If we can not search via request body, do you have any solution for it?
Looping: @Paul Church
Vassil Peytchev (Sep 12 2020 at 13:20):
Did you try searching using POST?
http://build.fhir.org/search.html#Introduction
Lloyd McKenzie (Sep 12 2020 at 13:59):
You can also consider using Batch.
Paul Church (Sep 12 2020 at 14:46):
We don't support POST search parameters in the request body at the moment. We support read but not search in a batch bundle - search is feasible but we haven't seen much demand for it yet.
In general I suggest designing the search to use an attribute of the resources instead of a large list. If there isn't a criterion that selects these 100 patients, perhaps an artificial attribute like meta.tag. If you need to retrieve a lot of resources by ID alone, a batch bundle of read operations will work and can be very large.
Hue Nguyen (Sep 12 2020 at 15:00):
@Paul Church
I wanna make a search query with Patient.name, Patient.phone, Encounter.practitioner.
Query will like <basepath>/Encounter?practitioner={id}&subject:Patient:name=xxx&subject:Patient:phone=xxx
But GCP has a problem when search with Japanese characters (jp characters is too short and can't set index for it).
So, I'm trying to use Elastic search for Japanese characters search => and will get list of IDs
Then, new query will be:
<basepath>/Encounter?practitioner={id}&subject:Patient:_id=111,222,43333....
Do you have any suggestion for this case
Paul Church (Sep 17 2020 at 19:49):
Sorry for the delay. My only suggestion for this case is to split into smaller queries.
We are tracking POST _search with the parameters in the request body as a future enhancement but it's likely that substring search on 1-2 character words will be fixed earlier than that.
Hue Nguyen (Sep 23 2020 at 07:17):
Thank you. Let's me try
Brian Forbis (Dec 10 2020 at 19:56):
I have a sort of related question regarding 2048 character limit on URLs. I understand that using POST based search could avoid that on the way into the server, but wouldn't this still cause problem for bundle link entries (self, prev, next, etc) in the returned bundle?
Paul Church (Dec 10 2020 at 22:13):
Yes, I would think we'd have to give you a link.next URL with query parameters that is too long, but you could reinterpret it into a POST body. Not sure what other servers do about this.
Brian Forbis (Dec 10 2020 at 22:15):
I think returning a URL that cannot be served by a GET request is invalid? Is that correct?
Paul Church (Dec 10 2020 at 22:18):
The only language I'm aware of is "In the case of a search, the initial request may be made via a POST, but the follow up page requests will be made via GET requests. However servers SHOULD allow for a client to convert the follow up requests to be made via a POST."
This seems unhelpful in the case where the search parameters are too long to be served by a GET.
Brian Forbis (Dec 15 2020 at 15:36):
Perhaps this is something that just needs to be documented by each individual implementation? It seems that most servers support somewhere between 4k-8k max header size (which also applies to query args), so the 2048 limit is just for browser URLs which I think doesn't really apply here since these are APIs. Here's a list of popular servers and their default size limits. These settings are usually adjustable, but they are set to that size specifically to avoid DoS attacks.
As far as returning a link that the server would reject if it was made via GET, but accept if it was made via POST, I'd still like to know whether that could be considered acceptable per conformance standards.
Last updated: Apr 12 2022 at 19:14 UTC
