When is a search query in FHIR not a GET request?
When it’s a POST request and you use the _search endpoint.
I worked with FHIR for a year before I knew it was possible to run search queries as POST requests.
At first I couldn’t see a use case for this, but when I considered the sensitivity of the data that can appear in search queries a use case quickly emerged.
Developers have a habit of logging everything.
An API call comes in, we log where it came from. A long and detailed query string? We log it, just for reference.
The problem with this in a healthcare setting is that some of the data coming in as part of FHIR queries could be and often is PHI or PII data, which should never be written to causal log files.
- Patient names and dates of birth
- Identifiers such as social security or medical record numbers
- Conditions and medications
Sending the query as a POST request reduces the likelihood of values like these ending up somewhere they shouldn’t.
A second reason is that sometimes you need to run long queries. This is common if you’re running a query in response to the results of a previous query. You may want to get 100 specific Patient resources using the Patient’s FHIR ID as the parameter. The query would look like this:
Patient?_id=5d0e992f-8b8d-49ff-a7e5-982562626408,16cf3420-b0ce-4baa-a0ad-a7005b405176,e27e93a6-49da-479c-a3b1-7306b13686f6
With 100 GUIDs instead of just 3. This will quickly exceed the maximum size for a URL and your query will return results missing a number of patients.
A POST search lets you pass those 100 GUIDs as part of the request body, keeping the URL size small.
Here’s an example in Postman:
- The _search endpoint identifies the POST request as a search query.
- The query parameters are sent as form encoded data.
- The results are returned in a recognizable bundle.
There is no difference in the behavior of the query once it is received by the FHIR server. The returned bundle is the same as it is for a GET request.
---