FHIR Searching using POST

Another little thing that has some up as we implement our FHIR services is what HTTP verbs you can use when submitting a query. The ‘usual’ way to do this is with the GET verb, but the spec states that it is also legitimate to use a POST to the _search endpoint, with the parameters as an x-multi-part-form submission in the POST body.

In DSTU-1, it states that this mechanism is ‘allowed’, whereas in the DSTU-2 candidate it has become a SHALL – i.e. you will have to support it.

The (DSTU-2) spec simply states:

Because of the way that some user agents and proxies treat GET and POST requests, in addition to the get based search method above, servers that support search SHALL also support a POST based search:

But there’s a more important reason. Some implementations forbid anything that could be construed as Personal Health Information (PHI) – such as query parameters – to be in the URL, as that is sent in clear text even across a secure (SSL/TLS) connection (as well as being stored in server logs and proxy servers). In contrast, the POST body should not be visible to an interceptor.

I do think that the SHALL is a bit harsh, and that a SHOULD would be sufficient, but doubt that it will get changed! (and I guess I can understand why…)

So there you are. If, as a client, you don’t want your query parameters to be in the search query, then you can use a POST to _search instead – and a FHIR compliant server must support it.

UPDATE: I was not correct in saying that query parameters are visible over TLS – they are in fact encrypted. Nevertheless, they will often be logged in server logs at the recipient, and so remain frowned upon by some.