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

Cohort Criteria

Cohort Criteria

The same resource-scoped FHIR search expressions are used in two standards-based flows.

Stateless Exploration

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.

Bulk Cohort Group

For extraction, POST [base]/Group accepts a Group conforming to http://hl7.org/fhir/uv/bulkdata/StructureDefinition/bulk-cohort-group. 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=386872004 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. Repeated search parameters are ANDed. Separate member-filter extensions resolve separate patient sets and are intersected.

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=386872004" } }
  ],
  "type": "person",
  "actual": false,
  "name": "IBD medication cohort"
}

This selects patients with either listed condition and the medication statement.

Date Syntax

Date comparison prefixes are values, not parameter-name suffixes:

  • birthdate=1980-01-01
  • birthdate=ge1980-01-01
  • birthdate=le2000-12-31
  • date=ge2024-02-01&date=le2024-12-31

The mock implements exact, ge, and le comparisons against the leading YYYY-MM-DD. Other valid FHIR prefixes receive an explicit unsupported error.

Async Group Result

Group create uses Prefer: respond-async, return=representation. Polling its Content-Location completes with a batch-response Bundle containing the persisted Group.type=person. Group.actual is true when resolved members are populated and false for a zero-match result; quantity is always the resolved count.