FHIR © HL7.org  |  FHIRsmith 4.0.1  |  Server Home  |  XIG Home  |  XIG Stats  | 

FHIR IG analytics

Packagehl7.fhir.uv.tools
Resource TypeOperationDefinition
IdOperationDefinition-cache-control.json
FHIR VersionR5
Sourcehttps://build.fhir.org/ig/FHIR/fhir-tools-ig/OperationDefinition-cache-control.html
URLhttp://hl7.org/fhir/tools/OperationDefinition/cache-control
Version1.1.2
Statusactive
Date2026-07-01T05:48:24+00:00
NameCacheControl
TitleTerminology Cache Control
Realmuv
Authorityhl7
DescriptionManage a terminology client cache on the server. A client that repeatedly validates or expands against the same value sets and code systems can register those resources with the server once, under a server-issued cache-id, and then refer to them by url on subsequent calls instead of re-sending them each time. The protocol is explicit: the client calls this operation with mode=start to create a cache; the server allocates the cache and returns its identifier in the `cache-id` output parameter. The client then sends that identifier as the `X-Cache-Id` HTTP header on subsequent $validate-code and $expand requests. Resources are populated into the cache by sending them (as `tx-resource`, or as the primary `valueSet`/`codeSystem`) on those requests, or by front-loading them in the mode=start call. By default a cache is sealed: it holds only the resources front-loaded at mode=start and does not grow. A client that wants the cache to accumulate resources as they are seen (needed for incremental population and batch front-loading) requests an unsealed cache by sending sealed=false at mode=start. The mode=start response always reports, in the `sealed` output parameter, which kind of cache was created. When finished, the client calls mode=end to release the cache (the server will otherwise time it out). Because the server owns the cache-id, it can authoritatively report when a client refers to a cache it does not have (never created, expired, or released): such requests fail with an OperationOutcome whose issue carries the code `cache-id-unknown` from http://hl7.org/fhir/tools/CodeSystem/tx-issue-type. This is distinct from a value set or code system genuinely not being found, so a client can tell a stale cache from an authoring error. This operation affects server state and SHOULD be invoked with POST; servers MAY also accept GET for convenience.
Typefalse
Kindoperation

Resources that use this resource

No resources found


Resources that this resource uses

No resources found


Narrative

Note: links and images are rebased to the (stated) source


English


Generated Narrative: OperationDefinition cache-control

URL: [base]/$cache-control

Parameters

UseNameScopeCardinalityTypeBindingDocumentation
INmode1..1code

What to do: 'start' creates a new cache and returns its id; 'end' releases the cache identified by the X-Cache-Id header; 'check' (where supported) reports whether the cache identified by the X-Cache-Id header is still valid, and may return statistics about it.

INtx-resource0..*Resource

Optional resources (CodeSystem, ValueSet, ConceptMap) to front-load into the cache when mode=start, so they are immediately in scope for subsequent calls that carry the cache-id. Resources may also be added incrementally on later $validate-code / $expand calls (unless the cache is sealed).

INsealed0..1boolean

Used with mode=start: whether the cache is sealed. A sealed cache (the default) contains only the resources front-loaded in this call and does not grow; an unsealed cache (sealed=false) additionally accumulates resources it sees on subsequent calls, and is what makes incremental population and batch front-loading possible. If omitted, the server's default applies (which SHOULD be true); a client that requires a particular behaviour should set this explicitly and check the sealed value returned in the response.

OUTcache-id0..1id

The server-issued cache identifier, returned by mode=start. The client sends this value as the X-Cache-Id HTTP header on subsequent requests that should use the cache. Absent if no cache was created.

OUTsealed0..1boolean

Returned by mode=start: whether the created cache is sealed. A mode=start response always includes it, so the client does not have to assume a default - it states authoritatively whether the cache is fixed at what was front-loaded (sealed=true) or will grow as further resources are seen (sealed=false). The minimum cardinality is 0 because it is not returned for the other modes (mode=end, mode=check); it is nonetheless mandatory in a mode=start response.


Spanish


Generated Narrative: OperationDefinition cache-control

URL: [base]/$cache-control

Parameters

UseNameScopeCardinalityTypeBindingDocumentation
INmode1..1code

What to do: 'start' creates a new cache and returns its id; 'end' releases the cache identified by the X-Cache-Id header; 'check' (where supported) reports whether the cache identified by the X-Cache-Id header is still valid, and may return statistics about it.

INtx-resource0..*Resource

Optional resources (CodeSystem, ValueSet, ConceptMap) to front-load into the cache when mode=start, so they are immediately in scope for subsequent calls that carry the cache-id. Resources may also be added incrementally on later $validate-code / $expand calls (unless the cache is sealed).

INsealed0..1boolean

Used with mode=start: whether the cache is sealed. A sealed cache (the default) contains only the resources front-loaded in this call and does not grow; an unsealed cache (sealed=false) additionally accumulates resources it sees on subsequent calls, and is what makes incremental population and batch front-loading possible. If omitted, the server's default applies (which SHOULD be true); a client that requires a particular behaviour should set this explicitly and check the sealed value returned in the response.

OUTcache-id0..1id

The server-issued cache identifier, returned by mode=start. The client sends this value as the X-Cache-Id HTTP header on subsequent requests that should use the cache. Absent if no cache was created.

OUTsealed0..1boolean

Returned by mode=start: whether the created cache is sealed. A mode=start response always includes it, so the client does not have to assume a default - it states authoritatively whether the cache is fixed at what was front-loaded (sealed=true) or will grow as further resources are seen (sealed=false). The minimum cardinality is 0 because it is not returned for the other modes (mode=end, mode=check); it is nonetheless mandatory in a mode=start response.


