FHIR IG analytics| Package | hl7.fhir.uv.tools |
| Resource Type | OperationDefinition |
| Id | OperationDefinition-cache-control.json |
| FHIR Version | R5 |
| Source | https://build.fhir.org/ig/FHIR/fhir-tools-ig/OperationDefinition-cache-control.html |
| URL | http://hl7.org/fhir/tools/OperationDefinition/cache-control |
| Version | 1.1.2 |
| Status | active |
| Date | 2026-07-01T05:48:24+00:00 |
| Name | CacheControl |
| Title | Terminology Cache Control |
| Realm | uv |
| Authority | hl7 |
| 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. 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. |
| Type | false |
| Kind | operation |
No resources found
No resources found
Note: links and images are rebased to the (stated) source
English
Generated Narrative: OperationDefinition cache-control
URL: [base]/$cache-control
| Use | Name | Scope | Cardinality | Type | Binding | Documentation |
| IN | mode | 1..1 | code | 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. | ||
| IN | tx-resource | 0..* | 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). | ||
| IN | sealed | 0..1 | boolean | 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. | ||
| OUT | cache-id | 0..1 | id | 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. | ||
| OUT | sealed | 0..1 | boolean | 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
| Use | Name | Scope | Cardinality | Type | Binding | Documentation |
| IN | mode | 1..1 | code | 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. | ||
| IN | tx-resource | 0..* | 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). | ||
| IN | sealed | 0..1 | boolean | 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. | ||
| OUT | cache-id | 0..1 | id | 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. | ||
| OUT | sealed | 0..1 | boolean | 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. |
{
"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"
}
]
}