FHIR is not SQL.
In SQL you can build complicated queries that span multiple columns and tables. In FHIR, not so much.
Even simple real-world use cases push the boundaries of what’s possible with FHIR query parameters.
Let’s say we want to run a query to identify cases of high blood pressure based on a Diastolic value of over 100. That’s high.
Blood pressure readings are typically stored in a single Observation with two components, one for Systolic and one for Diastolic.
Here’s what that looks like.
You might think that this query will give you what you want:
/Observation?code=55284-4&component-code=8462-4&component-value-quantity=gt100
You’d be wrong. Let’s break it down to see why.
We’re asking for Observations with a Loinc Code of 55284-4 — “Blood Pressure.” All good so far.
Next we’re insisting that the component list contains both a “Diastolic Blood Pressure” value AND a quantity value over 100.
Sounds right.
What we’re not doing is insisting that the “greater than 100” reading BE a Diastolic value. It could be a Systolic value — which is almost always over 100 for a healthy adult.
This is a very real problem, one that can’t be solved using simple search parameters.
For this we need a Composite.
A Composite is a FHIR search parameter that searches across two elements.
Only a small number of composite search parameters exist and many are part of the Observation resource. Here’s what our query would look like using the component-code-value-quantity search parameter.
/Observation?code=55284-4&component-code-value-quantity=8462-4$gt100
The $ sign separates the two values we’re searching for in the query string and joins them together into a single search parameter. It ensures that both values exist in the same Observation component.
But not all FHIR servers are equal. This is noticeably true in their ability to handle composite searches.
The above query ran successfully and as expected on Firely and Azure servers, but was unsuccessful on other public servers.
More about composite search parameters.
---