There’s not enough discussion around the dangers of GET requests in FHIR.
It seems like every tutorial or example — even my own — sends PII and PHI data as search parameters in GET requests.
This happens within apps as well, where GET seems to be the default for running search queries.
Here are a couple of example searches for a patient “Roger Fahey”, who I added to a test server earlier, complete with name and social security number.
/Patient?family=fahey&given=roger/Patient?identifier=http://hl7.org/fhir/sid/us-ssn|999-38-4752PII data in both.
Extend the query so that it includes Conditions or Observations and we have the PHI data as well. In the query string, in the clear, linking back to a very recognizable patient.
A few weeks ago I was setting up a FHIR Store on Google Cloud and was surprised to see a warning against using GET request for searching FHIR.
I shouldn’t have been surprised. If anything the surprise should have been that this warning was not more common.
Here’s the problem: When you send a FHIR query using a GET request, you don’t know what’s happening to the query string once it leaves your app.
It could be logged by default. It could be added to a database. It could appear in a Slack channel monitoring server activity.
You just don’t know. The sensitive data is there to be used.
What’s the solution?
Surprisingly, there actually IS a solution, and it’s well documented. But not well talked about.
Use a POST request to the FHIR server’s _search endpoints.
A POST search uses the very same search parameters, populated with the very same sensitive data, but sends them as form encoded data in the request body.
No query strings, no log files, no developer Slack channels.
Here’s what the above queries look like as POST requests.
Like many people, I’ve known about POSTing searches for a long time, but I haven’t used them that often.
This is an important topic that doesn’t get discussed often enough. Ask your team how your app is running search queries.
Your developers should not be deciding what to do here.
---