Not all FHIR servers are equal

Nowhere is this more apparent than in their ability to handle the _elements parameter. Some do, many don’t.

The first FHIR project I worked on involved using the QuestionnaireResponse resource.

Populating a screen with a dozen sets of responses meant handling 70,000 lines of JSON.

Not fun.

What I didn’t know then and do know now is that I could have reduced the size of that response by using FHIR’s _elements parameter.

I could have told the FHIR server exactly what I wanted.

Here’s an example.

Let’s say I want to populate a screen with a list of recent Observations for a single patient.

The base query looks like this:

/Observation/?_sort=-_lastUpdated&_count=10&subject=Patient/11450011

Add in the patient details:

&_include=Observation:subject

Now lets specify the elements I want:

&_elements=Observation.code.text,
Observation.value,
Observation.issued,
Patient.name

Here’s the full query on the HAPI server.

This gives me the text of the Observation code, the recorded value and date, as well as the Patient name.

I also get the resource’s Meta section, id and resourceType by default.

Everything else is left out.

No 70,000 lines of JSON. No 10 mb attachments I don’t need.

But like I said earlier, not all FHIR servers are equal.

Does your FHIR server support the _elements parameter?

More about _elements: https://www.hl7.org/fhir/R4/search.html#elements

Discussion

---

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