{
  "resourceType": "SearchParameter",
  "id": "slot-end",
  "url": "https://fhir.apps.health/SearchParameter/slot-end",
  "description": "Filter `Slot` by the instant it finishes.\n\n    GET [base]/Slot?end=ge2026-03-01T00:00:00Z\n    GET [base]/Slot?schedule=Schedule/{id}&end=lt2026-03-02T00:00:00Z\n\n**R4 has no such parameter, and that is why this one exists.** The base specification defines\n`start` on `Slot` and nothing over `Slot.end`, so a window bounded by when slots FINISH cannot be\nexpressed with base parameters alone. It is an ordinary `date` parameter over `Slot.end`: it takes\nthe prefixes and precisions a `date` search takes on the store serving it, and combines with the\nbase `Slot` parameters in the usual way.\n\n**A store that has not been given this definition does not refuse a search that names it.** It drops\nthe parameter, answers with everything, and at most explains itself in an `OperationOutcome` entry\ninside an otherwise ordinary searchset. The consequence is the whole reason to read this paragraph:\nan unfiltered result set is indistinguishable from a successful narrow search, so a client that\nasked to see slots ending inside a window and got back the whole store has no signal that anything\nwent wrong, and a test asserting a 200 response proves nothing.\n\n**So load this definition into the store before relying on the parameter, and prove the filter ran.**\nThe proof that works is a negative one: seed a slot that ends OUTSIDE the bound, search with the\nbound, and assert that slot is ABSENT. A test that asserts only that matching slots came back passes\nidentically against a store that ignored the parameter. Nexus EMR deployments seed this definition\nand hold a standing check of exactly that shape; a consumer operating its own store is responsible\nfor the same step, and nothing in the protocol will tell it the step was skipped.\n\n**Indexing is separate from definition.** On stores that index search parameters as a background\njob, writing the definition makes the parameter known and does not by itself make it usable; until\nthe index completes, the search behaves as it does on a store that never had the definition at all.",
  "name": "SlotEnd",
  "status": "draft",
  "experimental": false,
  "date": "2026-09-14",
  "publisher": "WELLSTAR Technologies Corp.",
  "contact": [
    {
      "name": "Nexus EMR FHIR Implementation Guide",
      "telecom": [
        {
          "system": "url",
          "value": "https://fhir.apps.health"
        }
      ]
    }
  ],
  "jurisdiction": [
    {
      "coding": [
        {
          "code": "CA",
          "system": "urn:iso:std:iso:3166",
          "display": "Canada"
        }
      ]
    }
  ],
  "code": "end",
  "base": [
    "Slot"
  ],
  "type": "date",
  "expression": "Slot.end"
}