Source1

{
  "resourceType": "OperationDefinition",
  "id": "cache-control",
  "text": {
    "status": "generated",
    "div": "<!-- snip (see above) -->"
  },
  "extension": [
    {
      "url": "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm",
      "valueInteger": 1
    },
    {
      "url": "http://hl7.org/fhir/StructureDefinition/structuredefinition-wg",
      "valueCode": "fhir"
    },
    {
      "url": "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode": "informative",
      "_valueCode": {
        "extension": [
          {
            "url": "http://hl7.org/fhir/StructureDefinition/structuredefinition-conformance-derivedFrom",
            "valueCanonical": "http://hl7.org/fhir/tools/ImplementationGuide/hl7.fhir.uv.tools"
          }
        ]
      }
    }
  ],
  "url": "http://hl7.org/fhir/tools/OperationDefinition/cache-control",
  "identifier": [
    {
      "system": "urn:ietf:rfc:3986",
      "value": "urn:oid:2.16.840.1.113883.4.642.40.1.33.1"
    }
  ],
  "version": "1.1.2",
  "name": "CacheControl",
  "title": "Terminology Cache Control",
  "status": "active",
  "kind": "operation",
  "experimental": false,
  "date": "2026-07-01T05:48:24+00:00",
  "publisher": "HL7 International / FHIR Infrastructure",
  "contact": [
    {
      "telecom": [
        {
          "system": "url",
          "value": "http://www.hl7.org/Special/committees/fiwg"
        }
      ]
    }
  ],
  "description": "Manage a terminology client cache on the server. A client that repeatedly validates or expands against the same value sets and code systems can register those resources with the server once, under a server-issued cache-id, and then refer to them by url on subsequent calls instead of re-sending them each time.\n\nThe protocol is explicit: the client calls this operation with mode=start to create a cache; the server allocates the cache and returns its identifier in the `cache-id` output parameter. The client then sends that identifier as the `X-Cache-Id` HTTP header on subsequent $validate-code and $expand requests. Resources are populated into the cache by sending them (as `tx-resource`, or as the primary `valueSet`/`codeSystem`) on those requests, or by front-loading them in the mode=start call.\n\nBy default a cache is sealed: it holds only the resources front-loaded at mode=start and does not grow. A client that wants the cache to accumulate resources as they are seen (needed for incremental population and batch front-loading) requests an unsealed cache by sending sealed=false at mode=start. The mode=start response always reports, in the `sealed` output parameter, which kind of cache was created. When finished, the client calls mode=end to release the cache (the server will otherwise time it out).\n\nBecause the server owns the cache-id, it can authoritatively report when a client refers to a cache it does not have (never created, expired, or released): such requests fail with an OperationOutcome whose issue carries the code `cache-id-unknown` from http://hl7.org/fhir/tools/CodeSystem/tx-issue-type. This is distinct from a value set or code system genuinely not being found, so a client can tell a stale cache from an authoring error.\n\nThis operation affects server state and SHOULD be invoked with POST; servers MAY also accept GET for convenience.",
  "jurisdiction": [
    {
      "coding": [
        {
          "system": "http://unstats.un.org/unsd/methods/m49/m49.htm",
          "code": "001"
        }
      ]
    }
  ],
  "affectsState": true,
  "code": "cache-control",
  "system": true,
  "type": false,
  "instance": false,
  "parameter": [
    {
      "name": "mode",
      "use": "in",
      "min": 1,
      "max": "1",
      "documentation": "What to do: 'start' creates a new cache and returns its id; 'end' releases the cache identified by the X-Cache-Id header; 'check' (where supported) reports whether the cache identified by the X-Cache-Id header is still valid, and may return statistics about it.",
      "type": "code"
    },
    {
      "name": "tx-resource",
      "use": "in",
      "min": 0,
      "max": "*",
      "documentation": "Optional resources (CodeSystem, ValueSet, ConceptMap) to front-load into the cache when mode=start, so they are immediately in scope for subsequent calls that carry the cache-id. Resources may also be added incrementally on later $validate-code / $expand calls (unless the cache is sealed).",
      "type": "Resource"
    },
    {
      "name": "sealed",
      "use": "in",
      "min": 0,
      "max": "1",
      "documentation": "Used with mode=start: whether the cache is sealed. A sealed cache (the default) contains only the resources front-loaded in this call and does not grow; an unsealed cache (sealed=false) additionally accumulates resources it sees on subsequent calls, and is what makes incremental population and batch front-loading possible. If omitted, the server's default applies (which SHOULD be true); a client that requires a particular behaviour should set this explicitly and check the sealed value returned in the response.",
      "type": "boolean"
    },
    {
      "name": "cache-id",
      "use": "out",
      "min": 0,
      "max": "1",
      "documentation": "The server-issued cache identifier, returned by mode=start. The client sends this value as the X-Cache-Id HTTP header on subsequent requests that should use the cache. Absent if no cache was created.",
      "type": "id"
    },
    {
      "name": "sealed",
      "use": "out",
      "min": 0,
      "max": "1",
      "documentation": "Returned by mode=start: whether the created cache is sealed. A mode=start response always includes it, so the client does not have to assume a default - it states authoritatively whether the cache is fixed at what was front-loaded (sealed=true) or will grow as further resources are seen (sealed=false). The minimum cardinality is 0 because it is not returned for the other modes (mode=end, mode=check); it is nonetheless mandatory in a mode=start response.",
      "type": "boolean"
    }
  ]
}