Search Parameter Reindexing
It is possible to trigger a manual reindexing of data in the repository. This is generally done for one of the following reasons:
In cases where Search Parameters have been changed in some way and the Mark Resources for Reindexing After SearchParameter Change property is not enabled, a reindex may be required in order to force data that was created prior to SearchParameter changes to be indexed. This setting is disabled by default. When reindexing because of a SearchParameter change, it is a good idea to include the type parameter shown below.
If Enforce Referential Integrity on Write is not enabled, it is possible to create resources with references that are not valid at the time that the resource is created. In that case, the reference will not be indexed even if the target resource is later created. A manual reindex is then required in order to correct this.
The server $reindex operation requests that all data on the server, or a selected subset of the data on the server be reindexed.
The $reindex operation allows for reindexing specific resources by providing a list of URLs, targeting only the corresponding resources. If the list of URLs is omitted, all resources will undergo reindexing.
See $reindex Operation (Instance) for an alternate lightweight syntax that can be used to reindex a single resource.
urls – (optional) If supplied, an ordered list of resource search urls to be reindexed. See Reindex URLs below for more information.reindexSearchParameters – (optional) Controls whether the system will attempt to update search parameter indexes. Valid values are:
all: (This is the default if not specified) Reindex all active search parameters.none: Do not reindex any search parameters. Choose this option if you wish to optimize storage as quickly as possible.optimizeStorage – (optional) Controls whether the system will migrate data from Compressed BLOB Storage to Inline Storage. See Resource Body Storage for more information. Valid values are:
NONE: (This is the default if not specified) Do not attempt to optimize storage during reindexing. Reindexing search parameters is faster with this option, so do not enable optimizeStorage unless you have modified the Inline Resource Storage Below Size setting.CURRENT_VERSION: Optimize the current version of resources.ALL_VERSIONS: Optimize all versions of resources.optimisticLock – (optional) If set to false (default is true), the system will not perform an optimistic lock check when reindexing data. Setting this value to false will improve the overall performance of the reindex job, but can result in stale data being indexed if a resource is updated by a client at the exact same time that it is being reindexed. Set this to false only if you are sure that data is not being modified while the job is running.The reindex operation uses search URLs to identify resources that should be reindexed. A search URL takes the form {resourceType}?[optional search parameters]. It does not include the base part of the URL.
For example, the following URL indicates that all resources of type Patient should be reindexed:
Patient
The following URL indicates that all Vital Signs Observations should be reindexed.
Observation
If no URLs are included, then all resources of all types will be reindexed. This is not currently supported on MongoDB.
It is important to remember that the search URL applies to resources as they are currently indexed. In other words, if you have just added a new search parameter to your repository and have not yet reindexed your data, you should not use that search parameter in your reindex URL since no resources will actually match it yet (so the reindex will not find and reindex any resources at all).
To reindex a specific set of URLs in order, call:
POST /$reindex
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [ {
"name": "url",
"valueString": "Patient?active=true"
}, {
"name": "url",
"valueString": "Observation?subject.active=true"
} ]
}
To reindex all Practitioner and all Patient resources, call:
POST /$reindex
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [ {
"name": "url",
"valueString": "Practitioner?"
}, {
"name": "url",
"valueString": "Patient?"
} ]
}
To reindex all non-SearchParameter resources and optimize storage, call:
POST /$reindex
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [ {
"name": "reindexSearchParameters",
"valueCode": "NONE"
}, {
"name": "optimizeStorage",
"valueCode": "ALL_VERSIONS"
} ]
}
To reindex all resources, simply call the $reindex operation with no parameters.
POST /$reindex
The $reindex operation creates a batch job that can be stopped and restarted on the Batch Job Management page.
The $reindex operation is partition aware. The operation is performed only on the partition that was included in the request and the job is only started if the user is allowed to access that partition. In order to perform a $reindex everything=true, the user must have access to all resource types on that partition.
For multitenancy using Request Tenant Selection Mode, it is possible to reindex against all partitions by using the _ALL as a tenant name in the request URL (e.g. /_ALL/$reindex).
The $reindex operation can also be invoked at the resource instance level.
For example, the following could be used to reindex a single Observation resource.
POST /Observation/123/$reindex
Unlike the server-level $reindex operation described above, the instance-level operation is synchronous, and returns once the reindexing is complete.
This operation returns a Parameters resource containing information about all the resource indexes that were added, removed, or retained while reindexing the resource. An example is shown below (this example has been abbreviated, typically resources will have more indexes than shown here).
{
"resourceType": "Parameters",
"parameter": [ {
"name": "Narrative",
"valueString": "<div><div id=\"StringIndexes\"><h1>String Indexes</h1><table id=\"StringIndexesTable\"><thead><tr><th>Name</th><th>Action</th><th>Type</th><th>ValueNormalized</th><th>ValueExact</th></tr></thead><tbody><tr><td>family</td><td> NO_CHANGE </td><td> String </td><td> SMITH </td><td> Smith </td></tr><tr><td>name</td><td> NO_CHANGE </td><td> String </td><td> SMITH </td><td> Smith </td></tr></tbody></table></div></div>"
}, {
"name": "StringIndexes",
"part": [ {
"name": "family",
"part": [ {
"name": "Action",
"valueCode": "NO_CHANGE"
}, {
"name": "Type",
"valueCode": "String"
}, {
"name": "ValueNormalized",
"valueString": "SMITH"
}, {
"name": "ValueExact",
"valueString": "Smith"
} ]
}, {
"name": "name",
"part": [ {
"name": "Action",
"valueCode": "NO_CHANGE"
}, {
"name": "Type",
"valueCode": "String"
}, {
"name": "ValueNormalized",
"valueString": "SMITH"
}, {
"name": "ValueExact",
"valueString": "Smith"
} ]
} ]
} ]
}
While developing and testing search parameters, it can be useful to test the outcome of a reindexing operation at small scale before initiating a full reindex. The $reindex-dryrun operation can be used to simulate a single resource reindex.
For example, the following could be used to simulate a reindex of a single Observation resource. Because this operation does not affect resource state, it can be invoked with an HTTP GET as well.
GET /Observation/123/$reindex-dryrun
This operation returns the same details response as the $reindex Operation (Instance) described above.
The following documentation is provided for the old reindexing operation. Users are encouraged to use the new operation as it provides better control of what's indexed and a user-interface to view, stop, and restart the reindexing job.
The following arguments are supported for this operation:
type – (optional) If supplied, specifies the specific resource type to reindex. If not specified, all resource types will be reindexed.To perform a manual reindex, the following operation can be invoked at the server (root) level of the FHIR Endpoint module (i.e. the base URL of the FHIR endpoint). To specifiy parameters, a resource of type Parameters must be included as the body of a POST request. See the following examples for more details.
-- DEPRECATED --
GET /$mark-all-resources-for-reindexing
POST /$mark-all-resources-for-reindexing
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [ {
"name": "type",
"valueString": "Patient"
} ]
}