Searching for resources is fundamental to the mechanics of FHIR. It is assumed that search operations traverse through an existing set of resources filtering by parameters supplied to the search operation. The FHIR clients send the search request to us assuming that we have the FHIR resources stored somewhere.
The search examples can be as follows
To search for all the procedures in a patient compartment that occurred over a 2-year period:
In Query string, '23' represents the Patient resource ID (Link needed to find the terms) and the date should fall in between 2010-01-01 and 2012-12-31.
If we don't have FHIR resources stored somewhere, we will have to parse the search query and understand the different conditions and then trigger calls with parsed data to meridian to gather results and then perform TERMS to FHIR resource conversions as always. This is huge in terms of computation load.
FHIR spec provides a huge list of parameters that need to be supported in search for each FHIR resource. There are other query types that are pattern based like 'Allergy.Condition.type' contains 'f*' and also based on resource types
GET [base]/?_type=Observation,Condition&other search params...
to restrict the search within the give resource types. If we don't have FHIR resources stored and organized by resource type, it will also need high computation