FHIR integration queries have specific patterns that show up in production. Five cover most use cases.
1. Point-of-care Patient reads. Single patient view: GET Patient/{id}?_revinclude=Observation:subject&_revinclude=Condition:subject. Fast, cached client-side.
2. Longitudinal chart query. All resources for a patient across time. Use _lastUpdated for incremental sync.
3. Population cohort query. Patients matching criteria: Patient?general-practitioner.name=Smith&_count=100. Server-side pagination.
4. Bulk analytics extract. Bulk Data `$export` for warehouse ingest.
5. Terminology-driven filtering. Observation?code:in=SomeValueSet for value-set-driven queries.
Search parameter patterns
1. Direct search. Patient?identifier=MRN12345. 2. Chained. Patient?general-practitioner.name=Smith. 3. Reverse chained. Patient?_has:Observation:subject:code=8480-6. 4. _include. Get referenced resources in same query. 5. _revinclude. Get resources that reference this.
Performance considerations
1. Index the search parameters you query. 2. Cache stable references. 3. Paginate with _count. 4. Batch reads with _include. 5. Bulk export for analytics, not repeated REST.
Common query mistakes
1. Unpaginated large result sets. 2. Chained queries without proper indexes. 3. Client-side joins where _include works. 4. Individual reads where Bundle works. 5. Repeated fetches where cache works.
FHIR query patterns are well-understood in 2026. The five above cover essentially all integration query needs.
