SlotEnd Search parameter¶
| Canonical | ../SearchParameter/slot-end |
|---|---|
| Status | draft · 1.26.0 |
| Query | Slot?end=[value] |
| Parameter name | end |
| Applies to | Slot |
| Type | date |
| Expression | Slot.end |
| Source | FSH · JSON |
Filter Slot by the instant it finishes.
GET [base]/Slot?end=ge2026-03-01T00:00:00Z
GET [base]/Slot?schedule=Schedule/{id}&end=lt2026-03-02T00:00:00Z
R4 has no such parameter, and that is why this one exists. The base specification defines
start on Slot and nothing over Slot.end, so a window bounded by when slots FINISH cannot be
expressed with base parameters alone. It is an ordinary date parameter over Slot.end: it takes
the prefixes and precisions a date search takes on the store serving it, and combines with the
base Slot parameters in the usual way.
A store that has not been given this definition does not refuse a search that names it. It drops
the parameter, answers with everything, and at most explains itself in an OperationOutcome entry
inside an otherwise ordinary searchset. The consequence is the whole reason to read this paragraph:
an unfiltered result set is indistinguishable from a successful narrow search, so a client that
asked to see slots ending inside a window and got back the whole store has no signal that anything
went wrong, and a test asserting a 200 response proves nothing.
So load this definition into the store before relying on the parameter, and prove the filter ran. The proof that works is a negative one: seed a slot that ends OUTSIDE the bound, search with the bound, and assert that slot is ABSENT. A test that asserts only that matching slots came back passes identically against a store that ignored the parameter. Nexus EMR deployments seed this definition and hold a standing check of exactly that shape; a consumer operating its own store is responsible for the same step, and nothing in the protocol will tell it the step was skipped.
Indexing is separate from definition. On stores that index search parameters as a background job, writing the definition makes the parameter known and does not by itself make it usable; until the index completes, the search behaves as it does on a store that never had the definition at all.