FHIR queries can look insanely complex

They’re not. Once you understand the three scenarios that encompass most FHIR queries, writing them gets a whole lot easier.

Let’s use Encounter as an example.

Scenario 1
I know exactly what I want. I want this specific Encounter.

Sample query: /Encounter/ID-123456789

Scenario 2
I know roughly what I want. I want all Encounters that meet this set of criteria. (this year)

Sample query: /Encounter/?date=ge2023-01-01

Scenario 3
I don’t just want Encounters. I also want specific resources associated with those Encounters. (Patients and Observations)

Sample query: /Encounter/?_include=Encounter:patient&_revInclude=Observation:encounter

Scenario 1 is easy. You already know the FHIR id. You simply add it to the query string.

Scenario 2 is where complexity can live. Build up your search criteria one parameter at a time, testing as you go in Postman or Insomnia.

Scenario 3 is easy. You use _include or _revInclude to get resources linked FROM or TO the Encounter.

You’ll find that most queries you work with will be a combination of scenarios 2 and 3.

More about FHIR search: http://hl7.org/fhir/R4/search.html

And then there’s search modifiers — but we’ll leave that for another day!!

Discussion

---

Sign up to “The Tuesday FHIR Sessions” and receive an email every Tuesday where I go deep on a single FHIR topic.