Secondary Use FHIR Server Implementation Guide
0.1.0 - ci-build
Secondary Use FHIR Server Implementation Guide - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
The same resource-scoped FHIR search expressions are used in two implemented flows.
Ordinary Patient search uses reverse chaining:
GET [base]/Patient?_has:Condition:subject:code=34000006&gender=female&_summary=count
Per-type counts repeat the cohort criteria through standard Patient reference chains. For example, POST [base]/Condition/_search can use the form body subject:Patient._has:Condition:subject:code=34000006&subject:Patient.gender=female&_summary=count. The adapter resolves the Patient set internally. Every exploration response contains only the authoritative Bundle.total and no resource entries.
For extraction, POST [base]/Group accepts a Group that declares http://hl7.org/fhir/uv/bulkdata/StructureDefinition/bulk-cohort-group. The prototype checks a focused set of required fields but does not run a profile validator. Every member-filter modifier extension contains valueExpression.language=application/x-fhir-query and one resource-scoped expression.
Each value is one resource-scoped FHIR search expression:
| Filter | Meaning |
|---|---|
Condition?code=34000006,64766004 |
condition A OR condition B |
MedicationStatement?code=386891004 |
medication statement with the supplied code |
Patient?gender=female&birthdate=ge1980-01-01 |
female AND born on/after the date |
Observation?code=38445-3&date=ge2024-02-01 |
matching observation code and date |
Comma-separated values inside one parameter occurrence are ORed. Parameters within one expression, including repeated parameters, are ANDed. Separate member-filter extensions resolve separate patient sets and are intersected. Search result controls _summary and _elements, including Patient-chained forms, are rejected in member filters.
The UI emits code and clinical-date constraints as separate member-filter expressions. This deliberately matches standard Patient _has exploration semantics: each criterion must be present in the patient's compartment, but separate criteria may be satisfied by separate resources.
For example:
{
"resourceType": "Group",
"meta": { "profile": ["http://hl7.org/fhir/uv/bulkdata/StructureDefinition/bulk-cohort-group"] },
"modifierExtension": [
{ "url": "http://hl7.org/fhir/uv/bulkdata/StructureDefinition/member-filter", "valueExpression": { "language": "application/x-fhir-query", "expression": "Condition?code=34000006,64766004" } },
{ "url": "http://hl7.org/fhir/uv/bulkdata/StructureDefinition/member-filter", "valueExpression": { "language": "application/x-fhir-query", "expression": "MedicationStatement?code=386891004" } }
],
"type": "person",
"actual": false,
"name": "IBD medication cohort"
}
This selects patients with either listed condition and the medication statement.
Date comparison prefixes are values, not parameter-name suffixes:
birthdate=1980-01-01birthdate=ge1980-01-01birthdate=le2000-12-31date=ge2024-02-01&date=le2024-12-31The mock implements exact, ge, and le comparisons against the leading YYYY-MM-DD. Other FHIR comparison prefixes receive an explicit unsupported error.
Use birthdate for Patient.birthDate. For clinical resources, the prototype provides a date alias; see the field mapping. This alias is not uniformly the standard R4 search parameter. Where two fields are listed, each comparison may match either one.
Group create requires Prefer: respond-async. The adapter returns HTTP 202 and launches cohort resolution in the background. An empty HTTP 202 from its Content-Location means the request is still pending.
Completion returns HTTP 200 with a batch-response Bundle. A successful entry contains the in-memory Group.type=person with actual=true, including for a zero-member result; quantity is the resolved count and member references retain source Patient ids. A failed entry contains response.status and a FHIR OperationOutcome. The Group is lost when the adapter restarts.
Deleting the async status cancels a pending request or removes its completed result. It does not delete an already created Group. Group deletion uses its own resource URL; the completed async response retains the original creation result.