This page is part of the FHIR Specification (v4.3.0: R4B (v5.0.0-draft-final: Final QA Preview for R5 - STU see ballot notes ). The current version which supercedes this version is 5.0.0 . For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

3.1.1 3.2.1 Search

FHIR Infrastructure Work Group

Maturity Level : Normative

Standards Status : Normative

Searching for resources is fundamental to the mechanics of FHIR. Search operations traverse through an existing set of resources filtering by parameters supplied to the search operation. The text below describes the FHIR search framework, starting with simple cases moving to the more complex. Implementers need only implement the amount of complexity that they require for their implementations. Servers SHALL declare what features of search they require through their CapabilityStatement search declarations , and clients are encouraged to do this too.

3.1.1.1 3.2.1.1 Summary Table Contents

• Introduction
  • Search Parameter Types Overview
  • Search Inputs Parameters for all resources
  • Search Contexts
  • Search result parameters Responses
    • Number Bundle Type Date/DateTime
    • Self Link - Understanding a Performed Search String
    • Other Links - Paging Token
    • Matches, Inclusions, and Outcomes - Bundle Entries Reference
    • Handling Errors Composite
• Transport Protocols
  • Quantity HTTP POST URI
  • HTTP GET Special
  • Choosing an HTTP Method
  • _id Batching Searches
  • Search in Messaging
• _lastUpdated Search Parameters
  • Searching Multiple Values (joining with AND or OR)
  • _tag Modifiers
  • Prefixes
  • _profile Escaping Search Parameters
  • Basic Parameter Types: date , number , quantity , reference , string , token , uri
  • Extended Parameter Types: composite , special
• _security Special Search Conditions
  • Searching Identifiers
    • Logical Identifiers _source
    • Searching by Membership
    • _text Identifiers and References
    • Canonical Identifiers
  • _content References and Versions
  • Searching Hierarchies
  • _list Searching MIME Types
  • Chaining (chained parameters)
  • Reverse Chaining _has
  • Handling Missing Data
  • _type Advanced Filtering
  • Searching Multiple Resource Types
  • Implicit Resources
  • Named Queries
• Modifying Search Results
  • Sorting (_sort) _sort
  • Total number of matching resources (_total)
  • Limiting Page Size (_count) _count
  • Limiting Total Result Size (_maxresults)
  • _include Summary (_summary)
  • Selecting Elements (_elements)
  • _revinclude Relevance (_score)
  • Including Referenced Resources
    • Inline Requests (_include, _revinclude) _summary
    • External References
    • _total Graph Definitions (_graph) TU
    • Contained Resources (_contained)
    • _elements Paging and Other Resources
• Standard Parameters
  • Parameters for All Resources _contained
  • Parameters for Each Resource
  • _containedType Text Search Parameters
• Server Conformance In addition, there is a special search parameters
• _query Search Result Currency
• Conformance Summary and _filter
• Summary Tables that allow for an alternative method

3.2.1.2 Introduction

FHIR Search is the primary mechanism used to find and list resource instances. The search mechanism is designed to be flexible enough to meet the needs of searching, a wide variety of use cases, and yet be simple enough to be commonly useful.

In a typical RESTful interface, collections of instances are returned as arrays of a type. In order to include related information (e.g., number of total results), support extended functionality (e.g., paging), and allow multiple resource types in results (e.g., returning Patient and Encounter resources), FHIR Search instead returns a Bundle resource, with a type of searchset . Resources included in the results appear as individual entries in such a bundle. Note that the parameters _format and _pretty defined parameter works for all search like for other interactions . More information about returned contents and elements can be found in Managing Returned Resources

Also, There are safety issues associated with the implementation of searching that implementers should always keep in mind. Implementers SHOULD review the safety checklist .

3.2.1.2.1 Search Overview

Though search operations are typically performed via REST, search is defined to be useful independently of HTTP. Note that while different formats of search requests are functionally equivalent, there MAY be differences inherent to searching via a particular protocol. Details can be found in Search Protocols .

3.2.1.2.2 Search Inputs

Input to search operations are referred to as Search Parameters . A search parameter can be:

• a filter across all resources (e.g., _id , which is present on every resource),
• a filter on a specific resource (e.g., Patient.birthDate , which applies to the Patient resource,)
• a textual search across a resource, or
• a parameter that affects search results .

There is a single page that lists all the search parameters . published with this specification. Note that search parameter names are case sensitive, though this specification never defines different parameters with names that differ only in case. Clients SHOULD use correct case, and servers SHALL not NOT define additional parameters with different meanings with names that only differ in case.

There are several safety issues associated with the implementation Order of searching that implementers should always keep in mind. 3.1.1.2 Introduction In the simplest case, a search operations is executed not driven by performing a GET operation order in the RESTful framework: GET [base]/[type]?name=value&...{&_format=[mime-type]}} For this RESTful search (see definition in RESTful API ), URL - with the parameters are a series exception of name=[value] pairs encoded in sort. First all filters are applied, then the URL or as an application/x-www-form-urlencoded submission result set is sorted, then paging is applied, and then included resources ( _include , _revinclude ) are added for a POST: each page.

The server determines which of the set of their resources it serves meet the specific criteria, and returns the results criteria contained in the HTTP response search parameters as a bundle which includes described below. However, the resources that are server has the prerogative to return additional search results of if it believes them to be relevant. Note: There is a special search for the search. Note that most relevant context in which the search set is indeterminate: Patient MPI Search .

In the absence of any search filters, e.g. _format GET [base] , GET [base]/Patient , or POST [base]/_search parameter works for or POST [base]/Patient/_search with no body, a server SHOULD return all records in scope of the search like for other interactions . context. Servers MAY reject a search as overly-broad, and SHOULD return an appropriate error in that situation (e.g., too-costly ).

3.2.1.2.3 Search Contexts

Search operations are executed in one of three defined contexts that control which set of resources are being searched:

• A specified resource type: GET [base]/[type]?parameter(s) A specified compartment , perhaps with a specified resource type in that compartment: GET [base]/Patient/[id]/[type]?parameter(s) All resource types: GET [base]?parameter(s) (parameters common to all types). If Note that if the _type parameter is included, all other search parameters SHALL be common to all provided types. If types, and if _type is not included, all parameters SHALL be common to all resource types. Show as: HTTP GET | HTTP POST GET [base]?parameter(s) POST [base]/_search Content-Type: application/x-www-form-urlencoded parameter(s)
• A specified resource type: Show as: HTTP GET | HTTP POST GET [base]/[type]?parameter(s) POST [base]/[type]/_search Content-Type: application/x-www-form-urlencoded parameter(s)
• A specified compartment , perhaps with a specified resource type in that compartment. Note that the literal * (asterisk) is valid as the [type] in a GET-based compartment search. This syntax is for disambiguation between an instance read and a compartment search, which would otherwise share the same URL. Show as: HTTP GET | HTTP POST GET [base]/[compartment]/[id]/[type]?parameter(s) POST [base]/[compartment]/[id]/[type]/_search Content-Type: application/x-www-form-urlencoded parameter(s)

3.2.1.3 Search Responses

Search operations can also be implemented responses are always returned as a Bundle . Search result bundles convey a lot of metadata in addition to any possible results, using the messaging framework . various elements available in the bundle resource.

The server determines which response to any search operation is always a list of their resources meet in a Bundle. An alternative approach is to use GraphQL .

3.2.1.3.1 Bundle Type

Search result bundles will always have the criteria contained Bundle.type of searchset . This element and value designate that the bundle is a search response and MAY be used in processing to indicate

3.2.1.3.2 Self Link - Understanding a Performed Search

In order to allow the client to be confident about what search parameters were used as described below. However, the server has criteria by a server, servers SHALL return the prerogative parameters that were actually used to return additional process a search. Applications processing search results SHALL check these returned values where necessary. For example, if it believes them a server did not support some of the filters specified in the search, a client might manually apply those filters to the retrieved result set, display a warning message to the user or take some other action.

These parameters are encoded in the self link of the returned bundle - a bundle.link with the relation set to self : Show as: FHIR+JSON | FHIR+XML { "resourceType": "Bundle", "type": "searchset", ... "link": { "relation": "self", "url": "http://example.org/Patient?name=peter" } ... } <Bundle> <type value="searchset"/> ... <link> <relation value="self"/> <url value="http://example.org/Patient?name=peter"/> </link> ... </Bundle>

Self links SHALL be relevant. Note: There expressed as an HTTP GET-based search with the relevant parameters included as query parameters, because of the semantics around the link types TU . This means that the same self link is a special search valid response for any equivalent search, regardless of how a search is performed (e.g., HTTP GET, HTTP POST, Messaging, etc.).

Self links MAY be returned as absolute URIs or URIs relative to the most relevant context base URL of a server, and MAY or MAY NOT be resolvable TU . A server that does not support search via GET will return links in which the same style as a server that does not support search set is indeterminate: Patient MPI Search . via POST. Note that this makes the self link special in the context of bundle links, as all other links are intended to be resolvable by a client.

Search using Clients SHALL review the returned parameters in the self link to ensure proper processing of results. Generally, ignored parameters will result in clients receiving more results than intended. In those situations, clients SHOULD filter received records to account for additional data TU .

3.2.1.3.3 Other Links - Paging

In addition to the self link, many bundles MAY contain links relevant to paging. These are identified via the GET relation may value in the links. Common links include: first , last , next , and prev .

As with the self link, all relevant paging links SHALL be expressed as GET requests TU . Servers SHOULD NOT include content that is considered sensitive information in the search parameters. Therefore, secure communications URLs TU .

3.2.1.3.4 Matches, Inclusions, and endpoint management Outcomes - Bundle Entries

Within the results bundle, there are recommended, see Security Communications three types of entries that MAY be present, identified by the search mode of the entry: match , include , or outcome .

The response Note that entries are unique (not allowed to any repeat) and there is only one mode per entry. In some corner cases, a resource may be included because it is both a match and an include . In these circumstances, match takes precedence.

3.2.1.3.4.1 Match

Entries marked with match in search operation results indicate that a record is always being returned because it meets the parameters specified in the search request (e.g., a list of resources record the client requested).

3.2.1.3.4.2 Include

Entries marked with include in search results indicate that a Bundle. An alternative approach record is being returned either because it is referred to from a record in the result set or that the server believes is useful or necessary for the client to process other results.

3.2.1.3.4.3 Outcome

Entries marked with outcome in search results are OperationOutcome resources with information related to the processing of a search. For example, a server MAY use GraphQL . an outcome record to report to a client that a search was unacceptable TU .

3.1.1.3 3.2.1.3.5 Handling Errors

If a server is unable to execute a search request, it may MAY either return an error. error for the request or return success with an outcome containing details of the error TU . A HTTP status code of 403 signifies that the server refused to perform the search, while other 4xx and 5xx codes signify that some sort of error has occurred. When the search fails, a server SHOULD return an OperationOutcome detailing the cause of the failure. Note: An Note that an empty search result is not a failure. an error.

In some cases, parameters may cause an error, or might not be able to match anything. For instance:

Note: Empty parameters are not an error - they are just ignored by the server.

Where the content of the parameter is syntactically incorrect, servers SHOULD return an error. However, where the issue is a logical condition (e.g. unknown subject or code), the server SHOULD process the search, including processing the parameter - with the result of returning an empty search set, since the parameter cannot be satisfied.

In such cases, the search process MAY include an OperationOutcome in the search set that contains additional hints and warnings about the search process. This is included in the search results as an entry with a search mode = of outcome . Clients can use this information to improve future searches. If, for example, a client performed the following search: GET [base]/Observation?patient.identifier=http://example.com/fhir/identifier/mrn|123456 Show as: HTTP GET | HTTP POST GET [base]/Observation?patient.identifier=http://example.com/fhir/identifier/mrn|123456 POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded patient.identifier=http://example.com/fhir/identifier/mrn|123456 and there is no patient for MRN 123456, the server would may return a bundle with no results and a warning outcome, such as this .

Unknown and unsupported parameters

Servers may receive parameters from the client that they do not recognize, or may receive parameters they recognize but do not support (either in general, or for a specific search). In general, servers SHOULD ignore unknown or unsupported parameters for the following reasons:

• Various HTTP stacks and proxies may add parameters that aren't under the control of the client
• The client can determine what parameters the server used by examining the self link in the return (see below )

Clients can specify how the server should behave, by using the prefer header header:

• Prefer: handling=strict: handling=strict : Client requests that the server return an error for any unknown or unsupported parameter
• Prefer: handling=lenient: handling=lenient : Client requests that the server ignore any unknown or unsupported parameter

Servers SHOULD honor the client's request, but are not required to do so. For more information, see HTTP Headers on the HTTP Page.

3.1.1.4 3.2.1.4 Standard Parameters Transport Protocols

This specification defines FHIR Search operations in both HTTP POST and GET . Servers supporting Search via HTTP SHALL support both modes of operation, though MAY return a HTTP 405 (Method Not Allowed) for either POST or GET , but not both TU .

3.1.1.4.1 3.2.1.4.1 Parameters for all resources HTTP POST

The following parameters apply to all resources : _content , _filter , _has , _id , _lastUpdated , _list , _profile , _query , _security , _source , _tag , _text , _type . In addition, the search parameter _text and _filter , (documented below) also applies Clients perform searches via HTTP POST by making an HTTP POST request to all resources (as do the appropriate context, with search result parameters). The search parameter parameters included as _id x-www-form-urlencoded refers to the logical id of content for the resource, post. For example:

POST [base]/_search
Content-Type: application/x-www-form-urlencoded
param1=value&...{&_format=[mime-type]}

POST [base]/[resource-type]/_search
Content-Type: application/x-www-form-urlencoded
param1=value&...{&_format=[mime-type]}

POST [base]/[compartment-type]/[compartment-id]/_search
Content-Type: application/x-www-form-urlencoded
param1=value&...{&_format=[mime-type]}

 GET [base]/Patient?_id=23

POST [base]/[compartment-type]/[compartment-id]/[resource-type]/_search
Content-Type: application/x-www-form-urlencoded
param1=value&...{&_format=[mime-type]}

This While servers SHALL support search finds the patient resource with parameters encoded in the given id (there can only be one resource for a given id). Functionally, this is equivalent to POST body (as shown above), servers MAY also support including some or all parameters as query parameters on a simple read operation : POST request TU , e.g.:

 GET [base]/Patient/23

POST [base]/[type]/_search?param1=value&...{&_format=[mime-type]}
Content-Type: application/x-www-form-urlencoded
param2=value2&...

However, the search with parameter _id returns a bundle with the requested resource, instead of just the resource itself. Additional Note that servers MAY impose restrictions on what parameters can are allowed to be added which may provide additional functionality passed as query parameters on top of this base read equivalence (e.g. POST requests TU . For example, a server could allow the _include _format ). Note that although the _id query parameter has a type of token, because servers SHALL use exact match but reject searches with it, there is no system for the _id parameter. Note that matches on a _id Patient.name are always case sensitive. query parameter.

3.2.1.4.2 HTTP GET

The search parameter _lastUpdated can be used Clients perform searches via HTTP GET by making an HTTP GET request to select resources based on the last time they were changed: appropriate context, with search parameters included as HTTP Query Parameters. For example:

 GET [base]/Observation?_lastUpdated=gt2010-10-01

GET [base]?param1=value&...{&_format=[mime-type]}

