Indexing status Operation¶

Canonical	`../OperationDefinition/indexing-status`
Status	draft · 1.26.0
Invocation	`GET [base]/$indexing-status`
Level	system
Affects state	no
Source	FSH · JSON

Report which search parameters are defined and indexed on the store this tenant is bound to, and whether an indexing job is running there right now.

POST [base]/$indexing-status

This is an administrative operation. The right that admits it is granted to an administrative role, not to an integration. It is described here because it is the only way to answer a question the server CapabilityStatement raises: two of the search parameters that statement declares are not base R4, and a store that has never been given their definitions ignores them silently rather than failing. This operation says whether a given tenant's store has them.

It takes no input and changes nothing. Post it with no body. A body, if sent, is ignored entirely: there are no input parameters and no filter.

affectsState is false, and the operation is still POST-only. The GET form is refused at 403 before it reaches the operation, because the right that admits this operation is spelled as a write. Do not build the GET call.

Reading the reply¶

A reply is a Parameters at 200, carrying three scalars and one repeating searchParameters part, one occurrence per parameter known to this tenant's store. The operation declares no refusal vocabulary of its own: there is nothing in a request for it to reject, so anything other than a 200 is the gateway's generic handling of a fault rather than a statement about indexing.

isFullyIndexed is narrower than it sounds. It is true only when every CUSTOM parameter is present, matches its expected definition, and no job is running. A built-in parameter reported with searchParameterIndexed false does not make it false. To ask "is the parameter I depend on usable", read that parameter's own entry; do not read the summary flag.

currentIndexingIntensity is defaulted, not measured. When nothing is running it reads Low. It is a claim about a running job only when isIndexing is true; read isIndexing first.

An absent entry is not a negative answer. Built-in parameters are listed only where the underlying store can report them. On a store that cannot, the reply carries the custom parameters alone, and the absence of a base R4 parameter says nothing about whether searches using it work.

Entries are not ordered by contract. Match on searchParameterUrl, which is the parameter's canonical, compared exactly.

What it does not tell you¶

There is no job identifier, no start time, no percentage complete and no estimate. Two replies cannot be compared to derive progress beyond the booleans they carry. A parameter that is being indexed reports searchParameterIsCurrentlyIndexing true and nothing further, and a job that has ended -- whether it finished, was abandoned, or was discarded because the store could not perform it -- simply stops appearing.

Response parameters¶

Parameter	Card.	Type	Documentation
`isFullyIndexed`	1..1	`boolean`	Whether every CUSTOM search parameter is present on the store, matches its expected definition, and is not mid-rebuild. NARROWER THAN THE NAME SUGGESTS: built-in parameters are excluded from this judgement, so a built-in reported as not indexed leaves this `true`. It is also `false` for the whole time any job is running, whatever that job is indexing. Read a specific parameter's own entry rather than this flag when the question is whether one search is usable.
`isIndexing`	1..1	`boolean`	Whether any indexing job is running for this tenant right now, for any parameter. Indexing is serialised per tenant, so this being `true` is also the reason a request to start another one is refused.
`currentIndexingIntensity`	1..1	`string`	The intensity of the running work, as `Low`, `Medium` or `High`, published as a `valueString`. Where several jobs run, it is the highest of them. A DEFAULTED VALUE, NOT A MEASUREMENT: when `isIndexing` is `false` this reads `Low` and means nothing. Read `isIndexing` first.
`searchParameters`	0..*	(parts)	One search parameter known to this tenant's store, and its state. Repeats once per parameter. Custom parameters are always listed; built-in parameters are listed only where the underlying store can report them, so an absent entry means the store did not report the parameter, NOT that searches using it fail. Not ordered by contract.
↳ `searchParameterUrl`	1..1	`string`	The parameter's canonical, published as a `valueString` rather than a `uri`. This is the key: match on it exactly. It is also the value the index-search-parameter operation takes.
↳ `searchParameterIndexed`	1..1	`boolean`	Whether this parameter is usable for search on this store. For a custom parameter this is a deep comparison and not a presence check: a definition that exists but differs from the one expected reports `false`, and it additionally requires that any built-in parameter sharing the same canonical is itself indexed. `false` here is the condition under which a search using this parameter is ignored rather than refused.
↳ `searchParameterIsCurrentlyIndexing`	1..1	`boolean`	Whether a running job claims this parameter. It carries no progress and no estimate; when the job ends this returns to `false` whether the work finished or was abandoned.
↳ `searchParameterIsBuiltIn`	1..1	`boolean`	Whether the parameter comes from the base specification (`true`) or is declared by this estate (`false`). It changes how the entry is judged: only the `false` entries count toward `isFullyIndexed`.