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
---
Sign up to “The Tuesday FHIR Sessions” and receive an email every Tuesday where I go deep on a single FHIR topic.