GET [base]/[resource-type]/?param1=value&...{&_format=[mime-type]}

  GET [base]/[compartment-type]/[compartment-id]/*?param1=value&...{&_format=[mime-type]}

GET [base]/[compartment-type]/[compartment-id]/[resource-type]?param1=value&...{&_format=[mime-type]}

3.2.1.4.3 Choosing an HTTP Method

The search parameters _tag , _profile and _security parameters As described above, servers that support search on the equivalent elements in via REST SHALL support both the meta GET element . and POST methods TU . However, there are known use cases that prevent one or the other method from being desirable in production. For example, GET [base]/Condition?_tag=http://acme.org/codes|needs-review searches for all Condition in the case of a large set of Endpoint resources with (e.g., FHIR servers), infrastructure could be configured to take advantage of HTTP caching mechanisms that do not function correctly on HTTP POST requests. Conversely, an implementation might not be able to properly secure Personal Health Information (PHI) that appears in request query parameters (e.g., in HTTP logs made by infrastructure) and wants to require the tag: use of HTTP POST for mitigation.

In the same manner: Note that neither GET nor POST have any inherent benefits with respect to security or privacy. The use of various default software configurations in production have led some to believe that POST is more secure because HTTP Body contents are not logged. This is not due to any protocol restrictions and should not be relied on. Implementers should verify that their logging processes adequately protect PHI and other sensitive data.

restricts Given the above considerations, server implementers SHOULD be sure to test both GET and POST search operations to only DiagnosticReport resources that ensure they are tagged as conforming to a particular profile. The second reference is relative and refers a local profile correct on their servers TU . For example, a read-only server may prohibit the same server. HTTP POST verb universally (returning a 405 - Method Not Allowed) and must then ensure correct implementation of HTTP GET.

_tag , Search requests may include sensitive information in the search parameters. Therefore, secure communications and _security parameters endpoint management are token types (see below ), and _profile is a reference recommended, see Security Communications search parameter.

3.1.1.4.2 3.2.1.4.4 Parameters for each resource Batching Search Requests

In addition to the _id parameter which exists for all resources, each FHIR resource type defines its own set of search parameters with their names, types, and meanings. These search parameters are on the same page as the resource definitions, and are also published as part of the standard Capability statement ( XML or JSON Servers MAY support batching ). multiple requests TU . In general, the defined search parameters correspond context of search, this allows several searches to be performed serially via a single element in the resource, but this request. Note that each operation of a batch is independent, so it is not required, and some search parameters refer possible to use the same type results of element in multiple places, or refer one request as input to derived values. another in the same batch.

Some When submitting multiple requests via a batch or transaction, the returned bundle is for the batch or transaction as an operation. Therefore, two search parameters defined by resources are associated with more than one path requests in a resource. This means batch would return a bundle that the search parameter matches if any contains at least two entries, each of the paths contain matching content. If a path matches, the whole resource which is returned in the result of a search results. The client may have to examine request (e.g., the resource to determine which path contains batch result bundle will contain entries that are the match. search result bundles).

Servers When bundling requests via batch or transaction , HTTP verbs and the URLs for RESTful interfaces are used. When requesting searches in a bundle, systems SHOULD accept searches via GET, even if they do not required typically accept GET-based searches TU . There is no standard way to implement any of convey POST-based searches within a Bundle and the standard architectural differences when searching via GET or POST are not relevant within a Bundle. Servers receiving searches within a Bundle SHOULD NOT impose any GET-specific limitations on search parameters (except for (i.e. restrictions not imposed on POST-based searches) that they would impose if the _id parameter described above). GET-based search had been received outside a Bundle TU .

3.2.1.4.5 Search via Messaging

Servers may also define their own parameters. MAY support FHIR Messaging . The mapping of seach requests into messages is described in more detail in the section Invoking Search via Messages .

3.1.1.4.3 3.2.1.5 Search Parameter Types Parameters

Each While search parameters are typically transmitted as URL-Encoded strings (e.g., HTTP Parameters or x-www-form-urlencoded body content), FHIR is modeled with a rich set of primitive and complex datatypes to describe the data encountered in healthcare. To provide consistent mapping between the two formats, each search parameter is defined by a type that specifies how the search parameter behaves. These are the defined search parameter types:

The Individual search parameters can MAY also append allow "modifiers" that control their behavior. The kinds of modifiers that available is dependent depend on the type of the search parameter. More details can be found in the Modifiers section of the search page.

3.2.1.5.1 Searching Multiple Values (joining with AND or OR)

Multiple search parameters passed to a single search are used to create an intersection of the results. In other words, multiple parameters are joined via "AND". For example, a search for a patient that includes a given name and a family name will only return records that match BOTH: Show as: HTTP GET | HTTP POST GET [base]/Patient?given=valueGiven&family=valueFamily POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded given=valueGiven&family=valueFamily will return only Patient records with a family name of "valueFamily" and a given name of "valueGiven".

In order to search for unions of results (values joined by "OR"), values can be separated by a comma (",") character. For example, a search for a patient with EITHER of two given names: Show as: HTTP GET | HTTP POST GET [base]/Patient?given=valueGivenA,valueGivenB POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded given=valueGivenA,valueGivenB will return Patient records with EITHER a given name of "valueGivenA" OR "valueGivenB". This includes patient record that have BOTH "valueGivenA" and "valueGivenB" (e.g., inclusive or).

It is possible to combine both "AND" and "OR" type queries together in a single request. For example, a search that includes a family name and either of two given names: Show as: HTTP GET | HTTP POST GET [base]/Patient?given=valueGivenA,valueGivenB&family=valueFamily POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded given=valueGivenA,valueGivenB&family=valueFamily will return records that match a family name of "valueFamily" AND a given name of either "valueGivenA" OR "valueGivenB".

Note that there is not a syntax to request unions on different elements (OR joins). For example, a client that wants records with either a given OR family name of "valueName". However, it is possible to define search parameters that operate on multiple elements. For example, the described use case of searching for a patient by any part of their name has a search parameter being modified. on Patient called name , which matches any part of a name (e.g., name=valueName ). It is also possible to define composite search parameters , which allows servers to provide this functionality.

If a client wants results based on OR-joins of unrelated elements, or if there is not a combined search parameter defined or supported on a server, the results can be retrieved by issuing multiple queries, either serially or in a batch.

3.1.1.4.4 3.2.1.5.2 Modifiers

Parameters Generally, search parameters are used as filters to refine search results based on one or more resource elements. For example, a query might find patients born in a certain year by using the birthdate search parameter, which maps to the Patient.birthDate element. Sometimes it is necessary or desirable to use a search parameter with a different behavior, for example, searching for patients that do not have a birth date in their records. Instead of requiring many search parameters on an element to cover each type of use, this specification defines modifiers that can be used to change the meaning of a search parameter while leaving element mappings intact.

Search parameter modifiers are defined per resource. Parameter names may specify by the search-modifier-code code system. Search parameter definitions MAY include a list of allowed modifiers in the SearchParameter.code element, which is bound to the search-modifier-code value set. Servers SHALL support any modifiers present in search parameters the server advertises support for. Servers MAY choose to support additional modifiers. Note that servers MAY support modifiers on types not defined in this specification.

In search requests, search modifiers are used by appending the modifier as a suffix. The modifiers suffix to the search parameter name, with the syntax of: [name]:[modifier] , such as birthdate:missing . Note that only a single modifier is allowed on a single search parameter. If multiple layers of modification are separated from necessary, a new search parameter can be defined with the appropriate behavior. If the desired behavior is not possible to define in a search parameter without multiple stacked modifiers, an operation can be defined.

Since modifiers change the meaning of a search parameter, a server SHALL reject any search request that contains a search parameter with an unsupported modifier. For example, if the server supports the name by search parameter, but not the :exact modifier on the name, it would reject a colon. Modifiers are: search with the parameter name:exact=Bill , using an HTTP 400 error with an OperationOutcome with a clear error message .

While support for modifiers is applied per search parameter, modifiers are generally defined according to search parameter type. For all example, the ":exact" modifier has meaning when applied to string-type search parameters (except combination): :missing ; e.g. gender:missing=true (or false). Searching but has no meaning and cannot be used with token-type search parameters. The exception is the search parameters type special . The definition for any search parameter of type "special" SHALL explicitly list any allowed modifiers; this list MAY include any value from the search-modifier-code code system.

The modifiers defined by this specification are:

3.2.1.5.2.1 above

The above modifier allows clients to search hierarchies of data based on relationships. The above modifier is only allowed on search parameters of type reference , token , and uri . The exact semantics for use vary depending on the type of search parameter:

3.2.1.5.2.1.1 above with reference type search parameters

When the above modifier is used with a reference type search parameter, the search is interpreted as a hierarchical search on linked resources of the same type, including exact matches and all parents of those matches. The above modifier is only valid for circular references - that is, references that point to another instance of the same type of resource (e.g., a hierarchy of Location resources). Further discussion about the requirements and uses for this type of search can be found in the resource). section Searching for Hierarchies .

When using the gender:missing=false above will return modifier on a reference, all typically-valid search parameter reference inputs are allowed.

For example, the search: Show as: HTTP GET | HTTP POST GET [base]/Procedure?location:above=A101 POST [base]/Procedure/_search Content-Type: application/x-www-form-urlencoded location:above=A101 would match any Procedure resources with locations:

• A101 , Location/A101 , https://example.org/Location/A101 - this location by ID
• A100 , Location/A100 , https://example.org/Location/A100 - parent of A101, representing the first floor (A101 - A199)
• BuildingA , Location/BuildingA , https://example.org/Location/BuildingA - parent of A100, representing the building 'A'

3.2.1.5.2.1.2 above with canonical references

When the above modifier is used with a reference against a canonical reference, the search is interpreted as a version search against the canonical resource. The format of the parameter is either [url] or [url]|[version] . This search is only allowed if the version scheme for the resource is known (e.g., a known version-scheme extension or element). Version-related search criteria against resources with unknown versioning schemes SHALL be either ignored or rejected TU . The above modifier comparison is performed as a 'greater than' against the version-scheme defined by the resource.

When using the above modifier on a canonical reference, all typically-valid search parameter token inputs are allowed. Note that any vertical pipe ( | ) characters that are part of the URL must be escaped ( %7C ) - the character is used as the separator between the URL and version components of the parameter.

More information can be found in the section References and Versions .

3.2.1.5.2.1.3 above with token type search parameters

When the above modifier is used with a token type search parameter, the supplied token is a concept with the form [system]|[code] and the intention is to test whether the coding in a resource subsumes the specified search code. Matches to the input token concept have an is-a relationship with the coding in the resource, and this includes the coding itself.

When using the above modifier on a token, all typically-valid search parameter token inputs are allowed.

For example, the search: Show as: HTTP GET | HTTP POST GET [base]/Observation?code:above=http://snomed.info/sct|3738000 POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded code:above=http://snomed.info/sct|3738000 for Observations with a code above SNOMED 'Viral hepatitis (disorder)' will match any Observation resources with codes:

• SNOMED 3738000 - Viral hepatitis (this code)
• SNOMED 235862008 - Hepatitis due to infection (parent of 'Viral hepatitis')
• SNOMED 128241005 - Inflammatory disease of liver (parent of 'Hepatitis due to infection')
• etc.
• SNOMED 312130009 - Viral infection by site (parent of 'Viral hepatitis')
• SNOMED 301810000 - Infection by site (parent of 'Viral infection by site')
• etc.

3.2.1.5.2.1.4 above with uri type search parameters

When the above modifier is used with a uri type search parameter, the value is used for partial matching based on URL path segments. Because of the hierarchical behavior of gender above , the modifier only applies to URIs that are URLs and cannot be used with URNs such as OIDs. Note that there are not many use cases where above parameter. is useful compared to a below search.

When using the above modifier on a uri, all typically-valid search parameter uri inputs are allowed.

For simple example, the search: Show as: HTTP GET | HTTP POST GET [base]/ValueSet?url:above=http://acme.org/fhir/ValueSet/123/_history/5 POST [base]/ValueSet/_search Content-Type: application/x-www-form-urlencoded url:above=http://acme.org/fhir/ValueSet/123/_history/5 would match any ValueSet resources with a url of:

• http://acme.org/fhir/ValueSet/123/_history/5 - full match
• http://acme.org/fhir/ValueSet/123/_history - parent of requested URI
• http://acme.org/fhir/ValueSet/123 - ancestor of requested URI
• http://acme.org/fhir/ValueSet - ancestor of requested URI
• http://acme.org/fhir - ancestor of requested URI
• http://acme.org/ - ancestor of requested URI

3.2.1.5.2.2 below

The below modifier allows clients to search hierarchies of data based on relationships. The below modifier is only allowed on search parameters of type elements, :missing=true will match reference , token , and uri . The exact semantics for use vary depending on the type of search parameter:

3.2.1.5.2.2.1 below with reference type search parameters - hierarchical searches

When the below modifier is used with a reference type search parameter, the search is interpreted as a hierarchical search on linked resources of the same type, including exact matches and all elements where children of those matches. The below modifier is only valid for circular ?? recursive instead of circular here ?? references - that is, references that point to another instance of the same type of resource (e.g., a hierarchy of Location resources). Further discussion about the requirements and uses for this type of search can be found in the section Searching Hierarchies .

When using the below modifier on a hierarchical reference, all typically-valid search parameter reference inputs are allowed.

For example, the search: Show as: HTTP GET | HTTP POST GET [base]/Procedure?location:below=BuildingA POST [base]/Procedure/_search Content-Type: application/x-www-form-urlencoded location:below=BuildingA for Procedures with a location below BuildingA would match any Procedure resources with locations:

• BuildingA , Location/BuildingA , https://example.org/Location/BuildingA - this location by ID
• A100 , Location/A100 , https://example.org/Location/A100 - child of BuildingA, representing the first floor
• A101 , Location/A101 , https://example.org/Location/A101 - child of A100, room 101
• A1.. , etc. - child of A100, rooms on the first floor
• A200 , Location/A200 , https://example.org/Location/A200 - child of BuildingA, representing the second floor
• etc.

3.2.1.5.2.2.2 below with canonical references

When the below modifier is used with a reference against a canonical reference, the search is interpreted as a version search against the canonical resource. The format of the parameter is either [url] or [url]|[version] . This search is only allowed if the underlying element version scheme for the resource is omitted known (e.g., a known version-scheme extension or where element). Version-related search criteria against resources with unknown versioning schemes SHALL be either ignored or rejected TU . The below modifier comparison is performed as a 'less than' against the element version-scheme defined by the resource.

When using the below modifier on a canonical reference, all typically-valid search parameter token inputs are allowed. Note that any vertical pipe ( | ) characters that are part of the URL must be escaped ( %7C ) - the character is present used as the separator between the URL and version components of the parameter.

More information can be found in the section References and Versions .

3.2.1.5.2.2.3 below with extensions but no @value token type search parameters

When the below modifier is used with a token type search parameter, the supplied token is a concept with the form [system]|[code] and the intention is to test whether the coding in a resource is subsumed by the specified search code. Matches include resources that have a coding that has an is-a relationship with the input concept, and this includes the coding itself.

When using the below modifier on a token, all typically-valid search parameter token inputs are allowed.

For example, the search: Show as: HTTP GET | HTTP POST GET [base]/Observation?code:below=http://snomed.info/sct|235862008 POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded code:below=http://snomed.info/sct|235862008 for Observations with a code below SNOMED 'Hepatitis due to infection' would match any Observation resources with codes:

• SNOMED 235862008 - Hepatitis due to infection (this code)
• For string: :exact SNOMED 773113008 returns results - Acute infectious hepatitis (child)
• SNOMED 95897009 - Amebic hepatitis (child)
• etc.

Note that match there is no limit inherent to the entire supplied referential search. If child concepts contain child concepts of their own, the search continues down the tree in each path until reaching a terminal node.

The below modifier is useful when trying to resolve MIME types. Further documentation can be found in the Searching MIME Types section of this page.

3.2.1.5.2.2.4 below with uri type search parameters

When the below modifier is used with a uri type search parameter, including casing the value is used for partial matching based on URL path segments. Because of the hierarchical behavior of below , the modifier only applies to URIs that are URLs and combining characters. cannot be used with URNs such as OIDs.

When using the below modifier on a uri, all typically-valid search parameter uri inputs are allowed.

For example, the search: Show as: HTTP GET | HTTP POST GET [base]/ValueSet?url:below=http://acme.org/fhir POST [base]/ValueSet/_search Content-Type: application/x-www-form-urlencoded url:above=http://acme.org/fhir would match any ValueSet resources with a url of:

• http://acme.org/fhir - full match
• http://acme.org/fhir/ValueSet - child of requested URI
• http://acme.org/fhir/ValueSet/123 - descendant of requested URI
• http://acme.org/fhir/ValueSet/123/_history - descendant of requested URI
• http://acme.org/fhir/ValueSet/123/_history/1 - descendant of requested URI
• etc.

3.2.1.5.2.3 code-text TU

The code-text modifier allows clients to indicate that a supplied string input should be matched as a case-insensitive and combining-character insensitive match against the start of target string. This modifier is used to do a 'standard' string search against code values. Note that the handling of (extended) extended grapheme clusters is within the discretion of the server, i.e. the server decides if a string search parameter matches on canonically equivalent characters, characters or matches on the actual used Unicode code points, or :contains points. Case-insensitive comparisons do not take locale into account, and will result in unsatisfactory results for certain locales. Character case definitions and conversions are out of scope for the FHIR standard, and the results of such operations are implementation dependent.

code-text (case insensitive is only allowed on reference and combining character-insensitive, token type search parameters. When using the 'code-text' modifier, all typically-valid search parameter string inputs are allowed.

For example, the search: Show as: HTTP GET | HTTP POST GET [base]/Patient?language:code-text=en POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded language:code-text=EN would match any Patient resources with a communication language of:

• en - requested code text (case-insensitive)
• en-AU - starts with requested code text (case-insensitive)
• en-CA - starts with requested code text (case-insensitive)
• en-GB - starts with requested code text (case-insensitive)
• etc.

3.2.1.5.2.4 contains

The contains modifier allows clients to indicate that a supplied string input should be matched as a case-insensitive and combining-character insensitive match anywhere in the string), instead target string. Note that the handling of extended grapheme clusters is within the discretion of the default behavior (case insensitive and accent-insensitive, partial server, i.e. the server decides if a string search parameter matches at on canonically equivalent characters or matches on the start actual used Unicode code points. Case-insensitive comparisons do not take locale into account, and will result in unsatisfactory results for certain locales. Character case definitions and conversions are out of scope for the FHIR standard, and the results of such operations are implementation dependent.

contains is allowed on string and uri type search parameters. When using the string). 'contains' modifier, all typically-valid search parameter string inputs are allowed.

For example, the search: Show as: HTTP GET | HTTP POST GET [base]/Patient?family:contains=son POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded family:contains=son would match any Patient resources with a family names such as:

• Son - requested string (case-insensitive)
• Sonder - begins with requested string (case-insensitive)
• Erikson - ends with requested string (case-insensitive)
• Samsonite - contains requested string (case-insensitive)
• etc.

3.2.1.5.2.5 exact

The exact modifier allows clients to indicate that a supplied string input is the complete and exact value that should be matched, including casing and combining characters. Note that the handling of extended grapheme clusters is within the discretion of the server, i.e. the server decides if a string search parameter matches on canonically equivalent characters or matches on the actual used Unicode code points. Case-insensitive comparisons do not take locale into account, and will result in unsatisfactory results for certain locales. Character case definitions and conversions are out of scope for the FHIR standard, and the results of such operations are implementation dependent.

exact is only allowed on string type search parameters. When using the 'exact' modifier, all typically-valid search parameter string inputs are allowed.

For token: :text example, the search: Show as: HTTP GET | HTTP POST GET [base]/Patient?family:exact=Son POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded family:exact=Son will only match Patient resources with a family name of:

• Son (the - requested string (case-sensitive)

3.2.1.5.2.6 identifier

The identifier modifier allows clients to indicate that a supplied token should be used to match does against the identifier element of a partial searches reference instead of the reference element. The format of the parameter is [system]|[code] . Note that chaining is not supported when using the identifier modifier and the modifier is not supported on canonical elements since they do not have an identifier separate from the reference itself.

identifier is only allowed on reference type search parameters. When using the text portion 'identifier' modifier, all typically-valid search parameter token inputs are allowed.

For example, the search: Show as: HTTP GET | HTTP POST GET [base]/Observation?subject:identifier=http://example.org/fhir/mrn|12345 POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded subject:identifier=http://example.org/fhir/mrn|12345 for observations with a subject containing the identifier 'http://example.org/fhir/mrn|12345' would match Observation resources such as: Show as: FHIR+JSON | FHIR+XML "Observation": { "subject": { "reference": "Patient/abc", "identifier": { "system": "http://example.org/fhir/mrn", "value": "12345" } } } <Observation> <subject> <reference value="Patient/abc"/> <identifier> <system value="http://example.org/fhir/mrn"/> <value value="12345"/> </identifier> </subject> </Observation> but will not match: Show as: FHIR+JSON | FHIR+XML "Observation": { "subject": { "reference": "Patient/abc" } } <Observation> <subject> <reference value="Patient/abc"/> </subject> </Observation> even if the Patient resource for Patient/abc includes the requested identifier among its Patient.identifier values.

For more details about the difference between the identifier modifier and chained-searches on the identifier element, see Searching Identifiers .

3.2.1.5.2.7 in

The in modifier is used to filter based on value membership of codes in Value Sets. The in modifier is only allowed on token type search parameters.

When the in modifier is used with a CodeableConcept token search parameter, the input is a uri (relative or absolute) that identifies a value set, and the display portion search parameter tests whether the coding is in the specified value set. The reference may be literal (to an address where the value set can be found) or logical (a reference to ValueSet.url ). If the server can treat the reference as a literal URL, it does, else it tries to match known logical ValueSet.url values. Note that the URI need not point to the root value set, http://snomed.info/sct?fhir_vs=isa/235862008 is a valid reference to a subset of SNOMED CT 'Hepatitis due to infection', but the parameter value will need to be URL Encoded in order to be a Coding), valid parameter.

When using the in modifier on a token, only tokens targeting value sets are allowed (e.g., a boolean token parameter target is not allowed).

For example, the search: Show as: HTTP GET | HTTP POST GET [base]/Condition?code:in=ValueSet/123 POST [base]/Condition/_search Content-Type: application/x-www-form-urlencoded code:in=ValueSet/123 would match any conditions that contain any code from 'ValueSet/123'.

Similarly, the search: Show as: HTTP GET | HTTP POST GET [base]/Condition?code:in=http%3A%2F%2Fsnomed.info%2Fsct%3Ffhir_vs%3Disa%2F235862008 POST [base]/Condition/_search Content-Type: application/x-www-form-urlencoded code:in=http%3A%2F%2Fsnomed.info%2Fsct%3Ffhir_vs%3Disa%2F235862008 would match any conditions that contain any code from 'http://snomed.info/sct?fhir_vs=isa/235862008', e.g.:

• SNOMED 235862008 - Hepatitis due to infection (this code)
• SNOMED 773113008 - Acute infectious hepatitis (is-a 235862008)
• SNOMED 95897009 - Amebic hepatitis (is-a 235862008)
• etc.

3.2.1.5.2.8 iterate

The iterate modifier is used to indicate that an inclusion directive should be applied to an included resource instead of the default matching resource. Note that this modifier is not defined for any search parameter types. This modifier can only be applied to the search result parameters of _include and _revinclude .

When the iterate modifier is used, the input provided is the same as the input for the inclusion directive (see Including other resources ).

For example, the search: Show as: HTTP GET | HTTP POST GET [base]/Observation?code=http://snomed.info/sct|3738000&_include=Observation:patient&_include:iterate=Patient:link POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded code=http://snomed.info/sct|3738000&_include=Observation:patient&_include:iterate=Patient:link would match any observations with the SNOMED code 3738000 (Viral hepatitis (disorder)). The results would include resources from following the search reference Observation.patient , which uses codes. Other defined modifiers are :in , :below , :above Patient resources linked via Observation.subject . Additionally, the server would iterate through the included patient records and :not-in follow the Patient.link which references, including linked Patient or RelatedPerson resources.

More information can be found in the section Including other resources

3.2.1.5.2.9 missing

The missing modifier allows clients to filter based on whether resources contain values that can match a search parameter. Usually, this equates to testing if a resource has an element or not.

missing is allowed on search parameter types that represent single-elements: date , number , quantity , reference , string , token , uri . When using the 'missing' modifier, the only valid input values are described below. For reference: :[type] the literal values true and false .

Searching for [parameter]:missing=true requests all resources that do not have a value in the matching element or where [type] the element is present with extensions, but no value is specified.

For example, the name of search: Show as: HTTP GET | HTTP POST GET [base]/Patient?given:missing=true POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded given:missing=true would match any Patient records that do not have any value in Patient.name that contains a type of resource, :identifier, and, value for some parameters, :above given , even if a patient contains a Patient.name that has a given with an extension and :below no value (e.g., a Data Absent Reason).

Searching for [parameter]:missing=false requests all resources that do have a value in the matching element.

For uri: :below , :above example, the search: Show as: HTTP GET | HTTP POST GET [base]/Patient?given:missing=false POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded given:missing=false would match any Patient records that have any value in Patient.name indicate that instead contains a value for given .

3.2.1.5.2.10 not

The not modifier allows clients to filter based on whether resources do not contain a specified token based on the search parameter input.

not is only allowed on search parameters of an exact match, either type token . When using the 'not' modifier, all typically-valid search term left-matches parameter token inputs are allowed.

Searching for [parameter]:not=[value] requests all resources that do not have any matching value in the value, or vice-versa. searched element(s).

For example, the search: Show as: HTTP GET | HTTP POST GET [base]/Patient?gender:not=male POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded gender:not=male would match any Patient records that do not have male as the value in Patient.gender . This includes:

• female - Administrative Gender that is not 'male'
• other - Administrative Gender that is not 'male'
• unknown - Administrative Gender that is not 'male'
• records without a Patient.gender value (even if a record has extensions, such as a Data Absent Reason)

Server SHALL reject Similarly, the search: Show as: HTTP GET | HTTP POST GET [base]/Composition?section:not=48765-2 POST [base]/Composition/_search Content-Type: application/x-www-form-urlencoded Composition?section:not=48765-2 for documents without an "Allergies and adverse reaction" section ( LOINC 48765-2 ) would return all Composition records that do not contain any section with a code of '48765-2'. This search request does not return "any document that has a section that contains is suffixed by not an Allergies and adverse reaction section". In the presence of multiple possible matches, the negation applies to the set and not each individual entry.

3.2.1.5.2.11 not-in

The not-in modifier is used to filter based on a value exclusion test for codes of Value Sets. The not-in modifier is only allowed on token type search parameters.

When the not-in modifier is used with a token search parameter, the input is a uri (relative or absolute) that identifies a value set, and the server does search parameter tests whether the coding is not support for in the specified value set. The reference may be literal (to an address where the value set can be found) or logical (a reference to ValueSet.url ). If the server can treat the reference as a literal URL, it does, else it tries to match known logical ValueSet.url values. Note that the URI need not point to the root value set, http://snomed.info/sct?fhir_vs=isa/235862008 is a valid reference to a subset of SNOMED CT 'Hepatitis due to infection', but the parameter value will need to be URL Encoded in order to be a valid parameter.

When using the not-in modifier on a token, only tokens targeting value sets are allowed (e.g., a boolean token parameter target is not allowed).

For example, the search: Show as: HTTP GET | HTTP POST GET [base]/Condition?code:not-in=ValueSet/123 POST [base]/Condition/_search Content-Type: application/x-www-form-urlencoded code:not-in=ValueSet/123 would match any conditions that do not contain any code from 'ValueSet/123'.

Similarly, the search: Show as: HTTP GET | HTTP POST GET [base]/Condition?code:not-in=http%3A%2F%2Fsnomed.info%2Fsct%3Ffhir_vs%3Disa%2F235862008 POST [base]/Condition/_search Content-Type: application/x-www-form-urlencoded code:not-in=http%3A%2F%2Fsnomed.info%2Fsct%3Ffhir_vs%3Disa%2F235862008 would match any conditions that do not contain any code from 'http://snomed.info/sct?fhir_vs=isa/235862008', e.g.:

• SNOMED 235862008 - Hepatitis due to infection (this code)
• SNOMED 773113008 - Acute infectious hepatitis (is-a 235862008)
• SNOMED 95897009 - Amebic hepatitis (is-a 235862008)
• etc.

3.2.1.5.2.12 of-type

The of-type modifier allows clients to filter for resource Identifier , based on the Identifier.type.coding.system , Identifier.type.coding.code and Identifier.value . This allows searches for specific values only within a specific identifier code system. The format when using 'of-type' is [system]|[code]|[value] , where [system] and [code] refer to the code and system in Identifier.type.coding ; the system and code portion is considered a match if the server supports the name system|code token would match a given Identifier.type.coding . The [value] test is a string match against Identifier.value . All three parts must be present.

of-type is only allowed on search parameter, but parameters of type token , and further restricted to parameters targeting the Identifier type. When using the 'of-type' modifier, all typically-valid token values are valid for the system and code segments, and all typically-valid string values are valid for the value segment. Note that input values MAY need to escaped in order to be processed correctly (e.g., if the 'value' contains a vertical pipe character).

For example, the search: Show as: HTTP GET | HTTP POST GET [base]/Patient?identifier:of-type=http://terminology.hl7.org/CodeSystem/v2-0203|MR|12345 POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded identifier:of-type=http://terminology.hl7.org/CodeSystem/v2-0203|MR|12345 for patients that contain an identifier that has a type coding of with a system of http://terminology.hl7.org/CodeSystem/v2-0203 , a code of MR (which identifies Medical Record Numbers), and a value of 12345 will return records such as: Show as: FHIR+JSON | FHIR+XML "Patient": { "identifier": [{ "type": { "coding" : { "system": "http://terminology.hl7.org/CodeSystem/v2-0203", "code": "MR" } } "system": "http://example.org/ehr-primary/", "value": "12345" }] } <Patient> <identifier> <type> <coding> <system value="http://terminology.hl7.org/CodeSystem/v2-0203"/> <value value="MR"/> </coding> </type> <system value="http://example.org/ehr-primary"/> <value value="12345"/> </identifier> </Patient> This can be used to disambiguate between data sets that contain collisions. For example, the above search will NOT return values with a different identifying type, such as: Show as: FHIR+JSON | FHIR+XML "Patient": { "identifier": [{ "type": { "coding" : { "system": "http://terminology.hl7.org/CodeSystem/v2-0203", "code": "MRT" } } "system": "http://example.org/ehr-er", "value": "12345" }] } <Patient> <identifier> <type> <coding> <system value="http://terminology.hl7.org/CodeSystem/v2-0203"/> <value value="MRT"/> </coding> </type> <system value="http://example.org/ehr-er"/> <value value="12345"/> </identifier> </Patient> which signifies that the identifier is a Temporary Medical Record Number.

3.2.1.5.2.13 text with reference TU or token type search parameters

The text modifier on search parameters of type reference and token allows clients to indicate that a supplied string should be used to perform a string-search against the text associated with a code or value. For example, CodeableConcept.text , Coding.display , Identifier.type.text , or Identifier.assigner.display . Search matching is performed using basic string matching rules - begins with or is, case-insensitive.

In this context, the text modifier is only allowed on reference and token type search parameters. When using the 'text' modifier, all typically-valid search parameter string inputs are allowed.

For example, the search: Show as: HTTP GET | HTTP POST GET [base]/Condition?code:text=headache POST [base]/Condition/_search Content-Type: application/x-www-form-urlencoded code:text=headache would match Condition resources containing any codes that start with or equal the string 'headache' (case-insensitive), such as:

• SNOMED 25064002 - Headache finding
• SNOMED 398987004 - Headache following lumbar puncture
• SNOMED 230480006 - Headache following myelography (disorder)
• ICD-10 R51 - Headache
• ICD-10 R51.0 - Headache with orthostatic component, not elsewhere classified
• ICD-10 R51.9 - Headache, unspecified
• etc.

Note that the search is not expected to return results with codes such as SNOMED 735938006 , since the :exact code text of 'Acute headache' does not match a default string search of the term headache (case-insensitive, begins with or equals). For advanced searching of related text, see the text-advanced search modifier.

For more details about the difference between the identifier modifier and chained-searches on the name, it should reject identifier element, see Searching Identifiers .

3.2.1.5.2.14 text with string type search parameters

The text modifier allows clients to request matching based on advanced string processing of the search parameter input. Implementers of this modifier SHOULD support a sophisticated search functionality of the type offered by typical text indexing services. The value of the parameter is a text-based search, which may involve searching multiple words with thesaurus and proximity considerations, and logical operations such as AND, OR, etc.. Note that only a few servers are expected to offer this facility.

Implementers could consider using the rules specified by the OData specification for the $search parameter . Typical implementations would use Lucene, Solr, an SQL-based full text search, or some similar indexing service.

name:exact=Bill text is only allowed on search parameters of type string . When using the 'text' modifier, all typically-valid search parameter string inputs are allowed.

For example, assuming a search parameter section-text that applies to Composition.section.text , the search: Show as: HTTP GET | HTTP POST GET [base]/Composition?section:text=(bone OR liver) and metastases POST [base]/Composition/_search Content-Type: application/x-www-form-urlencoded section:text=(bone OR liver) and metastases for compositions about metastases in the bones or liver of subjects will search for those literal values, but MAY also search for terms such as 'cancerous growth', 'tumor', etc..

3.2.1.5.2.15 text-advanced TU

The text-advanced modifier allows clients to request matching based on advanced string processing of the search parameter input against the text associated with a code or value. For example, CodeableConcept.text , Coding.display , or Identifier.type.text . Implementers of this modifier SHOULD support a sophisticated search functionality of the type offered by typical text indexing services, but MAY support only basic search with minor additions (e.g., word-boundary recognition). The value of the parameter is a text-based search, which may involve searching multiple words with thesaurus and proximity considerations, and logical operations such as AND, OR, etc..

text-advanced is allowed on search parameters of type reference and token . When using an the 'text-advanced' modifier, all typically-valid search parameter string inputs are allowed.

For example, the search: Show as: HTTP GET | HTTP POST GET [base]/Condition?code:text-advanced=headache POST [base]/Condition/_search Content-Type: application/x-www-form-urlencoded code:text-ad=headache would match Condition resources containing codes with text that equals or begins with 'headache', case-insensitive (e.g., same as the text modifier) such as:

• SNOMED 400 25064002 error - Headache finding
• SNOMED 398987004 - Headache following lumbar puncture
• SNOMED 230480006 - Headache following myelography (disorder)
• ICD-10 R51 - Headache
• ICD-10 R51.0 - Headache with an OperationOutcome orthostatic component, not elsewhere classified
• ICD-10 R51.9 - Headache, unspecified
• etc.

However, it would also match Condition resources containing codes with text containing the word 'headache' such as:

• SNOMED 735938006 - Acute headache
• SNOMED 95660002 - Thunderclap headache
• SNOMED 4969004 - Sinus headache
• ICD-10 G44.019 - Episodic cluster headache, not intractable
• ICD-10 G44.81 - Hypnic headache
• etc.

Additionally, a server MAY also return Condition resources with codes containing synonymous text such as conditions with the codes:

• SNOMED 37796009 - Migraine
• SNOMED 49605003 - Ophthalmoplegic migraine (disorder)
• ICD-10 G43.4 - Hemiplegic migraine
• ICD-10 G43.B0 - Ophthalmoplegic migraine, not intractable
• etc.

3.2.1.5.2.16 [type]

The [type] modifier allows clients to restrict the resource type of a reference. The modifier does not use the literal '[type]' in any way, but rather the name of a resource - e.g., Patient , Encounter , etc.. Note that the modifier cannot be used with a clear error message . reference to a resource found on another server, since the server would not usually know what type that resource has. However, since these are absolute references, there can be no ambiguity about the type.

[type] is only allowed on reference type search parameters. When using the '[type]' modifier, all typically-valid search parameter reference inputs are allowed, but the value format is restricted to only [id] .

For example, the search: Show as: HTTP GET | HTTP POST GET [base]/Observation?subject:Patient=23 POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded subject:Patient=23 for observations where the subject is 'Patient 23' is functionally equivalent to: Show as: HTTP GET | HTTP POST GET [base]/Observation?subject=Patient/23 POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded subject=Patient/23 as well as: Show as: HTTP GET | HTTP POST GET [base]/Observation?patient=23 POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded patient=23 However, the modifier becomes more useful when used with Chaining and Reverse Chaining of search parameters.

3.1.1.4.5 3.2.1.5.3 Prefixes

For the ordered parameter types of number , date , and quantity , a prefix to the parameter value may be used to control the nature of the matching. To avoid URL escaping and visual confusion, the following prefixes are used:

Note that prefixes always test against values present in elements. In all cases, a prefix-based test against an element that does not exist will fail the test. To search for elements missing values, the use of search modifiers is required - either missing or not .

If no prefix is present, the prefix eq is assumed. Note that the way search parameters operate is not the same as the way the operations on two numbers work in a mathematical sense. sa ( starts-after ) and eb ( ends-before ) are not used with integer values but are used for decimals.

For each prefix above, two interpretations are provided - the simple intent of the prefix and the interpretation of the parameter when applied to ranges. The range interpretation is provided for decimals and dates. Searches are always performed on values that are implicitly or explicitly a range. For instance, the number 2.0 has an implicit range of 1.95 to 2.05, and the date 2015-08-12 has an implicit range of all the time during that day. If the target value is a Range , a Period , or a Timing , then the target is explicitly a range. Three ranges are identified:

The proper use of these ranges is discussed further below.

3.1.1.4.6 3.2.1.5.4 number Escaping Search Parameters

Searching on In the rules described above, special rules are defined for the characters $ ,,, and | . As a simple numerical value consequence, if these characters appear in a resource. Examples: [parameter]=100 Values that equal 100, to 3 significant figures precision, so this is actually searching for values an actual parameter value, they must be differentiated from their use as separator characters. When any of these characters appear in an actual parameter value, they must be prepended by the range [99.5 ... 100.5) character [parameter]=100.00 Values that equal 100, \ , which also must be used to 5 significant figures precision, so this is actually searching for values in the range [99.995 ... 100.005) prepend itself. Therefore, [parameter]=1e2 param=xxx$xxx Values indicates that equal 100, to 1 significant figures precision, so this it is actually searching for values in the range [95 ... 105) a composite parameter, while [parameter]=lt100 param=xx\$xx Values indicates that are less than exactly 100 the parameter has the literal value [parameter]=le100 Values that are less or equal to exactly 100 xx$xx . The parameter value [parameter]=gt100 xx\xx Values that are greater than exactly 100 is illegal, and the parameter value [parameter]=ge100 param=xx\\xx Values that are greater or equal to exactly 100 indicates a literal value of [parameter]=ne100 Values that are not equal to 100 (actually, in the range 99.5 to 100.5) xx\xx . This means that: Show as: HTTP GET | HTTP POST Notes about searching on Numbers: When a number search GET [base]/Observation?code=a,b POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded code=a,b is used against a resource element request for any Observation that stores has a simple integer (e.g. ImmunizationRecommendation.recommendation.doseNumber ), and the search parameter is not expressed using the exponential forms, and does not include any non-zero digits after code of either a decimal point, the significance issues cancel out and searching or b , whereas: Show as: HTTP GET | HTTP POST GET [base]/Observation?code=a\,b POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded code=a\,b is based on exact matches. Note that if there are non-zero digits after a decimal point, there cannot be request for any matches When Observation that has a comparison prefix in the set lgt, lt, ge, le, sa & eb is provided, the implicit precision code of the number is ignored, and they are treated as if they have arbitrarily high precision The way search parameters operate in resources a,b .

This escaping is not the same as whether two numbers are equal to each other in at a mathematical sense Searching on decimals involves an implicit range. The number of significant digits of the implicit range is different level to the number of digits specified percent encoding that applies to all URL parameters (as defined in the search parameter value, excluding leading zeros. So 100 and 1.00e2 both RFC 3986 ). Standard percent escaping still applies, such that these URLs have the same number of significant digits - three Here are some example searches: Search Description meaning: Show as: HTTP GET | HTTP POST GET [base]/RiskAssessment?probability=gt0.8 [base]/ValueSet?url=http://acme.org/fhir/ValueSet/123,http://acme.org/fhir/ValueSet/124,ValueSet/125 POST [base]/ValueSet/_search Content-Type: application/x-www-form-urlencoded url=http://acme.org/fhir/ValueSet/123,http://acme.org/fhir/ValueSet/124,ValueSet/125 Show as: HTTP GET | HTTP POST GET [base]/ValueSet?url=http%3A%2F%2Facme.org%2Ffhir%2FValueSet%2F123%2Chttp%3A%2F%2Facme.org%2Ffhir%2FValueSet%2F124%2CValueSet%2F125 POST [base]/ValueSet/_search Content-Type: application/x-www-form-urlencoded url=http%3A%2F%2Facme.org%2Ffhir%2FValueSet%2F123%2Chttp%3A%2F%2Facme.org%2Ffhir%2FValueSet%2F124%2CValueSet%2F125 Show as: HTTP GET | HTTP POST Search for all GET [base]/ValueSet?url=http://acme.org/fhir/ValueSet/123,http://acme.org/fhir/ValueSet/124\,ValueSet/125 POST [base]/ValueSet/_search Content-Type: application/x-www-form-urlencoded url=http://acme.org/fhir/ValueSet/123,http://acme.org/fhir/ValueSet/124\,ValueSet/125

This specification defines this additional form of escape because the Risk Assessments with probability great than 0.8 (could also be probability=gt8e-1 escape syntax using exponential form) GET [base]/ImmunizationRecommendation?dose-number=2 Search for any immunization recommendation recommending a second dose \ applies to all parameter values after they have been 'unescaped' on the server while being read from the HTTP headers.

3.1.1.4.7 3.2.1.5.5 date

A date parameter searches on a date/time or period. As is usual for date/time related functionality, while the concepts are relatively straight-forward, there are a number of subtleties involved in ensuring consistent behavior.

The date parameter format is yyyy-mm-ddThh:mm:ss[Z|(+|-)hh:mm] (the standard XML format).

Technically, this is any of the date , dateTime , and instant data types; datatypes; e.g. Any degree of precision can be provided, but it SHALL be populated from the left (e.g. can't specify a month without a year), except that the minutes SHALL be present if an hour is present, and you SHOULD provide a time zone timezone if the time part is present. Note: Time can consist of hours and minutes with no seconds, unlike the XML Schema dateTime type. Some user agents may escape the : characters in the URL, and servers SHALL handle this correctly.

Date searches are intrinsically matches against 'periods', regardless of the underlying element type. For more information about how the different search prefixes work when comparing periods/ranges, refer to the Prefixes section. Date parameters may be used with the following data types: datatypes:

Implicitly, a missing lower boundary is "less than" any actual date. A missing upper boundary is "greater than" any actual date. The Date searches can be controlled through the use of prefixes as described in the prefixes: following table:

Other notes:

• When the date parameter is not fully specified, matches against it are based on the behavior of intervals, where:
  • Dates with only the year specified are equivalent to an interval that starts at the first instant of January 1st to the last instant of December 31st, e.g. 2000 is equivalent to an interval of [2000-01-01T00:00, 2000-12-31T23:59].
  • Dates with the year and month are equivalent to an interval that starts at the first instant of the first day of the month and ends on the last instant of the last day of the month, e.g. 2000-04 is equivalent to an interval of [2000-04-01T00:00, 2000-04-30T23:59].
• Where possible, the system should correct for time zones timezones when performing queries. Dates do not have time zones, timezones, and time zones timezones should not be considered. Where both search parameters and resource element date times do not have time zones, timezones, the servers local time zone timezone should be assumed.

To search for all the procedures in a patient compartment that occurred over a 2-year period: Show as: HTTP GET | HTTP POST GET [base]/Patient/23/Procedure?date=ge2010-01-01&date=le2011-12-31 POST [base]/Patient/23/_search Content-Type: application/x-www-form-urlencoded Patient/23/Procedure?date=ge2010-01-01&date=le2011-12-31

Managing time zones timezones and offsets and their impact on search is a very difficult area. The FHIR implementation community is still investigating and debating the best way to handle time zones. timezones. Implementation guides may make additional rules in this regard.

Future versions of this specification may impose rules around the use of time zones timezones with dates. Implementers and authors of implementation guides should be aware of ongoing work in this area.

Implementer feedback is welcome on the issue tracker or chat.fhir.org .

3.2.1.5.6 number

Searching on a simple numerical value in a resource. Examples:

Notes about searching on Numbers:

• When a number search is used against a resource element that stores a simple integer (e.g. ImmunizationRecommendation.recommendation.doseNumber ), and the search parameter is not expressed using the exponential forms, and does not include any non-zero digits after a decimal point, the significance issues cancel out and searching is based on exact matches. Note that if there are non-zero digits after a decimal point, there cannot be any matches
• When a comparison prefix in the set gt, lt, ge, le, sa & eb is provided, the implicit precision of the number is ignored, and they are treated as if they have arbitrarily high precision
• The way search parameters operate in resources is not the same as whether two numbers are equal to each other in a mathematical sense
• Searching on decimals without using one of the comparisons listed in the earlier bullet involves an implicit range. The number of significant digits of the implicit range is the number of digits specified in the search parameter value, excluding leading zeros. So 100 and 1.00e2 both have the same number of significant digits - three

Here are some example searches:

3.2.1.5.7 quantity

A quantity parameter searches on the Quantity datatype. The syntax for the value follows the form:

• [parameter]={[prefix]}[number] matches a quantity by value , with an optional prefix
• [parameter]={[prefix]}[number]|[system]|[code] matches a quantity by value , system and code , with an optional prefix
• [parameter]={[prefix]}[number]||[code] matches a quantity by value and code or unit , with an optional prefix

The prefix is optional, and is as described in the section on Prefixes , both regarding how precision and comparator/range operators are interpreted. Like a number parameter, the number part of the search value can be a decimal in exponential format. The system and code follow the same pattern as token parameters are also optional. Note that when the [system] component has a value, it is implied that a precise (and potentially canonical) match is desired. In this case, it is inappropriate to search on the human display for the unit, which can be is uncontrolled and may unpredictable. Example searches:

Specifying a system and a code for the search implies that the search is based on a particular code system - usually UCUM , and that a precise (and potentially canonical) match is desired. In this case, it is inappropriate to search on the human display for the unit, which can be is uncontrolled and may be unpredictable.

The search processor may choose to perform a search based on canonical units (e.g. any value where the units can be converted to a value in mg in the case above). For example, an observation may have a value of 23 mm/hr . This is equal to 0.023 m/hr . The search processor can choose to normalize all the values to a canonical unit such as 6.4e-6 m/sec , and convert search terms to the same units (m/sec). Such conversions can be performed based on the semantics defined in UCUM

3.2.1.5.8 reference

A reference parameter refers to references between resources . For example, find all Conditions where the subject reference is a particular patient, where the patient is selected by name or identifier. The interpretation of a reference parameter is either:

• [parameter]=[id] the logical [id] of a resource using a local reference (i.e. a relative reference).
• [parameter]=[type]/[id] the logical [id] of a resource of a specified type using a local reference (i.e. a relative reference), for when the reference can point to different types of resources (e.g. Observation.subject ).
• [parameter]=[type]/[id]/_history/[version] TU the logical [id] of a resource of a specified type using a local reference (i.e. a relative reference), for when the reference can point to different types of resources and a specific version is requested. Note that server implementations MAY return an error when using this syntax if resource versions are not supported. For more information, see References and Versions .
• [parameter]=[url] where the [url] is an absolute URL - a reference to a resource by its absolute location, or by its canonical URL
• [parameter]=[url]|[version] TU where the search element is a canonical reference, the [url] is an absolute URL, and a specific version or partial version is desired. For more information, see References and Versions .

Notes:

• A relative reference resolving to the same value as a specified absolute URL, or vice versa, qualifies as a match.
• If a reference value is a non-versioned relative reference (e.g., does not contain [url] or _history/[version] parts), the search SHOULD match instances that match the reference in it contains a versioned reference.

For example, if the base URL of a server is http://example.org/fhir, the search: Show as: HTTP GET | HTTP POST GET http://example.org/fhir/Observation?subject=Patient/123 POST http://example.org/fhir/Observation/_search Content-Type: application/x-www-form-urlencoded subject=Patient/123 will match Observations with subject.reference values:

• Patient/123 - exact match of search input
• http://example.org/fhir/Patient/123 - search input with implicit resolution to the local server
• Patient/123/_history/1 - reference to a specific version of the search input TU

Similarly, the search: Show as: HTTP GET | HTTP POST GET http://example.org/fhir/Observation?subject=http://example.org/fhir/Patient/123 POST http://example.org/fhir/Observation/_search Content-Type: application/x-www-form-urlencoded subject=http://example.org/fhir/Patient/123 will match Observations with subject.reference values:

• http://example.org/fhir/Patient/123 - exact match of search input
• Patient/123 - search input with implicit reference to the local server

Also, the search: Show as: HTTP GET | HTTP POST GET http://example.org/fhir/Observation?subject=123 POST http://example.org/fhir/Observation/_search Content-Type: application/x-www-form-urlencoded subject=123 will match Observations with subject.reference values:

• Patient/123 - search input of type Patient
• http://example.org/fhir/Patient/123 - search input with implicit resolution to the local server, of type Patient
• Practitioner/123 - search input of type Practitioner
• http://example.org/fhir/Practitioner/123 - search input with implicit resolution to the local server, of type Practitioner
• etc.

Some references may point to more than one type of resource; e.g. subject: Reference(Patient|Group|Device|..) . In these cases, multiple resources may have the same logical identifier. Servers SHOULD reject a search where the logical id refers to more than one matching resource across different types. In order to allow the client to perform a search in these situations the type is specified explicitly: Show as: HTTP GET | HTTP POST GET [base]/Observation?subject=Patient/23 POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded subject=Patient/23

This searches for any observations where the subject refers to the patient resource with the logical identifier "23". A modifier is also defined to allow the client to be explicit about the intended type: Show as: HTTP GET | HTTP POST GET [base]/Observation?subject:Patient/23 POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded subject:Patient/23

This has the same effect as the previous search. The modifier becomes useful when used with chaining as explained in the next section. Note: The [type] modifier can't be used with a reference to a resource found on another server, since the server would not usually know what type that resource has. However, since these are absolute references, there can be no ambiguity about the type.

In some cases, search parameters are defined with an implicitly limited scope. For example, Observation has an element subject , which is a reference to one of a number of types. This has a matching search parameter subject , which refers to any of the possible types. In addition to this, there is another search parameter patient , which also refers to Observation.subject , but is limited to only include references of type Patient . When using the patient search parameter, there is no need to specify ":Patient" as a modifier, or "Patient/" in the search value, as this must always be true.

References are also allowed to have an identifier . The modifier :identifier allows for searching by the identifier rather than the literal reference: Show as: HTTP GET | HTTP POST GET [base]/Observation?subject:identifier=http://acme.org/fhir/identifier/mrn|123456 POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded subject:identifier=http://acme.org/fhir/identifier/mrn|123456

This is a search for all observations that reference a patient by a particular patient MRN. When the :identifier modifier is used, the search value works as a token search . The :identifier modifier is not supported on canonical elements since they do not have an identifier separate from the reference itself.

Chaining is not supported when using the :identifier modifier, nor are chaining, includes or reverse includes supported for reference elements that do not have a reference element.

The reference search parameter is mostly used for resource elements of type Reference or canonical . However, it is also be used to search resource elements of type Resource - i.e. where one resource is directly nested within another - see the Bundle search parameters 'message' and 'composition' as an example of this.

3.1.1.4.8 3.2.1.5.9 string

For a simple string search, a string parameter serves as the input for a search against sequences of characters. This search is insensitive to casing and included combining characters, like accents or other diacritical marks. Punctuation and non-significant whitespace (e.g. repeated space characters, tab vs space) should also be ignored. Note that case-insensitive comparisons do not take locale into account, and will result in unsatisfactory results for certain locales. Character case definitions and conversions are out of scope for the FHIR standard, and the results of such operations are implementation dependent. By default, a field matches a string query if the value of the field equals or starts with the supplied parameter value, after both have been normalized by case and combining characters. Therefore, the default string search only operates on the base characters of the string parameter. The :contains modifier returns results that include the supplied parameter value anywhere within the field being searched. The :exact modifier returns results that match the entire supplied parameter, including casing and accents.

When a string type search parameter points to a complex or backbone element (an element that contains sub-elements), by default the search is interpreted as a search against one or more string values in sub-elements, as selected by the implementation. A search parameter MAY explicitly choose elements by using an expression that instead points directly to the sub-elements. TU

For example, if a search parameter is of type string and the expression points to Patient.name , the implementation MAY search against any one or more elements of the HumanName datatype (e.g., given , family , prefix , suffix , etc.) TU . However, if the search parameter intends to explicitly match against given and family only, the search parameter should use an expression of Patient.name.given | Patient.name.family .

If the SearchParameter's narrative description includes additional considerations about what fields are indexed, SearchParameter.processingMode should have the value other .

Examples:

An additional modifier :text can be used to specify a search with advanced text handling (see below ) though only a few servers are expected to offer this facility.

When a string search parameter refers to the types HumanName and Address , the search covers the elements of type string, and does not cover elements such as use and period . For robust search, servers should search the parts of a family name independently. E.g. searching either "Carreno" or "Quinones" should match a family name of "Carreno Quinones". HL7 affiliates may make more specific recommendations about how search should work in their specific culture.

It is at the discretion of the server whether to pre-process names, addresses, and contact details to remove separator characters prior to matching in order to ensure more consistent behavior. For example, a server might remove all spaces and - characters from phone numbers. What is most appropriate varies depending on culture and context. A server may also use a free-text style searches on this property to achieve the best results.
When searching whole names and addresses (not parts), servers may also use flexible match or a free-text style searches on names to achieve the best results.

3.1.1.4.10 3.2.1.5.10 token

A token type is a parameter that provides a close to exact match search on a string of characters, potentially scoped by a URI. It is mostly used against a code or identifier data type datatype where the value may have a URI that scopes its meaning, where the search is performed against the pair from a Coding or an Identifier. Tokens are also used against other fields where exact matches are required - uris, booleans, and ContactPoints , and ids . In these cases, cases the URI portion ( [system]| ) is not used. used (only the [code] portion).

For tokens, matches are literal (e.g. not based on subsumption or other code system features). Match is case sensitive unless the underlying semantics for the context indicate that the token should be interpreted case-insensitively (see, e.g. CodeSystem.caseSensitive ). Note that matches on _id are always case sensitive. If the underlying data type datatype is string then the search is not case sensitive.

Note : There are many challenging issues around case sensitivity and token searches. Some code systems are case sensitive (e.g. UCUM) while others are known not to be. For many code systems, it's ambiguous. Other kinds of values are also ambiguous. When in doubt, servers SHOULD treat tokens in a case-insensitive manner, on the grounds that including undesired data has less safety implications than excluding desired behavior. Clients SHOULD always use the correct case when possible, and allow for the server to perform case-insensitive matching.

To use subsumption-based logic, use the modifiers below, or list all the codes in the hierarchy. The syntax for the value is one of the following:

• [parameter]=[code] : the value of [code] matches a Coding.code or Identifier.value irrespective of the value of the system property
• [parameter]=[system]|[code] : the value of [code] matches a Coding.code or Identifier.value, and the value of [system] matches the system property of the Identifier or Coding
• [parameter]=|[code] : the value of [code] matches a Coding.code or Identifier.value, and the Coding/Identifier has no system property
• [parameter]=[system]| : any element where the value of [system] matches the system property of the Identifier or Coding

Notes:

• The namespace URI and code both must be escaped correctly. If a system is not applicable (e.g. an element of type uri , then just the form [parameter]=[code] is used.
• For token parameters on elements of type id , ContactPoint , uri , or boolean , the presence of the pipe symbol SHALL NOT be used - only the [parameter]=[code] form is allowed

Token search parameters are used for the following data types: datatypes:

Data Type Datatype	URI	Code	Comments
Coding	Coding.system	Coding.code
CodeableConcept	CodeableConcept.coding.system	CodeableConcept.coding.code	Matches against any coding in the CodeableConcept
Identifier	Identifier.system	Identifier.value	Clients can search by type not system using the :of-type modifier, see below. To search on a CDA II.root - which may appear in either Identifier.system or Identifier.value , use the syntax identifier=|[root],[root]
ContactPoint		ContactPoint.value	At the discretion of the server, token searches on ContactPoint may use special handling, such as ignoring punctuation, performing partial searches etc.
code	(implicit)	code	the system is defined in the value set (though it's not usually needed)
boolean		boolean	The implicit system for boolean values is http://hl7.org/fhir/special-values http://terminology.hl7.org/CodeSystem/special-values but this is never actually used
id		id
uri		uri
string	n/a	string	Token is sometimes used for string to indicate that exact matching is the correct default search strategy

Note: The use of token search parameters for boolean fields: the boolean values "true" and "false" are also represented as formal codes in the Special Values code system, which is useful when boolean values need to be represented in a Coding data type. datatype. The namespace for these codes is http://hl7.org/fhir/special-values, http://terminology.hl7.org/CodeSystem/special-values, though there is usually no reason to use this, as a simple true or false is sufficient.

Modifiers: Modifier Use :text The search parameter is processed as a string that searches text associated with the code/value - either CodeableConcept.text , Coding.display , or Identifier.type.text . In this case, the search functions as a normal string search :not Reverse the code matching described in the paragraph above: return all resources that do not have a matching item. Note that this includes resources that have no value for the parameter - e.g. ?gender:not=male includes all patients that do not have gender = male, including patients that do not have a gender at all :above The search parameter is a concept with the form [system]|[code] , and the search parameter tests whether the coding in a resource subsumes the specified search code. For example, the search concept has an is-a relationship with the coding in the resource, and this includes the coding itself. :below the search parameter is a concept with the form [system]|[code] , and the search parameter tests whether the coding in a resource is subsumed by the specified search code. For example, the coding in the resource has an is-a relationship with the search concept, and this includes the coding itself. :in The search parameter is a URI (relative or absolute) that identifies a value set, and the search parameter tests whether the coding is in the specified value set . The reference may be literal (to an address where the value set can be found) or logical (a reference to ValueSet.url). If the server can treat the reference as a literal URL, it does, else it tries to match known logical ValueSet.url values. :not-in The search parameter is a URI (relative or absolute) that identifies a value set, and the search parameter tests whether the coding is not in the specified value set. :of-type The search parameter has the format system|code|value, where the system and code refer to a Identifier.type.coding.system and .code , and match if any of the type codes match. All 3 parts must be present Most servers will only process value sets that are already known/registered/supported internally. However, servers can elect to accept any valid reference to a value set. Servers may elect to consider concept mappings when testing for subsumption relationships.

Example searches:

3.1.1.4.10.1 3.2.1.5.11 Searching Mime Types uri

The uri parameter refers to an element that contains a URI ( RFC 3986 ). By default, matches are precise, case and accent sensitive, and the entire URI must match. The modifier :above or :below modifier is also very useful with searching mime types, such as for DocumentReference.contenttype which refers can be used to Attachment.contentType . A simple indicate that partial matching is used. For example (note that the search such parameter ValueSet.url is of type uri ): Show as: HTTP GET | HTTP POST GET [base]/ValueSet?url=http://acme.org/fhir/ValueSet/123 POST [base]/ValueSet/_search Content-Type: application/x-www-form-urlencoded url=http://acme.org/fhir/ValueSet/123 GET [base]/ValueSet?url:below=http://acme.org/fhir/ POST [base]/ValueSet/_search Content-Type: application/x-www-form-urlencoded url:below=http://acme.org/fhir/ GET [base]/ValueSet?url:above=http://acme.org/fhir/ValueSet/123/_history/5 POST [base]/ValueSet/_search Content-Type: application/x-www-form-urlencoded url:above=http://acme.org/fhir/ValueSet/123/_history/5 GET [base]/ValueSet?url=urn:oid:1.2.3.4.5 POST [base]/ValueSet/_search Content-Type: application/x-www-form-urlencoded url=urn:oid:1.2.3.4.5

• The first line is a request to find any value set with the exact url "http://acme.org/fhir/ValueSet/123"
• The second line performs a search that will miss documents return any value sets that have a URL that starts with "http://acme.org/fhir/"
• The third line shows the converse - search for any value set above a mime type such as text/xml; charset=UTF-8 . given specific URL. This search will find all text/xml documents: GET [base]/DocumentReference?contenttype:below=text/xml For ease of processing match on any value set with the server, servers specified URL, but also on http://acme.org/ValueSet/123. Note that there are only required not many use cases where :above is useful as compared to support the :below on the base part search
• The fourth line shows an example of searching by an OID. Note that the mime type; servers are not required :above and :below modifiers only apply to sort between different parameters URLs, and do formal subsumption logic. not URNS such as OIDs

The search type uri is used with elements of type uri and url . The type reference is used for the types Reference and canonical .

3.1.1.4.11 3.2.1.5.12 quantity Special Parameters

A quantity few parameters have the type 'special'. That indicates that the way this parameter searches on works is unique to the Quantity data type. The syntax for parameter and described with the value follows parameter. The general modifiers and comparators do not apply, except as stated in the form: description.

Implementers will generally need to do special implementations for these parameters. These parameters are special:

• [parameter]=[prefix][number]|[system]|[code] matches a quantity with the given unit _filter (all resources)
• section-text on Composition
• contains on Location
• near on Location

3.2.1.5.13 Composite Search Parameters

The prefix is optional, and is as described above , both regarding how precision and comparator/range operators Composite search parameters are interpreted. Like allow joining multiple elements into distinct single values with a number parameter, $ . This is different from doing a simple intersection - the number part intersection rules apply at the resource level, so, for example, an Observation with multiple component repetitions may match because one repetition has a desired code and a different repetition matches a value filter.

The composite parameter approach works in this context because it allows searches based on a tuples of values. For example: Show as: HTTP GET | HTTP POST GET [base]/Observation?code-value-quantity=code$loinc|12907-2,value$ge150|http://unitsofmeasure.org|mmol/L POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded code-value-quantity=code$loinc|12907-2,value$ge150|http://unitsofmeasure.org|mmol/L will match Observation records with a LOINC code of "12907-2" (Sodium [Moles/volume] in Red Blood Cells) AND a value greater than "150 mmol/L".

Note that the search sequence is a single value and itself can be composed into a decimal in exponential format. The system set of values. For example, searching Group.characteristic , searching for multiple key/value pairs (instead of an intersection of matches on key and value): Show as: HTTP GET | HTTP POST GET [base]/Group?characteristic-value=gender$mixed,owner$Eve POST [base]/Group/_search Content-Type: application/x-www-form-urlencoded characteristic-value=gender$mixed,owner$Eve will match Groups that have a code gender follow characteristic of "mixed" (the group contains people of multiple genders) OR the same pattern as token parameters group has a owner characteristic of "Eve".

Note that search modifiers are also optional. Example searches: NOT allowed on composite parameters.

Examples of using composite parameters:

GET [base]/Observation?value-quantity=le5.4|http://unitsofmeasure.org|mg 3.2.1.6 Special Search Conditions

In addition to 'basic' searching, this specification defines behaviors for all the observations where the value of is less than 5.4 mg exactly where mg is understood as a UCUM unit many 'special' cases that are common across implementations.

3.2.1.6.1 Searching Identifiers GET [base]/Observation?value-quantity=ap5.4|http://unitsofmeasure.org|mg

In FHIR data, there are a few types of is about 5.4 mg where mg is understood as identifiers that may apply to a UCUM unit (typically, within 10% resource: a single logical identifier (the Resource.id of a resource), zero or more Identifier-type elements (e.g., Patient.Identifier ), and, if the value - see above) resource is a Canonical Resource , a canonical url . Each of these 'identifiers' have a different datatype and expose different search functionality. Some details about each are included below.

3.2.1.6.1.1 Logical Identifiers

Specifying The Logical Identifier of a system and resource represents a code unique key for an instance within a specific context (e.g., a single resource type in a server collection, a resource in a bundle, etc.). Searching by the search implies that the search logical id of an instance is based on a particular code system - usually UCUM done via the , and _id search parameter.

Given that a precise (and potentially canonical) match logical id is desired. unique in the context, searching by id will always result in either zero or one records. In this case, it many ways, the search is inappropriate functionally equivalent to an equivalent simple read operation . However, there are some differences in using search on the human display for instead of read:

• Search operations always return bundles.
  • If the unit, which id exists (and can be is uncontrolled and may unpredictable. The search processor may choose to perform returned), the result will be a search based on canonical units (e.g. any value where bundle containing the units can resource (search) instead of the resource itself (read).
  • If the id does not exist (or cannot be converted to returned), the result of a value valid search will still be a bundle. The bundle MAY include further information in mg the form of an OperationOutcome . See Handling Errors for more information.
• Additional resources can be requested and/or returned in the case above). same request - see Including Other Resources for more information.
• Additional search functionality is available. For example, an observation may have asking for a value Patient resource by id, but also setting the search criteria of 23 mm/hr . This is equal deceased to 0.23 m/hr . The search processer can choose to normalise all true would only return the values to a canonical unit such as Patient if they are deceased.

Since 6.4e-6 m/sec , _id requires a resource type context and convert search terms to the same units (m/sec). Such conversions there can only be performed based on zero or one resources of a type with a given id, the semantics defined in UCUM search is functionally equivalent to the simple read operation of GET [base]/Patient/23 . However, searching by logical identifier means that all other search functionality is available - e.g., OperationOutcome resources for issues, additional search parameters, inclusion of additional resources, etc..

3.1.1.4.12 3.2.1.6.1.2 reference Searching by Membership

A reference parameter refers to references between Some resources . (e.g., Group , List , and CareTeam ) are used to maintain collections of other resources. For example, find all Conditions where the subject reference is a particular patient, where the patient is selected by name or identifier. The interpretation Group of Patients representing a reference parameter cohort or a List of patient allergies. While it is either: possible to retrieve the collection resource, iterate over the entries, and fetch each referenced resource, using search criterion allows for fewer round-trips and additional search criteria to be specified in-line.

There are two standard search parameters defined by this specification to support searching against collection resources:

• [parameter]=[id] _in the logical [id] of a resource using a local reference (i.e. a relative reference) to test against active membership, and
• [parameter]=[type]/[id] _list the logical [id] of a resource of a specified type using a local reference (i.e. a relative reference), for when the reference can point to different types of resources (e.g. Observation.subject test against advanced List functionality (e.g., functional list definitions ) ).

[parameter]=[url] 3.2.1.6.1.3 Identifiers and References where the [url]

The Identifier datatype is an absolute URL - typically only used on by a reference to single element in a resource by its absolute location, and is typically named identifier . The element is typically cardinality 0..* , meaning that resources may have zero, one, or by it's canonical URL Note: A relative reference resolving more identifiers attached to the same value as a specified absolute URL, or vice versa, qualifies as them (e.g., a match. For example, if the search parameter value is Patient/123, then this will find references like this: single patient record with MRNs for several related facilities).

If Resources containing identifier elements usually expose a matching search parameter, e.g., Patient.identifier or CanonicalResource.identifier . Given the server base address is http://example.org/fhir, then structure of the full URL for that reference identifier type, the search parameter is http://example.org/fhir/Patient/123, which means that a token type - see the token search term also matches patient references like this: <patient> <reference value="http://example.org/fhir/Patient/123"/> </patient> In addition, searching type for reference=http://example.org/fhir/Patient/123 will also match both references. details.

Some references may point It is often useful to more than one type of resource; e.g. subject: Reference(Patient|Group|Device|..). In these cases, multiple resources may search via reference across resource links. For example, if you have the same logical identifier. Servers SHOULD reject MRN for a search where patient and do not know the logical id refers to more than one matching resource across different types. In order to allow the client identifier, it is desireable to perform a search in these situations the type is specified explicitly: GET [base]/Observation?subject=Patient/23 This searches like "encounters for any observations where the subject refers to the patient resource with the logical identifier "23". A modifier MRN 1234". There are two ways of searching references by identifier, depending on how data is also defined to allow the client to be explicit about the intended type: GET [base]/Observation?subject:Patient=23 This has the same effect as stored in the previous search. The modifier becomes useful when used with system: via chaining as explained in or via the next section. Note: The [type] identifier modifier can't be used with a reference to a resource found on another server, since the server would not usually know what type that resource has. However, since these are absolute references, there can be no ambiguity about the type. In some cases, search parameters are defined with an implicitly limited scope. For example, modifier.

3.2.1.6.1.4 Canonical Identifiers has an element subject , which is

Chaining functions by resolving a resource reference to one of a number of types. This has a matching and then searching inside it. In this case, requesting: Show as: HTTP GET | HTTP POST GET [base]/Encounter?patient.identifier=http://example.org/facilityA|1234 POST [base]/Encounter/_search Content-Type: application/x-www-form-urlencoded patient.identifier=http://example.org/facilityA|1234 will search parameter subject , which refers to any of Encounter resources, following references in the possible types. In addition to this, there is another patient search parameter ("the patient , which also refers to present at the encounter"), and testing those Patient resources against the Observation.subject , Patient.identifier value of 1234 in system http://example.org/facilityA . In short, this search will return all Encounters for Patient records matching "1234" in "facilityA".

This search is flexible, but does require resolving (searching against) Patient resources, even though the request is limited to only for Encounters. If a system wants to enable searches via identifiers without chaining, the server can include references of type additional information in the Reference Datatype (in Reference.identifier ), which is then accessible by the Patient identifier . When using search modifier. Note that this approach requires additional bookkeeping by the server - if a patient search parameter, there record is no modified, e.g., to add an additional identifier, every resource that reference that patient record would need to specify ":Patient" as a modifier, or "Patient/" in the search value, as this must always be true. updated.

References are also allowed to have an The identifier . The modifier :identifier allows for searching functions by testing the identifier rather than the literal reference: GET [base]/Observation?subject:identifier=http://acme.org/fhir/identifier/mrn|123456 This is a Reference.identifier element within resources. In this case, requesting: Show as: HTTP GET | HTTP POST GET [base]/Encounter?patient:identifier=http://example.org/facilityA|1234 POST [base]/Encounter/_search Content-Type: application/x-www-form-urlencoded patient:identifier=http://example.org/facilityA|1234 will search for all observations that reference a patient by a particular patient MRN. When Encounter resources, testing the :identifier modifier is used, Encounter.subject.identifier element against the search value works as a token of 1234 in system http://example.org/facilityA . In short, this search . The :identifier modifier is not supported on canonical elements since they do not will return all Encounters for that have an Patient references and include the identifier separate "1234" from the reference itself. "facilityA".

Chaining Note that the difference between the two searches is not supported when using a single character - the :identifier modifier, nor are chaining, includes or reverse includes supported for reference elements that do not have . (period) in the first example represents a reference chained search and the : element. (colon) in the second indicates the use of a search modifier.

3.2.1.6.1.5 Canonical Identifiers

The reference search parameter is mostly used for resource elements of type Reference or Canonical Resources are identified by their url and possibly a version. Similarly, references to canonical . However, it is also resources are made with the canonical datatype. More details about canonical references can be used to search resource elements found in the Canonical URLs section of the references page.

When searching canonical references, the search type Resource - i.e. where one resource is directly nested within another - reference , though with an additional syntax for version information. For more information about version resolution, see the Bundle search parameters 'message' References and 'composition' as an example Versions section of this. this page.

3.1.1.4.13 3.2.1.6.2 References and Versions

Elements of type Reference may contain a versioned reference: Show as: FHIR+JSON | FHIR+XML { "resourceType": "Condition", ... "evidence": { "detail": { "reference": "Observation/123/_history/234234" } }, ... } <Condition> ... <evidence> <detail> <reference value="Observation/123/_history/234234"/> </detail> </evidence> ... </Condition>

When searching on versioned references, the following rules apply:

• If a resource has a reference that is versioned, versioned and chaining is performed, the criteria should ideally be evaluated against the version referenced, but most systems will not be capable of this because search is only defined to function against the current version of a resource
• Where a search does not act on the referenced version, search results SHOULD contain a OperationOutcome with a warning that indicates the discrepancy
• If a resource has a reference that is versioned and _include the resource is performed, included (e.g., _include , _revinclude ), the specified version SHOULD be provided.
• If a reference-type search parameter does not contain a version (i.e., no /_history/[version] in the URL), the search will match against resources containing both versioned and un-versioned references.

Elements of type canonical may contain a version specific reference, but this version is different in both meaning and format to version specific references that might be found in a Reference : Show as: FHIR+JSON | FHIR+XML { "resourceType": "QuestionnaireResponse", ... "questionnaire": "http://example.org/fhir/questionnaire/patient-intake|3.0", ... } <QuestionnaireResponse> ... <questionnaire value="http://example.org/fhir/questionnaire/patient-intake|3.0"/> ... </QuestionnaireResponse>

This version is a reference to the business version of the resource.

For canonical references, servers SHOULD support searching by Canonical URLs, and SHOULD support automatically detecting a |[version] portion as part of the search parameter and interpreting that portion as a search on the business version of the target resource. The modifier :below is used with canonical references, to control whether the version is considered in the search. The search: GET {base]/Observation?definition:below=http:http://acme.com/some-profile matches all of these element values: Show as: HTTP GET | HTTP POST GET [base]/QuestionnaireResponse?questionnaire:below=http://example.org/fhir/questionnaire/patient-intake POST [base]/QuestionnaireResponse/_search Content-Type: application/x-www-form-urlencoded questionnaire:below=http://example.org/fhir/questionnaire/patient-intake would match QuestionnaireResponses based on Questionnaires:

• http://acme.com/some-profile|1.0 http://example.org/fhir/questionnaire/patient-intake|1.0
• http://acme.com/some-profile|1.1 http://example.org/fhir/questionnaire/patient-intake|1.1
• http://acme.com/some-profile|2.0 http://example.org/fhir/questionnaire/patient-intake|2.0
• etc.

The search: GET {base]/Observation?definition:below=http:http://acme.com/some-profile|1 matches Show as: HTTP GET | HTTP POST GET [base]/QuestionnaireResponse?questionnaire:below=http://example.org/fhir/questionnaire/patient-intake|1 POST [base]/QuestionnaireResponse/_search Content-Type: application/x-www-form-urlencoded questionnaire:below=http://example.org/fhir/questionnaire/patient-intake|1 would match QuestionnaireResponses based on Questionnaires with a major version of '1', e.g.:

• http://example.org/fhir/questionnaire/patient-intake|1.0
• http://example.org/fhir/questionnaire/patient-intake|1.1

3.1.1.4.14 3.2.1.6.3 Searching Hierarchies

Some references are circular - that is, the reference points to another resource of the same type. When the reference establishes a strict hierarchy, the modifiers :above and :below may be used to search transitively through the hierarchy: Show as: HTTP GET | HTTP POST GET [base]/Procedure?location:below=42 POST [base]/Procedure/_search Content-Type: application/x-www-form-urlencoded location:below=42

This search returns no not only all procedures that occurred at location with id 42, but also any procedures that occurred in locations that are part of location with id 42.

Show as: HTTP GET | HTTP POST GET [base]/MedicationAdministration?encounter:above=21 POST [base]/MedicationAdministration/_search Content-Type: application/x-www-form-urlencoded encounter:above=21

Returns all medication administrations that happened during encounter with id 21 or during any "parent" encounter of that encounter.

Servers indicate that :above/:below is supported on a search parameter by defining them as Modifiers on the Search Parameter definition.

3.1.1.4.15 3.2.1.6.4 Chained Searching MIME Types

The :below modifier is also very useful with searching MIME type , such as the search parameter DocumentReference.contenttype , which refers to Attachment.contentType . A simple search such as: Show as: HTTP GET | HTTP POST GET [base]/DocumentReference?contenttype=text/xml POST [base]/DocumentReference/_search Content-Type: application/x-www-form-urlencoded contenttype=text/xml will miss documents with a MIME type such as text/xml; charset=UTF-8 . This search will find all text/xml documents: Show as: HTTP GET | HTTP POST GET [base]/DocumentReference?contenttype:below=text/xml POST [base]/DocumentReference/_search Content-Type: application/x-www-form-urlencoded contenttype:below=text/xml

For ease of processing on the server, servers are only required to support :below on the base part of the MIME type; servers are not required to sort between different parameters and do formal subsumption logic.

Additionally, the below modifier can be applied to the first segment only: Show as: HTTP GET | HTTP POST GET [base]/DocumentReference?contenttype:below=image POST [base]/DocumentReference/_search Content-Type: application/x-www-form-urlencoded contenttype:below=image will match all image/ content types, e.g., "image/png", "image/jpeg", etc.

3.2.1.6.5 Chaining (chained parameters)

In order to save a client from performing a series of search operations, reference parameters may be "chained" by appending them with a period ( . ) followed by the name of a search parameter defined for the target resource. This can be done recursively, following a logical path through a graph of related resources, separated by . . For instance, given that the resource DiagnosticReport has a search parameter named subject , which is usually a reference to a Patient resource, and the Patient resource includes a parameter name which searches on patient name, then the search GET [base]/DiagnosticReport?subject.name=peter search: Show as: HTTP GET | HTTP POST GET [base]/DiagnosticReport?subject.name=peter POST [base]/DiagnosticReport/_search Content-Type: application/x-www-form-urlencoded subject.name=peter is a request to return all the lab reports that have a subject whose name includes "peter". Because the Diagnostic Report subject can be one of a set of different resources, it's necessary to limit the search to a particular type: GET [base]/DiagnosticReport?subject:Patient.name=peter Show as: HTTP GET | HTTP POST GET [base]/DiagnosticReport?subject:Patient.name=peter POST [base]/DiagnosticReport/_search Content-Type: application/x-www-form-urlencoded subject:Patient.name=peter This request returns all the lab reports that have a subject which is a patient, whose name includes "peter".

Note that chained parameters are applied independently to the target resource. For example, GET Patient?general-practitioner.name=Joe&general-practitioner.address-state=MN Show as: HTTP GET | HTTP POST GET [base]/Patient?general-practitioner.name=Joe&general-practitioner.address-state=MN POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded general-practitioner.name=Joe&general-practitioner.address-state=MN may return Patients cared for by Joe from CA and Jane from MN: no one practitioner need satisfy both conditions. E.g. the chains are evaluated separately. For use cases where the joins must be evaluated in groups, there are either Composite search parameters, or the _filter parameter.

Note that chained search parameters are not intended to work with search modifiers . While their use is not prohibited, searches requiring advanced matching across resources are encouraged to use Named Queries or Advanced filtering .

Advanced Search Note: Where a chained parameter searches a resource reference that may have more than one type of resource as its target, the parameter chain may end up referring to search parameters with the same name on more than one kind of resource at once. Servers SHOULD reject a search where the logical id refers to more than one matching resource across different types. For example, the client has to specify the type explicitly using the syntax in the second example above.

3.1.1.4.16 3.2.1.6.6 Reverse Chaining

The _has parameter provides limited support for reverse chaining - that is, selecting resources based on the properties of resources that refer to them (instead of chaining, above, where resources can be selected based on the properties of resources that they refer to). Here is an example of the _has parameter: Show as: HTTP GET | HTTP POST GET [base]/Patient?_has:Observation:patient:code=1234-5 POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded _has:Observation:patient:code=1234-5

This requests the server to return Patient resources, where the patient resource is referred to by at least one Observation where the observation has a code of 1234, and where the Observation refers to the patient resource in the patient search parameter.

"Or" searches are allowed (e.g. GET [base]/Patient?_has:Observation:patient:code=123,456), _has:Observation:patient:code=123,456 ), and multiple _has parameters are allowed (e.g. GET [base]/Patient?_has:Observation:patient:code=123&_has:Observation:patient:code=456). _has:Observation:patient:code=123&_has:Observation:patient:code=456 ). Note that each _has parameter is processed independently of other _has parameters.

The _has parameter can be chained, nested, like this: GET [base]/Patient?_has:Observation:patient:_has:AuditEvent:entity:user=MyUserId Fetch Show as: HTTP GET | HTTP POST GET [base]/Patient?_has:Observation:patient:_has:AuditEvent:entity:agent=MyUserId POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded _has:Observation:patient:_has:AuditEvent:entity:agent=MyUserId This search will fetch all the patients Patient records that have an Observation where the observation has an audit event from a specific user.

If, instead, the search is to find patients that speak either language, then this is a single parameter with multiple values, separated by a , . For example, The /Patient?language=FR,NL . This is known as an OR search parameter, since the server is expected to respond with results which match either value. Every search _has parameter may can also be used with comma-separated values in this fashion; this includes the use of search parameters with modifiers, such as `?code:text=this,that. AND parameters and OR parameters may also be combined, chained-searches, for example: /Patient?language=FR,NL&language=EN would refer Show as: HTTP GET | HTTP POST GET [base]/Encounter?patient._has:Group:member:_id=102 POST [base]/Encounter/_search Content-Type: application/x-www-form-urlencoded patient._has:Group:member:_id=102 to any patient who speaks English, as well as either French or Dutch. This approach allows for simple combinations of and/or values, but doesn't allow a search based on a pair of values, such as all observations with a sodium value >150 mmol/L (particularly as for the end criteria of a chained search), or searching on Group.characteristic where you need find a combination Encounters of key/value, not an intersection patients that are members of separate matches on key and value. Another example is spatial coordinates when doing geographical searches. the Group "102".

To allow these searches, a resource may also specify composite parameters that take sequences of single values Note that match other defined reverse-chained search parameters as an argument. The matching parameter of each component in such a sequence are not intended to work with search modifiers . While their use is documented in not prohibited, the definition syntax of the parameter. These sequences are formed by joining the single values with a $ . Note: This sequence is a single value _has makes construction and itself can be composed into a set of values, so that, for example, multiple parsing error-prone. Searches requiring advanced matching characteristic-value parameters can be specified as GET [base]/Group?characteristic-value=gender$mixed,owner$Eve . Note: Modifiers across resources are not used on composite parameters. Examples of using composite parameters: encouraged to use Named Queries or Advanced filtering .

3.1.1.4.18 3.2.1.6.7 Handling Missing Data

Consider the case of searching for all AllergyIntolerance resources: Show as: HTTP GET | HTTP POST GET [base]/AllergyIntolerance?clinical-status=http://terminology.hl7.org/CodeSystem/allergyintolerance-clinical|active POST [base]/AllergyIntolerance/_search Content-Type: application/x-www-form-urlencoded clinical-status=http://terminology.hl7.org/CodeSystem/allergyintolerance-clinical|active

This search will only return resources that have a value for clinicalStatus: Show as: FHIR+JSON | FHIR+XML { "resourceType" : "AllergyIntolerance", "clinicalStatus": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/allergyintolerance-clinical", "code": "active" } ] } } <AllergyIntolerance> <clinicalStatus> <coding> <system value="http://terminology.hl7.org/CodeSystem/allergyintolerance-clinical"/> <code value="active"/> </coding> </clinicalStatus> </AllergyIntolerance>

Resources missing a clinicalStatus will not be returned. This is probably unsafe - it would not usually be appropriate to ignore AllergyIntolerance warnings with an unknown clinical status, and only return resources with an explicit clinicalStatus. Instead, it might be desired to return AllergyIntolerance resources with either an explicit value for clinicalStatus, or none: Show as: HTTP GET | HTTP POST GET [base]/AllergyIntolerance?clinical-status=http://terminology.hl7.org/CodeSystem/allergyintolerance-clinical|active POST [base]/AllergyIntolerance/_search Content-Type: application/x-www-form-urlencoded clinical-status=http://terminology.hl7.org/CodeSystem/allergyintolerance-clinical|active GET [base]/AllergyIntolerance?clinical-status:missing=true POST [base]/AllergyIntolerance/_search Content-Type: application/x-www-form-urlencoded clinical-status:missing=true

Note that this is 2 separate queries. They can be combined in a batch , but not in a single operation. This query will always return an empty list, as no resource can satisfy both criteria at once: Show as: HTTP GET | HTTP POST GET [base]/AllergyIntolerance?clinical-status=http://terminology.hl7.org/CodeSystem/allergyintolerance-clinical|active&clinical-status:missing=true POST [base]/AllergyIntolerance/_search Content-Type: application/x-www-form-urlencoded clinical-status=http://terminology.hl7.org/CodeSystem/allergyintolerance-clinical|active&clinical-status:missing=true

There is no way to use the :missing modifier and mix with a value using the comma syntax documented above for composite search parameters.

An alternative approach is to use the _filter parameter, for servers that support this parameter.

3.1.1.4.23 3.2.1.6.8 Advanced filtering

The search mechanism described above is flexible, and easy to implement for simple cases, but is limited in its ability to express combination queries. To complement this mechanism, the "_filter" _filter search expression parameter can be used.

For example, "Find all the observations for patient with a name including peter that have a LOINC code 1234-5 ": Show as: HTTP GET | HTTP POST GET [base]/Observation?code=http://loinc.org|1234-5&subject.name=peter POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded code=http://loinc.org|1234-5&subject.name=peter

Using the _filter parameter, the search would be expressed like this: this (note that the value is unescaped for readability): Show as: HTTP GET | HTTP POST GET [base]/Observation?_filter=code eq http://loinc.org|1234-5 and subject.name co "peter" POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded _filter=code eq http://loinc.org|1234-5 and subject.name co "peter"

The _filter parameter is described in detail on the "_Filter Parameter" page .

3.1.1.4.24 3.2.1.6.9 Specifying the type of Searching Multiple Resource Types

Normally, a search is initiated against a known type of resource, e.g. GET [base]/Observation?params... e.g.: Show as: HTTP GET | HTTP POST GET [base]/Observation?params... POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded params... However, in some circumstances, a search is executed where there is no fixed type of resource: resource, for example:

• Using search across all resource types (GET [base]?params...) ( [base]?params... )
• Using search with messaging
• Some search specifications inside other services e.g. decision support usage

In these circumstances, the search criteria may need to specify one or more resource types that the search applies to. This can be done by using the standard search parameter _type parameter: .

If no type is specified, the only search parameters that be can be used in global search like this are the base parameters that apply to all resources. resources .

If a single type is specified, all search parameters for that type are allowed.

If multiple types are specified, any all search parameters shared across that can be referenced commonly between resources can be used (e.g., listed with the entire set same name in the CapabilityStatement, typically the value of specified resources may SearchParameter.code ) TU . For example, both Patient and Person define a search parameter referenced by name . Assuming a server implements both parameters and uses name to do so, the name parameter can be used (see to search across both Patient and Person resources. Note that this is allowed even though the search parameters do not share a common definition. If a request references multiple parameters that are not the same type (e.g., if one parameter registry is a number type and another is a token type, despite sharing the same name), this is an error and servers SHOULD return a 400 status TU .

3.2.1.6.10 Implicit Resources

Some resources are defined implicitly rather than as explicit instances (e.g. Implicit Code Systems ). When searching resources where implicit instances might exist, it is up to the server whether they will include implicit resources as part of the search set. Implementation Guides MAY set specific expectations about search behavior around implicit resources. TU

3.2.1.6.11 Named Queries

Technically, The search framework described above is a useful framework for providing a simple search based on indexed criteria, but more sophisticated query capability is needed to handle precise queries, complex decision support-based requests, and direct queries that have human resolution. To support more advanced functionality, this specification defines a method for creating and using named .

The _query parameter names a custom search profile that describes a specific query operation. The named query may define additional named parameters that are used with that particular named query. Servers can define their own additional named queries to meet their own uses using an OperationDefinition .

Query operations are only allowed in the _type base and type search contexts . Named queries cannot be defined at the instance level. Query operations SHOULD NOT be invoked via any method other than search with the _query parameter (e.g., servers SHOULD NOT execute query operations via [base]/$[operation code] , etc.). TU

For named queries, all the standard search parameters (parameters for all resources and search result parameters) are potentially available for use in addition to any parameters defined by the query operation. In addition, if the query operation is defined in the scope of a token specific resource, the search parameters for that resource are also potentially available. For example, a named query with a scope of Patient could include the _lastUpdated , _sort , and/or Patient.gender search parameters, even if those aren't explicitly listed as parameters on the query operation.

Servers do not need to support ANY such 'inherited' parameters unless explicitly documented in the operation's description. Clients should not assume the availability of any search parameter that is not supported for general queries (i.e. listed in the server's CapabilityStatement , either in CapabilityStatement.rest.searchParam or CapabilityStatement.rest.resource.searchParam ). Servers MAY further document the search parameters they support for a specific query operation - either in text or by defining a constrained operation based on the Resource Types original that explicitly enumerates all supported parameters. TU

In order to ensure consistent behavior, authors SHOULD include relevant search parameters in the named query definition ( OperationDefinition ). TU

For example, the operation definition: Show as: FHIR+JSON Value Set. | FHIR+XML { "resourceType": "OperationDefinition", "id": "current-high-risk", "url": "http://example.org/OperationDefinition/current-high-risk", "version": "0.0.1", "name": "Current High-Risk Patients", "status": "draft", "kind": "query", "description": "Filter Patients based on risk assessments", "code": "current-high-risk", "resource": [ "Patient" ], "system": false, "type": true, "instance": false, "parameter": [ { "name": "ward", "use": "in", "min": 0, "max": "*", "documentation": "Ward filters to apply to patient locations", "type": "string", "searchType": "reference" }, { "name": "return", "use": "out", "min": 1, "max": "1", "documentation": "Searchset bundle", "type": "Bundle" } ] } <OperationDefinition xmlns="http://hl7.org/fhir"> <id value="current-high-risk" /> <url value="http://example.org/OperationDefinition/current-high-risk" /> <version value="0.0.1" /> <name value="Current High-Risk Patients" /> <status value="draft" /> <kind value="query" /> <description value="Filter Patients based on risk assessments" /> <code value="current-high-risk" /> <resource value="Patient" /> <system value="false" /> <type value="true" /> <instance value="false" /> <parameter> <name value="ward" /> <use value="in" /> <min value="0" /> <max value="*" /> <documentation value="Ward filters to apply to patient locations" /> <type value="string" /> <searchType value="reference" /> </parameter> <parameter> <name value="return" /> <use value="out" /> <min value="1" /> <max value="1" /> <documentation value="Searchset bundle" /> <type value="Bundle" /> </parameter> </OperationDefinition>

Note that operations defined as named queries (using a OperationDefinition.kind of query ) SHOULD NOT be invoked via any mechanism other than search (i.e., do not expose [base]/[type]/$[operation code] ) TU .

3.1.1.5 3.2.1.7 Managing Returned Resources Modifying Search Results

Along with search parameters that are used as input to search filters, there are also Search Result Parameters defined by this specification to modify the results of a performed search. These parameters control aspects of the results such as sort order, including additional resources, etc., and are defined in the following sections. Note that since these are not search parameters, they do not have definitions as SearchParameter resources and do not appear in the search parameter registry .

Note that with the exception of _include and _revinclude , search result parameters SHOULD only appear once in a search. If such a parameter appears more than once, the behavior is undefined and a server MAY treat the situation as an error TU .

The search result parameters defined by this specification are:

3.1.1.5.1 3.2.1.7.1 Sorting (_sort)

The client can indicate which order to return the results by using the parameter _sort , which can contain a comma-separated list of sort rules in priority order: Show as: HTTP GET | HTTP POST GET [base]/Observation?_sort=status,-date,category POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded _sort=status,-date,category

Each item in the comma separated comma-separated list is a search parameter, optionally with a '-' prefix. The prefix indicates decreasing order; in its absence, the parameter is applied in increasing order.

Notes:

• When sorting, the actual sort value used is not returned explicitly by the server for each resource, just the resource contents.
• To sort by relevance, use _score .
• The server returns the sort it performs as part of the returned search parameters (see below ).
• A Servers have discretion on the implementation of sorting for both repeated elements and complex elements. For example, if requesting a sort on Patient.name , servers might search parameter can refer to an element that repeats, by family name then given, given name then family, or prefix, family, and therefore there can be then given. Similarly, when sorting with multiple values for a given search parameter for a single resource. In this case, names, the sort is might be based on the item in the set of multiple parameters that comes earliest 'earliest' name in the specified sort order when ordering or the returned resources. first name in the instance.
• When sorting on string search parameters, sorting SHOULD be performed on a case-insensitive basis. Accents may either be ignored or sorted as per realm convention.
• This specification does not specify exacts exact rules for consistency of sorting across servers. In general, this is deemed to be not as essential as consistency of filtering (though even that is a little variable). The purpose of sorting is to provide data in a "reasonable" order for end-users. "Reasonable" may vary by use case and realm, particularly for accented characters.
The _total
• When sorting on search parameters of reference and token types, the search parameter has MAY include the status trial-use text modifier pending real world experience to request sorting based on the text or display portions of it's use. the element values. For example, _sort=code:text or _sort:-code:text .
• When sorting on search parameters of date type, if the source data is not a single instance (e.g. a Period ) the sort behavior is server-defined. If more prescribed search behavior is needed, custom search parameters that assert specific behavior can be defined. Note that most reference implementations search by the start of the period.

3.1.1.5.2 3.2.1.7.2 Total number of matching resources (_total)

The return Bundle has an element total which is the number of resources that match the search parameters.

Note that Bundle.total represents the total number of matches, not how many resources are returned in a particular response (see paging , immediately below). ).

Providing a precise number of matching resources may be onerous for the server, depending on how the server is designed. To help reduce the server load, a client can provide the parameter _total to indicate it's its preference with regard to the total, which can have one of the following values:

The Bundle.total element is still optional, and the servers can ignore the _total parameter: it is just an optimization hint, that might possibly save the server some work.

3.1.1.5.3 3.2.1.7.3 Limiting Page Count Size (_count)

In order to keep the load on clients, servers servers, and the network minimized, the server may choose to return the results in a series of pages. The search result set contains the URLs that the client uses to request additional pages from the search set. For a simple RESTful search, the page links are contained in the returned bundle as links .

Typically, a server will provide its own parameters in the links that it uses to manage the state of the search as pages are retrieved. These parameters do not need to be understood or processed by the client.

The parameter _count is defined as an instruction to the server regarding how many resources should be returned in a single page. Servers SHALL NOT return more resources in a single page than requested, even if they don't support paging, but may return less than the client requested. NOTE: This means that all servers that support search or history SHALL support checking the _count parameter. The server should repeat SHOULD ensure that any pages reachable via links (e.g. previous/next) respect the the original requested _count parameter in its returned expectations (or a server-overridden max page links so that subsequent paging requests honor the original _count . size). Note: It is at the discretion of the search engine as to how to handle ongoing updates to the resources while the search is proceeding.

Note: The combination of _sort and _count can be used to return only the latest resource that meets a particular criteria - set the criteria, and then sort by date in descending order, with _count=1 . This way, the last matching resource will be returned.

if If _count has the value 0, this shall be treated the same as _summary=count : the server returns a bundle that reports the total number of resources that match in Bundle.total, but with no entries, and no prev/next/last links. Note that the Bundle.total only include the total number of matching resources. It does not count extra resources such as OperationOutcome or included resources that may also be returned. In the same way, the _count parameter only applies to resources with entry.search.mode = search match , and does not include included resources or operation outcomes.

The _count parameter has no impact on the value of Bundle.total as the latter represents the total number of matches, not how many are returned in a single Bundle response.

3.1.1.5.4 3.2.1.7.4 Including other Limiting Total Result Size (_maxresults) TU

In some scenarios, a client knows that it will only process a certain number of results for a search, regardless of how many records there are. For example, if an application is providing an overview of patient activity and will only display the most recent observation on a summary screen, telling the server that additional records will never be retrieved allows the server to free any resources that might have been reserved for paging.

The parameter _maxresults is defined as an instruction to the server regarding the limit on how many total resources should be returned from a query. If supported, a server SHOULD NOT return more resources than requested. As with other parameters, servers supporting _maxresults SHALL include this parameter in result ( the Self Link when returning results.

The _include _maxresults parameter has no impact on the value of Bundle.total as the latter represents the total number of matches, not how many are returned in a response.

The combination of _sort and _revinclude _maxresults ) can be used to return only the latest resource that meets a particular criteria - set the criteria, and then sort by date in descending order, with _maxresults=1 . This way, the last matching resource will be returned.

Note that _maxresults does not absolve a server from paging requirements. For example, a client can request _maxresults=10&_count=5 to receive (at most) two pages of five results each.

3.2.1.7.5 Summary (_summary)

Clients may The client can request that the engine server to return only a portion of the resources related by using the parameter _summary : Show as: HTTP GET | HTTP POST GET [base]/ValueSet?_summary=true POST [base]/ValueSet/_search Content-Type: application/x-www-form-urlencoded _summary=true

The _summary parameter requests the server to return a subset of the search results, resource. It can contain one of the following values:

The intent of the _summary parameter is to reduce the total processing load on server, client, and resources between them such as the network. It is most useful when for resources that are large, particularly ones that include images or elements that may repeat many times. The purpose of the summary form is to allow a client to quickly retrieve a large set of resources, and let a user pick the appropriate one. The summary for an element is searching defined to allow a user to quickly sort and filter the resources, and typically omit important content on the basis that the entire resource will be retrieved when the user selects a clinical resource, but resource.

Servers are not obliged to return just a summary as requested. There are only a limited number of summary forms defined for every such resource returned, resources in order to allow servers to store the client will also need summarized form(s) in advance. Servers SHOULD mark the subject (patient) resource by populating meta.tag resources with the code SUBSETTED to ensure that the clinical incomplete resource refers to. is not accidentally used to overwrite a complete resource.

The client can use self link in the search result Bundle is important for the interpretation of the result and should always be returned, regardless of the type of _summary.

Note that the _include parameter to indicate that and _revinclude parameters cannot be mixed with _summary=text .

Implementation Note: There is some question about the subject resources inclusion of extensions in the summary. Additional rules may be included made around this in the results. An alternative scenario is where future.

3.2.1.7.6 Elements (_elements)

If one of the summary views defined above is not appropriate, a client wishes can request a specific set of elements be returned as part of a resource in the search results using the _elements parameter: Show as: HTTP GET | HTTP POST GET [base]/Patient?_elements=identifier,active,link POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded _elements=identifier,active,link

The _elements parameter consists of a comma-separated list of base element names such as, elements defined at the root level in the resource. Each element name SHALL be the base element name without specifying [x] or one of the types (e.g., "value" is valid, while "value[x]" and "valueQuantity" are not) TU . Only elements that are listed are to fetch be returned. Clients SHOULD list all mandatory and modifier elements in a particular resource, resource as part of the list of elements. Servers have the right to return more data than request, however clients can generally expect that returned elements will be:

• elements explicity requested,
• mandatory elements, or
• modifier elements that have values.

Servers are not obliged to return just the requested elements. Servers SHOULD always return mandatory and any modifier elements whether they are requested or not. Servers SHOULD mark the resources that refer with the tag SUBSETTED to it. For example, ensure that the incomplete resource is not actually used to overwrite a complete resource.

If a client supplies _elements values prefixed with resource types, such as _elements=Patient.gender , then servers SHOULD apply these element-level restrictions to all resources in the returned bundle, rather than just to direct search matches (i.e., restrictions should be applied to bundle entries with any search.mode).

3.2.1.7.7 Relevance (_score)

Where a search specifies a non-deterministic sort, the search algorithm may wish generate a ranking score to fetch indicate which resources meet the specified criteria better than others. The server can return this score in entry.score : Show as: FHIR+JSON | FHIR+XML "entry": { "score": 0.45, "resource": { "resourceType": "Patient", ... patient data ... } } <entry> <score value=".45"/> <resource> <Patient> ... patient data ... </Patient> </resource> </entry>

The score is a MedicationRequest, decimal number with a value between (and including) 0 and any provenance 1, where 1 is best match, and 0 is least match.

3.2.1.7.8 Including Referenced Resources

Along with resources matching search criteria, clients may request that refer related resources are included with results (i.e., to reduce the prescription. overall network delay of repeated retrievals). For example, when searching for clinical resources (e.g., Condition , Observation , etc.), the client will also generally need the subject ( Patient ) resource that the clinical resource refers to. This section describes several mechanisms for requesting additional data within FHIR search.

Note that implementers should also consider whether using GraphQL is known as a reverse include, an appropriate approach, but outside the scope of FHIR Search and thus not described here.

3.2.1.7.8.1 Inline Requests ( _include and is specified by providing a _revinclude parameter. )

Both The most common method for requesting additional resources is inline, via the search result parameters _include and _revinclude . The parameters are based on similar to chaining search parameters, rather than paths in the resource, since joins, such as chaining , are already done by that they follow links between resources based on search parameter. parameters.

Each The parameter _include parameter specifies a search parameter is used to join on: follow links 'forward'. For example, to include relevant Patient resources for requested Encounter matches, based on the Encounter.subject element, using either the subject or patient search parameters.

The first search requests all matching MedicationRequests, parameter _revinclude is used to follow reverse links. For example, to include any patient that relevant Observation resources for requested Patient matches, based on the medication prescriptions in Observation.subject element, using either the result set refer to. The second subject or patient search requests all matching prescriptions, return all the provenance resources that refer to them. parameters.

Parameter values for both Both _include and _revinclude have share the same syntax - up to three parts, components, separated by a colon characters ( : character: ). The details of the syntax are:

• The [_include|_revinclude]=* : the wildcard literal * (asterisk) is requesting all resources and references supported by the server (will typically only be supported references that are indexed). TU
• [_include|_revinclude]=[resource]:* : where [resource] is the name of the source resource from which the join comes and the wildcard literal * (asterisk) is requesting all supported reference type search parameters for that resource. Note that the list of search parameters supported for _include or _revinclude is not the same as the list of supported search parameters.
• The [_include|_revinclude]=[resource]:[parameter] : where [resource] is the name of the source resource from which the join comes and [parameter] is the name of a search parameter which must be of type reference .
• (Optional) A specific [_include|_revinclude]=[resource]:[parameter]:[targetType] : where [resource] is the name of type the source resource from which the join comes, [parameter] is the name of target a search parameter which must be of type reference , and [targetType] is a specific resource type (for when the a search parameter refers to references of multiple possible target types) types).

Note that implementers intending to support wildcard ( * ) segments SHOULD advertise them along with other resources and search parameters in their capability statement (e.g., in CapabilityStatement.rest.resource.searchInclude ).

_include and _revinclude parameters do not include multiple values. Instead, the parameters are repeated for each different include criteria.

Each _include parameter specifies a search parameter to join on: Show as: HTTP GET | HTTP POST GET [base]/MedicationRequest?_include=MedicationRequest:requester POST [base]/MedicationRequest/_search Content-Type: application/x-www-form-urlencoded _include=MedicationRequest:requester GET [base]/MedicationRequest?_revinclude=Provenance:target POST [base]/MedicationRequest/_search Content-Type: application/x-www-form-urlencoded _revinclude=Provenance:target

The first search requests all matching MedicationRequests, and asks the server to follow the references to any "requester" for each medication returned and include them in the returned result set. The second search requests all prescriptions, and that any Provenance resources referring to those prescriptions be included in the result set.

For each returned resource, the server identifies the resources that meet the criteria expressed in the join, and adds to the results, with the entry.search.mode set to "include" (in some searches, it is not obvious which resources are matches, and which are includes). If there is no reference, or no matching resource, the resource cannot be retrieved (e.g. on a different server), then the resource is omitted, and no error is returned.

The inclusion process can be iterative, if (and Servers SHOULD resolve _include and _revinclude requests for version-specific references by resolving the version named in the reference.

_include and _revinclude are, by default, invoked only if) on the modifier :iterate initial results of the search set, not on any 'included' resources. To repeatedly perform the _include is included. and _revinclude instructions on included resources, use the iterate modifier.

For example, this search returns all Medication Request MedicationRequest resources and their prescribing Practitioner Resources for the matching Medication Dispense MedicationDispense resources: Show as: HTTP GET | HTTP POST GET [base]/MedicationDispense?_include=Medication:prescription &_include:iterate=MedicationRequest:requester&criteria... POST [base]/MedicationDispense/_search Content-Type: application/x-www-form-urlencoded _include=MedicationDispense:prescription&_include:iterate=MedicationRequest:requester&criteria...

Details about the iterate modifier can be found in the section Modifier: iterate .

This technique applies to circular relationships as well. For example, the first of these two searches includes any related observations to the target relationships, but only those directly related. The second search asks for the _include based on related parameter to be executed iteratively, so it will retrieve observations that are directly related, and also any related observations to any other included observation. Show as: HTTP GET | HTTP POST GET [base]/Observation?_include=Observation:has-member&criteria... POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded _include=Observation:has-member&criteria... GET [base]/Observation?_include:iterate=Observation:has-member&criteria... POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded _include:iterate=Observation:has-member&criteria...

Both _include and _revinclude use the wild card "*" for the search parameter name, indicating that any search parameter of type=reference be included. Though both clients and servers need to take care not to request or return too many resources when doing this. Most notably, using iterative wildcards inclusions might lead to the retrieval of the full patient's record, or even more than that: resources are organized into an interlinked network and broad _include paths may eventually traverse all possible paths on the server. For servers, these iterative and wildcard _include s are demanding and may slow the search response time significantly.

It is at the server's discretion how deep to iteratively evaluate the inclusions. Servers are expected to limit the number of iterations done to an appropriate level and are not obliged to honor requests to include additional resources in the search results. Because iterative search is generally resource intensive, it is not the default behavior.

When search results are paged, each page of search results should include the matching includes for the resources in each page, so that each page stands alone as a coherent package.

3.2.1.7.8.2 External References

Note: when considering using If the _include and _revinclude, implementers should path selects a reference that refers to a resource on another server, the server can elect to include that resource in the search results for the convenience of the client.

If the _include path selects a reference that refers to an entity that is not a Resource, such as an image attachment, the server may also consider whether using GraphQL elect to include this in the returned results as a Binary and/or GraphDefinition resource. For example, the include path may point to an attachment which is by reference, like this: Show as: FHIR+JSON | FHIR+XML "content": { "contentType": "image/jpeg", "url": "http://example.org/images/2343434/234234.jpg" } <content> <contentType>image/jpeg</contentType> <url>http://example.org/images/2343434/234234.jpg</url> </content>

The server can retrieve the target of this reference, and add it to the results for the convenience of the client.

3.2.1.7.8.3 Graph Definitions (_graph) TU

While inline requests for additional resources are flexible, there are times when a more appropriate approaches in their context. structured approach is desired (e.g., optimizing frequent requests, etc.). To facilitate a structured approach, the _graph result parameter is defined.

The _graph result parameter functions as a reference type search parameter. The input is a reference to a GraphDefinition resource, which is used to define the graph of desired resources for inclusion.

3.1.1.5.5 3.2.1.7.8.4 Contained Resources (_contained)

By default, search results only include resources that are not contained in other resources. A However, chained condition parameters will be evaluated inside contained resources. To illustrate this, consider a MedicationRequest resource (id: MedicationRequest/23 ) that has a contained Medication resource specifying a custom formulation that has ingredient with a an itemCodeableConcept "abc" in "http://acme.com./medications". "http://example.org/medications" (id: Medication/m1 ).

In this case, a the search: Show as: HTTP GET | HTTP POST GET [base]/MedicationRequest?medication.ingredient-code=abc POST [base]/MedicationRequest/_search Content-Type: application/x-www-form-urlencoded medication.ingredient-code=abc

will include MedicationRequest/23 in the MedicationRequest results as a match. The search chained into the contained resource in and met the results. However, this search: search criteria.

However, the search: Show as: HTTP GET | HTTP POST GET [base]/Medication?ingredient-code=abc POST [base]/Medication/_search Content-Type: application/x-www-form-urlencoded ingredient-code=abc will not include find Medication/m1 - the medication is a contained Medication resource in the results, since within a MedicationRequest and not subject to search. This is because either the wrong type of resource would be returned, returned (the MedicationRequest containing the Medication), or the contained resource would be returned without its container resource, resource (just the Medication), which provides would be missing the required context to provided by the contained container resource.