Search Parameter Initialization

The FHIR specification describes a rich set of default Search Parameters for every resource type, and these are all enabled by default. Every enabled search parameter means additional processing work when a resource is written, so disabling search parameters that are not used can have a significant impact on write performance.

For example, out of the box, every time a Patient resource is written, distinct search parameters are created to index:

• The family name
• The given name
• All names as a single index
• Email address
• Phone number
• All identifers
• All street address lines
• All listed address cities
• All listed address states/provinces
• All listed address countries
• All listed address postal/zip codes
• Gender

Having all of the indexes above can be useful if you are trying to build a general-purpose system that will support searching by any combination of a wide range of demographics.

On the other hand, if you are implementing one or more Implementation Guides that only mandate support for a specific limited number of search parameters, indexing all of these fields adds processing time and index disk space every time a resource is written.

The performance and storage space difference can be dramatic when you disable unnecessary search parameters. Tuning is highly recommended.

Checking Active Parameters

Search Parameters are controlled in your repository using SearchParameter resources. A simple search can be used to determine which search parameters are active, e.g.:

https://try.smilecdr.com/baseR4/SearchParameter?base=Patient&status=active

You can disable unwanted Search Parameters by updating these resources and setting the status to retired.

Seeding Search Parameters

By default, the system will automatically initialize your repository with all Search Parameters defined in the base FHIR specification when you create a new FHIR repository.

If you wish to automatically adjust this seeding, you can do this using the Search Parameter Seeding settings. Note that it is fine to adjust these after the repository has been created, even if the default set of search parameters has already been created.

Understanding Active Search Parameters

Three factors determine which Search Parameters are active in your repository: the Support Default SearchParameters setting, the enable and disable patterns configured for seeding, and the SearchParameter resources stored in the database. Each is described below.

Enable and disable patterns control which SearchParameter resources are seeded into the database. During seeding, Search Parameters excluded by the patterns are either skipped (when no SearchParameter resource exists for them) or set to retired (when one already exists).

Patterns

Patterns for both enabling and disabling search parameters take the forms:

• [resourceType]:[paramName] (One specific search parameter for one resource type) – e.g. "Practitioner:name"
• *:[paramName] (any search parameters with the given name across all resource types) – e.g. "*:name"
• [resourceType]:* (all search parameters for the given resource type) – e.g. "Practitioner:*"
• * (all search parameters for all resource types)

Multiple patterns may be specified using either a newline or a comma to separate the values.

When enable patterns are configured, they act as a whitelist - any search parameter not matched by an enable pattern will be disabled, regardless of whether a disable pattern is also configured. Enable patterns also take final precedence over disable patterns, so any search parameter matching an enable pattern will remain active even if it is also matched by a disable pattern. For example, if you specify a disable pattern of Patient:* and an enable pattern of Patient:name, Patient:identifier then only name and identifier will be active — all other Patient search parameters will be disabled, and so will all search parameters for every other resource type, since the enable pattern acts as a global whitelist.

Note that there are a small number of search parameters that can not be disabled as they are required for routine operation of the CDR. These include *:url (used by various parts of the validator and terminology services), Subscription:* and Basic:* (both by the Subscription module), and SearchParameter:* (used for search parameter loading). The system will not permit these to be disabled and will automatically ignore any attempts to disable them through disable or enable patterns.

Example

The following example shows seeding settings appropriate for a repository being used to support the CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) Implementation Guide.

Patient:*
Practitioner:*
ExplanationOfBenefit:*
Coverage:*
Organization:*

Patient:identifier
Coverage:identifier
ExplanationOfBenefit:identifier
ExplanationOfBenefit:patient
ExplanationOfBenefit:type
ExplanationOfBenefit:service-date
ExplanationOfBenefit:claim
ExplanationOfBenefit:coverage
ExplanationOfBenefit:encounter
ExplanationOfBenefit:enterer
ExplanationOfBenefit:facility
ExplanationOfBenefit:provider
ExplanationOfBenefit:payee