Release 5
ExchangeThis page is part of the FHIR Specification (v5.0.0: R5 - STU). This is the current published version in it's permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions 
. Page versions: R5 R4B R4 R3 R2
| 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.
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 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 _format
parameter works for search like for other interactions. More information
about returned contents and elements can be found in
Managing Returned Resources
There are safety issues associated with the implementation of searching that implementers should always keep in mind. Implementers SHOULD review the safety checklist.
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 on the Search section of the HTTP page.
Input to search operations are referred to as Search Parameters. A search parameter can be:
_id, which is
present on every resource),Patient.birthDate, which applies to the Patient resource,)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 define additional parameters with different meanings with names that only differ in case.
Order of operations is not driven by order in the URL - with the exception of sort. First all filters are applied,
then the result set is sorted, then paging is applied, and then included resources (_include,
_revinclude) are added for each page.
The server determines which of their resources meet the criteria contained in the search parameters as described below. However, the server has the prerogative to return additional search results if it believes them to be relevant. Note: There is a special search for the most relevant context in which the search set is indeterminate: Patient MPI Search.
In the absence of any search filters, e.g. GET [base], GET [base]/Patient, or
POST [base]/_search or POST [base]/Patient/_search with no body, a server SHOULD
return all records in scope of the search context. Servers MAY reject a search as overly-broad, and SHOULD
return an appropriate error in that situation (e.g., too-costly).
For more information about how search inputs are tested against resources, please see Search Parameters.
Search operations are executed in one of three defined contexts that control which set of resources are being searched:
_type parameter is included, all other search parameters SHALL be
common to all provided 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)
* (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)
Search responses are always returned as a Bundle. Search result bundles convey a lot of metadata in addition to any possible results, using the various elements available in the bundle resource.
The response to any search operation is always a list of resources in a Bundle. An alternative approach is to use GraphQL.
Search result bundles will always have the Bundle.type of searchset.
This element and value designate that the bundle is a search response and MAY be used in processing to indicate
In order to allow the client to be confident about what search parameters were used as criteria by a server, servers SHALL return the parameters that were actually used to process a search. Applications processing search results SHALL check these returned values where necessary. For example, if 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 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 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 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 the same style as a server that does not support 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.
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.
In addition to the self link, many bundles MAY contain links relevant to paging. These are identified
via the relation 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 in the URLs TU.
Within the results bundle, there are three types of entries
that MAY be present, identified by the search mode
of the entry: match, include, or outcome.
Note that entries are unique (not allowed to 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.
Entries marked with match in search results indicate that a record is being returned because
it meets the parameters specified in the search request (e.g., a record the client requested).
Entries marked with include in search results indicate that a 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.
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 an outcome record
to report to a client that a search was unacceptable TU.
If a server is unable to execute a search request, it MAY either return an 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 that an empty search result is not an error.
In some cases, parameters may cause an error, or might not be able to match anything. For instance:
Show as: HTTP GET | HTTP POST| Issue | Search |
| A parameter may refer to a non-existent resource, such as if no Observation with an id of "101" exists | GET [base]/Observation?_id=101 POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded _id=101 |
| A parameter may reference a non-existent resource, such as if no Patient with MRN "1234" exists | GET [base]/Observation?patient.identifier=http://example.com/fhir/mrn|1234 POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded patient.identifier=http://example.com/fhir/mrn|1234 |
| A parameter may refer to an unknown code, such as if LOINC code "1234-1" is not known to the server | GET [base]/Observation?code=loinc|1234-1 POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded code=loinc|1234-1 |
| A parameter may refer to a time that is out of scope, such as if the system only has data going back to 2001 | GET [base]/Condition?onset=le1995 POST [base]/Condition/_search Content-Type: application/x-www-form-urlencoded onset=le1995 |
| A parameter may use an illegal or unacceptable modifier, such as if the modifier cannot be processed by the server | GET [base]/Condition?onset:text=1995 POST [base]/Condition/_search Content-Type: application/x-www-form-urlencoded onset:text=1995 |
| A data time parameter may have incorrect format, such as if the modifier cannot be processed by the server | GET [base]/Condition?onset=23%20May%202009 POST [base]/Condition/_search Content-Type: application/x-www-form-urlencoded onset=23%20May%202009 |
| A parameter may be unknown or unsupported (more details below) | GET [base]/Condition?myInvalidParameter=true POST [base]/Condition/_search Content-Type: application/x-www-form-urlencoded myInvalidParameter=true |
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:
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 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:
Clients can specify how the server should behave, by using the prefer header:
Prefer: handling=strict: Client requests that the server return an error for any unknown or unsupported parameterPrefer: handling=lenient: Client requests that the server ignore any unknown or unsupported parameterServers SHOULD honor the client's request, but are not required to do so. For more information, see HTTP Headers on the HTTP Page.
This specification defines FHIR Search operations in both HTTP POST and GET.
For details about the HTTP methods regarding search, please see the
Search section of the HTTP page.
Some servers expose a FHIR endpoint that actually represents multiple data stores. For example, a system might expose a single Observation endpoint, even though internally there are distinct systems for labs, vitals, clinical assessments, and symptoms. Alternatively, a system might expose a single Patient endpoint even though it is backed by multiple distinct Patient repositories.
In these "single endpoint/multiple back-end" scenarios, it is possible that the internal repositories have different capabilities when it comes to search.
At present, there is no standard way to declare such limitations as part of the CapabilityStatement, other than through custom extensions. A future release of FHIR could provide a more standard way of performing such declarations.
In any event, systems can handle such limitations in at least four ways:
category parameter be present
(and only have one value) or Patient searches might require that the organization
parameter be present. These permitted combinations can be conveyed by extensions on the
CapabilityStatement. Clients that fail to satisfy the 'combination' rules
will not be able to search successfully.
Servers MAY support batching multiple requests TU. In the context of search,
this allows several searches to be performed serially via a single request. Note that each operation of a batch is independent,
so it is not possible to use the results of one request as input to another in the same batch.
When submitting multiple requests via a batch or transaction, the returned bundle is for the batch or transaction as an operation. Therefore, two search requests in a batch would return a bundle that contains at least two entries, each of which is the result of a search request (e.g., the batch result bundle will contain entries that are the search result bundles).
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 typically accept GET-based
searches TU. There is no standard way to convey POST-based searches within a Bundle and the 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 (i.e. restrictions not imposed on POST-based searches) that they would impose if the GET-based search had been received outside a Bundle TU.
Servers MAY support FHIR Messaging. The mapping of seach requests into messages is described in more detail in the section Invoking Search via Messages.
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 data types 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:
| number | Search parameter SHALL be a number (a whole number, or a decimal). |
| date | Search parameter is on a date/time. The date format is the standard XML format, though other formats may be supported. |
| string | Search parameter is a simple string, like a name part. Search is case-insensitive and accent-insensitive. May match just the start of a string. String parameters may contain spaces. |
| token | Search parameter on a coded element or identifier. May be used to search through the text, display, code and code/codesystem (for codes) and label, system and key (for identifier). Its value is either a string or a pair of namespace and value, separated by a "|", depending on the modifier used. |
| reference | A reference to another resource (Reference or canonical). |
| composite | A composite search parameter that combines a search on two values together. |
| quantity | A search parameter that searches on a quantity. |
| uri | A search parameter that searches on a URI (RFC 3986). |
| special | Special logic applies to this parameter per the description of the search parameter. |
Individual search parameters MAY also allow "modifiers" that control their behavior. The kinds of modifiers available depend on the type of the search parameter. More details can be found in the Modifiers section of the search page.
Some search parameter types allow "prefixes" (or "comparators") which can be used to request different match-testing functionality (e.g., greater-than instead of equality). The kinds of comparators allowed depends on the type of the search parameter. More details can be found in the Prefixes section of the search page.
Generally, an single search test can be broken down into a few parts:
For example, a search against the Patient resource for given=value is a request to a server to compare values
in the given name of a patient against "value", using the default string test (see string for details).
Each of these 'parts' of a search test have a lot of flexibility.
Search input values are parsed according to the search parameter type, as defined in the relevant
SearchParameter resource. The rules for parsing a search input value into the equivalent
FHIR type can be found on the search page (e.g., converting a token input into a
Coding).
The type of test used to compare values are controlled by the search parameter type and a search modifier OR a search prefix,
if present. For example, the number search parameter type describes the default search test as an
equality test (i.e., {element value} equals {input value}). A Search Modifier,
such as not changes the test - in this case negating the default
behavior (i.e., not({element value} equals {input value})). Finally, a
Search Prefix, allowed on the number search type, can be used to change
the test to something like a 'greater than' (i.e., {element value} is greater than {input value}). Note
that a single test cannot contain both a modifier and a prefix.
Many elements in FHIR are defined as arrays (or collections) of values (e.g., a patient can have more than one
name or address). When performing a search test against elements that have a cardinality of more than one, the test
is considered a 'contains' type test against the collection of values. For example, if a patient has two name
elements with values, a test is considered a match if at least one of the values is a match.
When a 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 values in sub-elements with an appropriate type, as selected by the implementation. A search parameter MAY instead explicitly choose elements by using an expression that instead points directly to the sub-elements TU.
Search combination logic is defined by an equivalent set logic on the results of individual tests, performed
at the resource level. "OR" joined parameters are "unions of sets" and "AND" joined parameters are "intersections of sets".
Note that the joins are considered at the resource level and search parameters are unordered. This means that complex
combinations of "AND" and "OR" are not possible using the basic search syntax. Uses requiring advanced combination logic
should consider the use of the _filter parameter or
Named Queries.
When multiple search parameters passed to a single search, they 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".
It is also possible to use an "AND" join repeated on the same element. When doing so, the join behavior
is the same as when using different elements. For example, a search that asks for having two specific
given names:
Show as: HTTP GET | HTTP POST
GET [base]/Patient?given=valueGivenA&given=valueGivenB
POST [base]/Patient/_search
Content-Type: application/x-www-form-urlencoded
given=valueGivenA&given=valueGivenB
will return records that have BOTH a match for the given name of "valueGivenA" AND a match for the given
name of "valueGivenB". Note that this will match both patient records that have a single name
containing multiple given elements as well as records that have a multiple name
elements that, in total, contain the values:
Show as: FHIR+JSON | FHIR+XML
"Patient": {
"name": [{
"given": [ "valueA", "valueB" ]
}]
}
"Patient": {
"name": [{
"given": [ "valueA" ]
}, {
"given": [ "valueB" ]
}]
}
<Patient>
<name>
<given value="valueA"/>
<given value="valueB"/>
</name>
</Patient>
<Patient>
<name>
<given value="valueA"/>
</name>
<name>
<given value="valueB"/>
</name>
</Patient>
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).
Each value of an "OR" query MAY contain a prefix if allowed by the search type. For example,
a search for a heart rate value (LOINC 8867-4 ) outside of the
'normal resting range of adults':
Show as: HTTP GET | HTTP POST
GET [base]/Observation?code=http://loinc.org|8867-4&value-quantity=lt60,gt100
POST [base]/Observation/_search
Content-Type: application/x-www-form-urlencoded
code=http://loinc.org|8867-4&value-quantity=lt60,gt100
will match against Observations that have the LOINC code for a Heart Rate and have a value that is EITHER
less than 60 OR greater than 100.
If a modifier is used on a search parameter, it applies to each value of an "OR" query. For example, searching for either of two exact given names: Show as: HTTP GET | HTTP POST GET [base]/Patient?given:exact=GivenA,GivenB POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded given:exact=GivenA,GivenB will match against Patients that contain a given name of exactly "GivenA", Patients that contain a given name of exactly "GivenB", and Patients that contain both values.
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 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.
The following table contains examples of how joins work depending on their element types TU. Note that this table is illustrative and not comprehensive. Additionally, the joins listed below can be combined in a single request to form more complicated logic. For brevity, this table demonstrates the joins only against the same element type, though this is not a requirement. For example, it is common to join one parameter against a simple scalar element with another that is an array of complex elements. In this table, the following definitions are used:
Scalar refers to elements that have a maximum cardinality of one.Array refers to elements that have a maximum cardinality greater than one.Simple refers to elements that do not contain additional elements (e.g., Primitive Types).Complex refers to elements that contain additional elements (e.g., HumanName, etc.)| Context | Short | Example |
AND, Scalar, Simple |
Intersection of records that match each of the search criteria | GET [base]/Patient?death-date=ge2022-01-01&death-date=lt2023-01-01 POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded death-date=ge2022-01-01&death-date=lt2023-01-01 |
The search is asking for patients with a death-date on or after January 1, 2022 and a death-date
before January 1, 2023. The results are the intersection of patients with a deceasedDateTime on or
after January 1, 2022 and patients with a deceasedDateTime before January 1, 2023. Each match
will contain a single value in the requested range.
|
||
OR, Scalar, Simple |
Union of records that match each of the search criteria | GET [base]/Patient?death-date=ge2030-01-01,lt1980-01-01 POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded death-date=ge2030-01-01,lt1900-01-01 |
The search is asking for patients with a death-date on or after January 1, 2030 or a death-date
before January 1, 1900. The results are the union of patients with a deceasedDateTime on or
after January 1, 2030 and patients with a deceasedDateTime before January 1, 1900. Each match
will contain a single value in the requested range (e.g., checking for dates outside the allowed range).
|
||
AND, Array, Simple |
Intersection of records that contain at least one match for each search criteria | GET [base]/AllergyIntolerance?category=medication&category=biologic POST [base]/AllergyIntolerance/_search Content-Type: application/x-www-form-urlencoded category=medication&category=biologic |
The search is asking for allergies or intolerances with a category of medication and a category
of biologic. The results are the intersection of AllergyIntolerance records records with each of the requested
category values. Each matching record will contain at least one of each of the requested category values.
|
||
OR, Array, Simple |
Union of records that contain at least one match for each search criteria | GET [base]/AllergyIntolerance?category=medication,biologic POST [base]/AllergyIntolerance/_search Content-Type: application/x-www-form-urlencoded category=medication,biologic |
The search is asking for allergies or intolerances with a category of either medication or
biologic. The results are the union of AllergyIntolerance records records with any of the requested
category values. Each matching record will contain at least one of either of the requested category values,
and can contain both.
|
||
AND, Array, Complex |
Intersection of records that contain at least one match for each search criteria | GET [base]/Patient?name=valueA&name=valueB POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded name=valueA&name=valueB |
The search is asking for patients with a name of 'valueA' a name of 'valueB'.
The results are the intersection of patients that have each of the requested values in any component of
their name. Each match will contain each of the requested values in some form. E.g., a patient with
the given names of both 'valueA' and 'valueB' will match, as well as a patient with a given name of
'valueA' and a family name of 'valueB', etc..
|
||
OR, Array, Complex |
Union of records that contain at least one match for any search criteria | GET [base]/Patient?name=valueA,valueB POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded name=valueA,valueB |
The search is asking for patients with a name of either 'valueA' or 'valueB'. The results are
the union of patients with 'valueA' anywhere in their name and patients with 'valueB' anywhere in their name.
Each matching record will contain at least one of the search criteria.
|
||
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 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 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 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 search parameter,
but not the :exact modifier on the name, it would reject a 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 example, the ":exact" modifier has meaning when applied to string-type search parameters 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:
above |
reference, token, uri | Tests whether the value in a resource is or subsumes the supplied parameter value (is-a, or hierarchical relationships). |
below |
reference, token, uri | Tests whether the value in a resource is or is subsumed by the supplied parameter value (is-a, or hierarchical relationships). |
code-text TU |
reference, token |
Tests whether the textual display value in a resource (e.g., CodeableConcept.text, Coding.display,
or Reference.display) matches the supplied parameter value.
|
contains |
string, uri | Tests whether the value in a resource includes the supplied parameter value anywhere within the field being searched. |
exact |
string | Tests whether the value in a resource exactly matches the supplied parameter value (the whole string, including casing and accents). |
identifier |
reference |
Tests whether the Reference.identifier in a resource (rather than the Reference.reference) matches
the supplied parameter value.
|
in |
token | Tests whether the value in a resource is a member of the supplied parameter ValueSet. |
iterate |
n/a (not allowed anywhere by default) | The search parameter indicates an inclusion directive (_include, _revinclude) that is applied to an included resource instead of the matching resource. |
missing |
date, number, quantity, reference, string, token, uri |
Tests whether the value in a resource is present (when the supplied parameter value is true) or
absent (when the supplied parameter value is false).
|
not |
token | Tests whether the value in a resource does not match the specified parameter value. Note that this includes resources that have no value for the parameter. |
not-in |
reference TU , token | Tests whether the value in a resource is not a member of the supplied parameter ValueSet. |
of-type |
token (only Identifier) |
Tests whether the Identifier value in a resource matches the supplied parameter value.
|
text |
reference TU , token |
Tests whether the textual value in a resource (e.g., CodeableConcept.text, Coding.display,
Identifier.type.text, or Reference.display) matches the supplied parameter value using
basic string matching (begins with or is, case-insensitive).
|
text |
string | The search parameter value should be processed as input to a search with advanced text handling. |
text-advanced TU |
reference, token |
Tests whether the value in a resource matches the supplied parameter value using advanced text handling that searches
text associated with the code/value - e.g.,
CodeableConcept.text, Coding.display, or Identifier.type.text.
|
[type] |
reference |
Tests whether the value in a resource points to a resource of the supplied parameter type.
Note: a concrete ResourceType is specified as the modifier (e.g., not the literal :[type],
but a value such as :Patient).
|
Note that modifiers are allowed in searches that combine multiple terms. When using a modifier in "or" joined search parameter values,
the modifier applies to ALL values present. For example, in given:exact=valueA,valueB, the exact
modifier is used for both "valueA" and "valueB". Additional details can be found in the
Searching Multiple Values section of the Search page.
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:
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 children 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 where those references establish a hierarchy. For example, the Location resource can define a
hierarchy using the partOf element to track locations that are inside each other (e.g., Location/A101, a room, is
partOf Location/A, a floor). Meanwhile, the Patient resource could refer to other patient
resources via the link element, but no hierarchical meaning is intended. Further discussion about the requirements and uses for this
type of search can be found in the section Searching Hierarchies.
When using the above modifier on a reference, all typically-valid search parameter reference inputs are allowed.
Note that the actual Resources that establish hierarchical references and the search parameters used are listed in the
Circular Resource References section of the References page.
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 IDA100, 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'
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.
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:
3738000 - Viral hepatitis (this code)235862008 - Hepatitis due to infection (parent of 'Viral hepatitis')128241005 - Inflammatory disease of liver (parent of 'Hepatitis due to infection')312130009 - Viral infection by site (parent of 'Viral hepatitis')301810000 - Infection by site (parent of 'Viral infection by site')
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 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 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 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 matchhttp://acme.org/fhir/ValueSet/123/_history - parent of requested URIhttp://acme.org/fhir/ValueSet/123 - ancestor of requested URIhttp://acme.org/fhir/ValueSet - ancestor of requested URIhttp://acme.org/fhir - ancestor of requested URIhttp://acme.org/ - ancestor of requested URI
The below modifier allows clients to search hierarchies of data based on relationships. The below 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:
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 children of those matches. The below
modifier is only valid for circular references - that is, references that point to another instance of the
same type of resource where those references establish a hierarchy. For example, the Location resource can define a
hierarchy using the partOf element to track locations that are inside each other (e.g., Location/A101, a room, is
partOf Location/A, a floor). Meanwhile, the Patient resource could refer to other patient
resources via the link element, but no hierarchical meaning is intended. 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.
Note that the actual Resources that establish hierarchical references and the search parameters used are listed in the
Circular Resource References section of the References page.
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 IDA100, Location/A100, https://example.org/Location/A100 - child of BuildingA, representing the first floorA101, Location/A101, https://example.org/Location/A101 - child of A100, room 101A1.., etc. - child of A100, rooms on the first floorA200, Location/A200, https://example.org/Location/A200 - child of BuildingA, representing the second floor
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 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 below
modifier comparison is performed as a 'less than' against the 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 used as the separator between
the URL and version components of the parameter.
More information can be found in the section References and Versions.
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:
235862008 - Hepatitis due to infection (this code)773113008 - Acute infectious hepatitis (child)95897009 - Amebic hepatitis (child)Note that there is no limit inherent to the 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.
When the below 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 below, the modifier only applies to URIs that are URLs and 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 matchhttp://acme.org/fhir/ValueSet - child of requested URIhttp://acme.org/fhir/ValueSet/123 - descendant of requested URIhttp://acme.org/fhir/ValueSet/123/_history - descendant of requested URIhttp://acme.org/fhir/ValueSet/123/_history/1 - descendant of requested URI
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
grapheme clusters is within the discretion of
the server, i.e. the server decides if a 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.
code-text is only allowed on reference and 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)
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 target string. 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.
contains is allowed on string and uri type search
parameters. When using the '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)
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 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 - requested string (case-sensitive)
The identifier modifier allows clients to indicate that a supplied token should be used to
match against the identifier element of a 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 '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.
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 token search parameter, the input 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. 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 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.:
235862008 - Hepatitis due to infection (this code)773113008 - Acute infectious hepatitis (is-a 235862008)95897009 - Amebic hepatitis (is-a 235862008)
The iterate modifier is used to indicate that an inclusion directive
should be applied to an included resource instead of the 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 are Patient resources linked via Observation.subject. Additionally, the
server would iterate through the included patient records and follow the Patient.link
references, including linked Patient or RelatedPerson resources.
More information can be found in the section Including other resources
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 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 the element is present with extensions, but no value is specified.
For example, the 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 value for given,
even if a patient contains a Patient.name that has a given with an extension and 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 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 that contains a value for given.
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 type token. When using the 'not' modifier,
all typically-valid search parameter token inputs are allowed.
Searching for [parameter]:not=[value] requests all resources that do not have any matching value in the 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'Patient.gender value (even if a record has extensions, such as a Data Absent Reason)
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 does not return
"any document that has a section that is 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.
Note that the not modifier can behave in undesirable ways with "or"-joined parameter values. Specifically,
consider a query that uses a scalar (max cardinality one) value, such as: gender:not=male,female. Using the 'default'
rules, the query is expanded to be the union of the sets of: patients that do not have a gender element value or that contain any
value other than "male", and patients that do not have a gender element value or that contain any value other than "female" - the
union of those sets will always contain all records.
Implementer feedback is requested on this behavior and if additional rules concerning the not modifier would be appropriate.
In the meantime, use of the not modifier with "or"-joined search terms is not recommended. Implementers are instead
recommended to use either the _filter parameter or Named Queries.
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 search parameter
tests whether the coding is not 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.:
235862008 - Hepatitis due to infection (this code)773113008 - Acute infectious hepatitis (is-a 235862008)95897009 - Amebic hepatitis (is-a 235862008)
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 the 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 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.
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:
25064002 - Headache finding398987004 - Headache following lumbar puncture230480006 - Headache following myelography (disorder)R51 - HeadacheR51.0 - Headache with orthostatic component, not elsewhere classifiedR51.9 - Headache, unspecified
Note that the search is not expected to return results with codes such as SNOMED 735938006, since
the 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
identifier element, see Searching Identifiers.
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.
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..
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 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:
25064002 - Headache finding398987004 - Headache following lumbar puncture230480006 - Headache following myelography (disorder)R51 - HeadacheR51.0 - Headache with orthostatic component, not elsewhere classifiedR51.9 - Headache, unspecifiedHowever, it would also match Condition resources containing codes with text containing the word 'headache' such as:
735938006 - Acute headache95660002 - Thunderclap headache4969004 - Sinus headacheG44.019 - Episodic cluster headache, not intractableG44.81 - Hypnic headacheAdditionally, a server MAY also return Condition resources with codes containing synonymous text such as conditions with the codes:
37796009 - Migraine49605003 - Ophthalmoplegic migraine (disorder)G43.4 - Hemiplegic migraineG43.B0 - Ophthalmoplegic migraine, not intractable
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 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.
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 prefixes described in the table below are used. Note that in the following table:
parameter value refers to the value provided to search against (e.g., the parameter value in the request)resource value refers to the value being tested against in a resource (e.g., an element value in a data store)| Prefix Code | Description | Formal Definition |
eq |
the resource value is equal to or fully contained by the parameter value | the range of the parameter value fully contains the range of the resource value |
ne |
the resource value is not equal to the parameter value | the range of the parameter value does not fully contain the range of the resource value |
gt |
the resource value is greater than the parameter value | the range above the parameter value intersects (i.e. overlaps) with the range of the resource value |
lt |
the resource value is less than the parameter value | the range below the parameter value intersects (i.e. overlaps) with the range of the resource value |
ge |
the resource value is greater or equal to the parameter value | the range above the parameter value intersects (i.e. overlaps) with the range of the resource value, or the range of the parameter value fully contains the range of the resource value |
le |
the resource value is less or equal to the parameter value | the range below the parameter value intersects (i.e. overlaps) with the range of the resource value or the range of the parameter value fully contains the range of the resource value |
sa |
the resource value starts after the parameter value | the range of the parameter value does not overlap with the range of the resource value, and the range above the parameter value contains the range of the resource value |
eb |
the resource value ends before the parameter value | the range of the parameter value does not overlap with the range of the resource value, and the range below the parameter value contains the range of the resource value |
ap |
the resource value is approximately the same to the parameter value. Note that the recommended value for the approximation is 10% of the stated value (or for a date, 10% of the gap between now and the date), but systems may choose other values where appropriate |
the range of the parameter value overlaps with the range of the resource value |
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.
Prefixes are allowed in searches that combine multiple terms. When using a prefix in "or" joined search parameter values,
the prefix only applies to the value it precedes. For example, in value-quantity=lt60,gt100, the lt
prefix is applied to the value "60" and the gt prefix is applied to the value "100". Additional details can be
found in the Searching Multiple Values section of the Search page.
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 resource value is a Range, a Period, or a Timing, then the target is explicitly a range. Three ranges are identified:
| range of the value | The limits implied by the precision of the value | The number 2.0 has a range of 1.95 to 2.05 The date 2015-08-12 has a range from 2015-08-12T00:00:00.0000 inclusive to 2015-08-13T00:00:00.0000 exclusive. |
| range below the value | Up to the specified value | The range below 2.0 includes any value less or equal to <2.00000000000000000000 The range before 2015-08-12T05:23:45 includes any time up to 2015-08-12T05:23:45.000000000000000 |
| range above the value | The specified value and up | The range above 2.0 includes any value greater or equal to <2.00000000000000000000 The range after 2015-08-12T05:23:45 includes any time after 2015-08-12T05:23:45.000000000000000 |
Additional details about how ranges are applied are specific to each data type and are documented there.
In the rules described above, special rules are defined for the characters $, ,, and |.
As a consequence, if these characters appear in 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 character \, which also must be used to prepend itself.
Therefore, param=xxx$xxx indicates that it is a composite parameter, while param=xx\$xx indicates that
the parameter has the literal value xx$xx. The parameter value xx\xx is illegal,
and the parameter value param=xx\\xx indicates a literal value of xx\xx.
This means that:
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 a request for any Observation that has a code of either a 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 a request for any Observation that has a code of a,b.
This escaping is at a different level to the percent encoding that applies to all
URL parameters (as defined in RFC 3986 ).
Standard percent escaping still applies, such that these URLs have the same meaning:
Show as: HTTP GET | HTTP POST
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
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
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 escape syntax using \ applies to all parameter values after they have been 'unescaped' on the server while being read from the HTTP headers.
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.ssss[Z|(+|-)hh:mm] (the standard XML format). Note
that fractional seconds MAY be ignored by servers TU.
Technically, this is any of the date, dateTime,
and instant 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 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:
| date | The range of the value is the day, month, or year as specified |
| dateTime | The range of the value as defined above; e.g. For example, the date 2013-01-10 specifies all the time from 00:00 on 10-Jan 2013 to immediately before 00:00 on 11-Jan 2013 |
| instant | An instant is considered a fixed point in time with an interval smaller than the precision of the system, i.e. an interval with an effective width of 0 |
| Period | Explicit, though the upper or lower bound might not actually be specified in resources. |
| Timing | the specified scheduling details are ignored and only the outer limits matter. For instance, a schedule that specifies every second day between 31-Jan 2013 and 24-Mar 2013 includes 1-Feb 2013, even though that is on an odd day that is not specified by the period. This is to keep the server load processing queries reasonable. |
Implicitly, a missing lower boundary is "less than" any actual date. A missing upper boundary is "greater than" any actual date. Date searches can be controlled through the use of prefixes as described in the following table:
[parameter]=eq2013-01-14 |
|
[parameter]=ne2013-01-14 |
|
[parameter]=lt2013-01-14T10:00 |
|
[parameter]=gt2013-01-14T10:00 |
|
[parameter]=ge2013-03-14 |
|
[parameter]=le2013-03-14 |
|
[parameter]=sa2013-03-14 |
|
[parameter]=eb2013-03-14 |
|
[parameter]=ap2013-03-14 |
|
Please note in particular the differences between range comparison and boundary comparison prefixes when comparing ranges on both sides. Tests such as
'greater than' are evaluated true if any part of the value range is higher than the test range. Similarly, a test such as 'starts after' is non-inclusive
of the range of the test value, so a request such as sa2013-01-14 is requesting values that start after January 14th has passed,
not after January 14th started. In order to avoid unintentional overlapping of ranges, requests can increase the specificity of their request. For example,
the test for sa2013-01-14T00:00:00 is a much clearer test.
Other notes:
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 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 timezones. Implementation guides may make additional rules in this regard.
Future versions of this specification may impose rules around the use of 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 .
Searching on a simple numerical value in a resource. Examples:
[parameter]=100 | Values that equal 100, to 3 significant figures precision, so this is actually searching for values in the range [99.5 ... 100.5) |
[parameter]=100.00 | Values that equal 100, to 5 significant figures precision, so this is actually searching for values in the range [99.995 ... 100.005) |
[parameter]=1e2 | Values that equal 100, to 1 significant figure precision, so this is actually searching for values in the range [50 ... 150) |
[parameter]=lt100 | Values that are less than exactly 100 |
[parameter]=le100 | Values that are less or equal to exactly 100 |
[parameter]=gt100 | Values that are greater than exactly 100 |
[parameter]=ge100 | Values that are greater or equal to exactly 100 |
[parameter]=ne100 | Values that are not equal to 100 (actually, in the range 99.5 to 100.5) |
Notes about searching on Numbers:
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 precisionHere are some example searches:
Show as: HTTP GET | HTTP POST| Search | Description |
| GET [base]/RiskAssessment?probability=gt0.8 POST [base]/RiskAssessment/_search Content-Type: application/x-www-form-urlencoded probability=gt0.8 | Search for all the Risk Assessments with probability great than 0.8 (could also be probability=gt8e-1 using exponential form) |
| GET [base]/ImmunizationRecommendation?dose-number=2 POST [base]/ImmunizationRecommendation/_search Content-Type: application/x-www-form-urlencoded dose-number=2 | Search for any immunization recommendation recommending a second dose |
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:
| Search | Description |
| GET [base]/Observation?value-quantity=5.4|http://unitsofmeasure.org|mg POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded value-quantity=5.4|http://unitsofmeasure.org|mg | Search for all the observations with a value of 5.4(+/-0.05) mg where mg is understood as a UCUM unit (system/code)
|
| GET [base]/Observation?value-quantity=5.40e-3|http://unitsofmeasure.org|g POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded value-quantity=5.40e-3|http://unitsofmeasure.org|g | Search for all the observations with a value of 0.0054(+/-0.00005) g where g is understood as a UCUM unit (system/code)
|
| GET [base]/Observation?value-quantity=5.4||mg POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded value-quantity=5.4||mg | Search for all the observations with a value of 5.4(+/-0.05) mg where the unit - either the code (code) or the stated human unit (unit) are "mg"
|
| GET [base]/Observation?value-quantity=5.4 POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded value-quantity=5.4 | Search for all the observations with a value of 5.4(+/-0.05) irrespective of the unit |
| GET [base]/Observation?value-quantity=le5.4|http://unitsofmeasure.org|mg POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded value-quantity=le5.4|http://unitsofmeasure.org|mg | Search for all the observations where the value of is less than 5.4 mg exactly where mg is understood as a UCUM unit |
| GET [base]/Observation?value-quantity=ap5.4|http://unitsofmeasure.org|mg POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded value-quantity=ap5.4|http://unitsofmeasure.org|mg | Search for all the observations where the value of is about 5.4 mg where mg is understood as a UCUM unit (typically, within 10% of the value - see above) |
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
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:
[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 inputhttp://example.org/fhir/Patient/123 - search input with implicit resolution to the local serverPatient/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 inputPatient/123 - search input with implicit reference to the local serverPatient/123/_history/1, since the original reference was
not a relative reference TU.
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 Patienthttp://example.org/fhir/Patient/123 - search input with implicit resolution to the local server, of type PatientPractitioner/123 - search input of type Practitionerhttp://example.org/fhir/Practitioner/123 - search input with implicit resolution to the local server, of type Practitioner
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.
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:
Show as: HTTP GET | HTTP POST| GET [base]/Patient?given=eve POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded given=eve | Any patients with a name containing a given part with "eve" at the start of the name. This would include patients with the given name "Eve", "Evelyn". |
| GET [base]/Patient?given:contains=eve POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded given:contains=eve | Any patients with a name with a given part containing "eve" at any position. This would include patients with the given name "Eve", "Evelyn", and also "Severine". |
| GET [base]/Patient?given:exact=Eve POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded given:exact=Eve | Any patients with a name with a given part that is exactly "Eve". Note: This would not include patients with the given name "eve" or "EVE". |
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.
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 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, ContactPoints, and ids. In these
cases the URI portion ([system]|) is not 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 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 CodingNotes:
[parameter]=[code] form is allowedToken search parameters are used for the following datatypes:
| 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://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 case-insensitive full-string 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 datatype. The namespace for these codes is
http://terminology.hl7.org/CodeSystem/special-values, though there is usually no reason to use this, as a simple true or false is sufficient.
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:
Show as: HTTP GET | HTTP POST| Search | Description |
| GET [base]/Patient?identifier=http://acme.org/patient|2345 POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded identifier=http://acme.org/patient|2345 | Search for all the patients with an identifier with key = "2345" in the system "http://acme.org/patient" |
| GET [base]/Patient?gender=male POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded gender=male | Search for any patient with a gender that has the code "male" |
| GET [base]/Patient?gender:not=male POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded gender:not=male | Search for any patient with a gender that does not have the code "male", including those that do not have a code for gender at all. |
| GET [base]/Composition?section=48765-2 POST [base]/Composition/_search Content-Type: application/x-www-form-urlencoded section=48765-2 | Search for any Composition that contains an Allergies and adverse reaction section |
| GET [base]/Composition?section:not=48765-2 POST [base]/Composition/_search Content-Type: application/x-www-form-urlencoded section:not=48765-2 | Search for any Composition that does not contain an Allergies and adverse reaction section. Note that this search does not return "any document that has a section that is not an Allergies and adverse reaction section" (e.g. in the presence of multiple possible matches, the negation applies to the set, not each individual entry) |
| GET [base]/Patient?active=true POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded active=true | Search for any patients that are active |
| GET [base]/Condition?code=http://acme.org/conditions/codes|ha125 POST [base]/Condition/_search Content-Type: application/x-www-form-urlencoded code=http://acme.org/conditions/codes|ha125 | Search for any condition with a code "ha125" in the code system "http://acme.org/conditions/codes" |
| GET [base]/Condition?code=ha125 POST [base]/Condition/_search Content-Type: application/x-www-form-urlencoded code=ha125 | Search for any condition with a code "ha125". Note that there is not often any useful overlap in literal symbols between code systems, so the previous example is generally preferred |
| GET [base]/Condition?code:text=headache POST [base]/Condition/_search Content-Type: application/x-www-form-urlencoded code:text=headache | Search for any Condition with a code that has a text "headache" associated with it (either in the text, or a display) |
| GET [base]/Condition?code:in=http%3A%2F%2Fsnomed.info%2Fsct%3Ffhir_vs%3Disa%2F126851005 POST [base]/Condition/_search Content-Type: application/x-www-form-urlencoded code:in=http%3A%2F%2Fsnomed.info%2Fsct%3Ffhir_vs%3Disa%2F126851005 | Search for any condition in the SNOMED CT value set "http://snomed.info/sct?fhir_vs=isa/126851005" that includes all descendants of "Neoplasm of liver" |
| GET [base]/Condition?code:below=126851005 POST [base]/Condition/_search Content-Type: application/x-www-form-urlencoded code:below=126851005 | Search for any condition that is subsumed by the SNOMED CT Code "Neoplasm of liver". Note: This is the same outcome as the previous search |
| GET [base]/Condition?code:in=http://acme.org/fhir/ValueSet/cardiac-conditions POST [base]/Condition/_search Content-Type: application/x-www-form-urlencoded code:in=http://acme.org/fhir/ValueSet/cardiac-conditions | Search for any condition that is in the institutions list of cardiac conditions |
| GET [base]/Patient?identifier:of-type=http://terminology.hl7.org/CodeSystem/v2-0203|MR|446053 POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded identifier:of-type=http://terminology.hl7.org/CodeSystem/v2-0203|MR|446053 | Search for the Medical Record Number 446053 - this is useful where the system id for the MRN is not known |
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 can be used to indicate
that partial matching is used. For example (note that the search 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
:below search
The search type uri is used with elements of type uri and url.
The type reference is used for the types Reference and
canonical.
A few parameters have the type 'special'. That indicates that the way this parameter works is unique to the parameter and described with the parameter. The general modifiers and comparators do not apply, except as stated in the description.
Implementers will generally need to do special implementations for these parameters. These parameters are special:
section-text on Compositioncontains on Locationnear on Location
Composite search parameters are allow joining multiple elements into distinct single values with a $.
This is different from doing a simple intersection - the 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 sequence is a single value and itself can be composed into a 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 gender characteristic of "mixed" (the group contains people of
multiple genders) OR the group has a owner characteristic of "Eve".
Note that search modifiers are NOT allowed on composite parameters.
Examples of using composite parameters:
Show as: HTTP GET | HTTP POST| Search | Description |
| GET [base]/DiagnosticReport?result.code-value-quantity=http://loinc.org|2823-3$gt5.4|http://unitsofmeasure.org|mmol/L POST [base]/DiagnosticReport/_search Content-Type: application/x-www-form-urlencoded result.code-value-quantity=http://loinc.org|2823-3$gt5.4|http://unitsofmeasure.org|mmol/L | Search for all diagnostic reports that contain on observation with a potassium value of >5.4 mmol/L (UCUM) |
| GET [base]/Observation?component-code-value-quantity=http://loinc.org|8480-6$lt60 POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded component-code-value-quantity=http://loinc.org|8480-6$lt60 | Search for all the observations with a systolic blood pressure < 60. Note that in this case, the unit is assumed (everyone uses mmHg) |
| GET [base]/Group?characteristic-value=gender$mixed POST [base]/Group/_search Content-Type: application/x-www-form-urlencoded characteristic-value=gender$mixed | Search for all groups that have a characteristic "gender" with a text value of "mixed" |
| GET [base]/Questionnaire?context-type-value=focus$http://snomed.info/sct|408934002 POST [base]/Questionnaire/_search Content-Type: application/x-www-form-urlencoded context-type-value=focus$http://snomed.info/sct|408934002 | Search for all questionnaires that have a clinical focus = "Substance abuse prevention assessment (procedure)" |
In addition to 'basic' searching, this specification defines behaviors for many 'special' cases that are common across implementations.
In FHIR data, there are a few types of identifiers that may apply to a resource: a single
logical identifier (the Resource.id of a resource),
zero or more Identifier-type elements (e.g.,
Patient.Identifier), and, if the 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.
The Logical Identifier of a resource represents a 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 logical id of an instance is done via the _id search parameter.
Given that a logical id is unique in the context, searching by logical id will always result in either zero or one records. In many ways, the search is functionally equivalent to an equivalent simple read operation. However, there are some differences in using search instead of read:
deceased to true would only return the Patient if they are deceased.
Since _id requires a resource type context and there can only be zero or one resources of a type with a given logical id,
the 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..
Some resources (e.g., Group, List, and CareTeam) are used to maintain collections of other resources. For example, a Group of Patients representing a cohort or a List of patient allergies. While it is 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:
_in to test against active membership, and_list to test against advanced List functionality
(e.g., functional list definitions).
The Identifier datatype is typically only used on by a single element in a resource
and is typically named identifier. The element is typically cardinality 0..*, meaning that resources
may have zero, one, or more identifiers attached to them (e.g., a single patient record with MRNs for several related facilities).
Resources containing identifier elements usually expose a matching search parameter, e.g., Patient.identifier or CanonicalResource.identifier. Given the structure of the identifier type, the search parameter is a token type - see the token search type for details.
It is often useful to search via reference across resource links. For example, if you have the MRN for a patient and do not know
the logical identifier, it is desireable to perform searches like "encounters for the patient with MRN 1234". There are two ways
of searching references by identifier, depending on how data is stored in the system: via chaining or via the
identifier search modifier.
Chaining functions by resolving a resource reference 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 Encounter resources, following references in the patient search parameter ("the patient present at the encounter"),
and testing those Patient resources against the 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 only for Encounters. If a system wants to enable searches via identifiers without
chaining, the server can include additional information in the Reference Datatype
(in Reference.identifier), which is then accessible by
the identifier search modifier. Note that this approach requires
additional bookkeeping by the server - if a patient record is modified, e.g., to add an additional identifier, every
resource that reference that patient record would need to be updated.
The identifier modifier functions by testing the 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 Encounter resources, testing the Encounter.subject.identifier element against the value of 1234 in system
http://example.org/facilityA. In short, this search will return all Encounters for that have Patient references
and include the identifier "1234" from "facilityA".
Note that the difference between the two searches is a single character - the . (period) in the first example
represents a chained search and the : (colon) in the second indicates the use of a search modifier.
Canonical Resources are identified by their url and possibly a version. Similarly, references to canonical resources are made with the canonical datatype. More details about canonical references can be found in the Canonical URLs section of the references page.
When searching canonical references, the search type is reference, though with an additional syntax for version information. For more information about version resolution, see the References and Versions section of this page.
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:
_include, _revinclude),
the specified version SHOULD be provided.
/_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:
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:
The search: 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.:
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
can 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 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.
Resources that establish hierarchical references are listed in the Circular Resource References section of the References page.
Servers indicate that above/below
is supported on a search parameter by defining them as
Modifiers on the Search Parameter definition.
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.
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:
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:
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, 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.
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. _has:Observation:patient:code=123,456), and multiple _has
parameters are allowed (e.g. _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 nested, like this:
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 Patient records that have an Observation where the observation has an audit event from a specific user.
The _has parameter can also be used in chained-searches, for example:
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 search for the Encounters of patients that are members of the Group "102".
Note that reverse-chained search parameters are not intended to work with search modifiers.
While their use is not prohibited, the syntax of _has makes construction and parsing error-prone.
Searches requiring advanced matching across resources are encouraged
to use Named Queries or Advanced filtering.
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.
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 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 (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.
Normally, a search is initiated against a known type of resource, 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, for example:
[base]?params...)
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.
If no type is specified, the only search parameters that can be used in global search like this are the base parameters that apply to all resources.
If a single type is specified, all search parameters for that type are allowed.
If multiple types are specified, all search parameters that can be referenced commonly
between resources can be used (e.g., listed with the same name in the
CapabilityStatement, typically the value of
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 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 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.
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
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 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 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 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 | 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>
can be executed via:
Show as: HTTP GET | HTTP POST
Request Description
GET [base]/Patient?_query=current-high-risk
POST [base]/Patient/_search
Content-Type: application/x-www-form-urlencoded
_query=current-high-risk
Query with no additional parameters
GET [base]/Patient?_query=current-high-risk&ward=Location/A1
POST [base]/Patient/_search
Content-Type: application/x-www-form-urlencoded
_query=current-high-risk&ward=Location/A1
Query with a
ward parameter value passed to the filter
GET [base]/Patient?_query=current-high-risk&birthdate=ge1970-01-1
POST [base]/Patient/_search
Content-Type: application/x-www-form-urlencoded
_query=current-high-risk&birthdate=ge1970-01-01
Query with a no additional parameters, filter results according to a standard patient birthdate query.
Note that servers SHOULD accept query parameters that are not enumerated in named queries based on their standard
support (e.g., parameters that are supported for a given resource type), but servers MAY choose to ignore parameters
not specified by the OperationDefinition TU.
GET [base]/Patient?_query=current-high-risk&birthdate=ge1970-01-01&ward=Location/A1
POST [base]/Patient/_search
Content-Type: application/x-www-form-urlencoded
_query=current-high-risk&birthdate=ge1970-01-01&ward=Location/A1
Query with both a
ward parameter value passed to the named query and a standard patient query filter by birthdate.
Note that query parameters are unordered, so parameters to a named query MAY appear in any location or sequence TU.
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.
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:
_contained |
Request different types of handling for contained resources. |
_count |
Limit the number of match results per page of response.
|
_elements |
Request that only a specific set of elements be returned for resources. |
_graph TU |
Include additional resources according to a GraphDefinition.
|
_include |
Include additional resources, based on following links forward across references. |
_maxresults |
Limit the total number of match results a request can return.
|
_revinclude |
Include additional resources, based on following reverse links across references. |
_score |
Request match relevance in results. |
_sort |
Request which order results should be returned in. |
_summary |
Return only portions of resources, based on pre-defined levels. |
_total TU |
Request a precision of the total number of results for a request. |
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 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:
_score.Patient.name, servers might search by family name
then given, given name then family, or prefix, family, and then given. Similarly, when
sorting with multiple given names, the sort might be based on the 'earliest' name in sort order or the
first name in the instance.
reference and token
types, the search parameter MAY include the text modifier
to request sorting based on the text or display portions of the element values.
For example, _sort=code:text or _sort:-code:text.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.
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).
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
its preference with regard to the total, which can have one of the
following values:
| none | There is no need to populate the total count; the client will not use it |
| estimate | A rough estimate of the number of matching resources is sufficient |
| accurate | The client requests that the server provide an exact total of the number of matching resources |
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.
The _total parameter has the status trial-use pending real-world experience of its use.
In order to keep the load on clients, 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 ensure that any pages reachable via
links (e.g. previous/next) respect the the original requested
_count expectations (or a server-overridden max page 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.
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 _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 = 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.
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
The _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 _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.
The client can request the server to return only a portion of the resources
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
resource. It can contain one of the following values:
| true | Return a limited subset of elements from the resource. This subset SHOULD consist solely of all supported elements that are marked as "summary" in the base definition of the resource(s) (see ElementDefinition.isSummary) |
| text |
Return only the text, id, meta, and top-level mandatory elements
(these mandatory elements are included to ensure that the payload is valid FHIR; servers MAY omit elements
within these sub-trees as long as they ensure that the payload is valid). Servers MAY return extensions,
but clients SHOULD NOT rely on extensions being present and SHOULD use another search mode if data contained
in extensions is required. TU
|
| data | Remove the text element |
| count | Search only: just return a count of the matching resources, without returning the actual matches |
| false | Return all parts of the resource(s) |
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 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 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 resource.
Servers are not obliged to return just a summary as requested. There are only
a limited number of summary forms defined for resources in order to allow servers
to store the summarized form(s) in advance. Servers SHOULD mark the by populating
meta.tag resources with the code SUBSETTED
to ensure that the incomplete resource is not accidentally used to overwrite
a complete resource.
The 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 and _revinclude parameters cannot be mixed with _summary=text.
Implementation Note: There is some question about the inclusion of extensions in the summary. Additional rules may be made around this in the future.
If one of the summary views defined above is not appropriate, a client 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 be returned. Clients SHOULD list all mandatory and modifier
elements in a 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:
Servers are not obliged to return just the requested elements.
Servers SHOULD always return mandatory and modifier elements whether they are
requested or not. Servers SHOULD mark the resources with the
tag SUBSETTED
to 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).
Where a search specifies a non-deterministic sort, the search algorithm may generate a ranking score to 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 decimal number with a value between (and including) 0 and 1, where 1 is best match, and 0 is least match.
Along with resources matching search criteria, clients may request that related resources are included with results (i.e., to reduce the 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 an appropriate approach, but outside the scope of FHIR Search and thus not described here.
_include and _revinclude)
The most common method for requesting additional resources is inline, via the search result
parameters _include and _revinclude. The parameters are similar to
chaining search parameters, in that they follow links between resources
based on search parameters.
The parameter _include is used to 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 parameter _revinclude is used to follow reverse links. For example, to include
relevant Observation resources for requested Patient matches, based on the
Observation.subject element, using either the subject or
patient search parameters.
Both _include and _revinclude share the same syntax - up to three components, separated
by colon characters (:). The details of the syntax are:
[_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.
[_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.
[_include|_revinclude]=[resource]:[parameter]:[targetType]: where [resource] is the name of the source resource from which
the join comes, [parameter] is the name of a search parameter which must be of type reference, and [targetType] is
a specific resource type (for when a search parameter refers to references of multiple 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.
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 on the initial results
of the search set, not on any 'included' resources. To repeatedly perform the _include and
_revinclude instructions on included resources, use the
iterate modifier.
For example, this search returns all MedicationRequest resources and their prescribing Practitioner Resources for the matching 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 _includes 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.
If the _include 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 elect to include this in the returned
results as a Binary 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.
While inline requests for additional resources are flexible, there are times when a more
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.
By default, search results only include resources that are not contained in other resources.
However, chained 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 an
itemCodeableConcept "abc" in "http://example.org/medications" (id: Medication/m1).
In this case, 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 results as a match. The search chained into the
contained resource and met the 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 find Medication/m1 - the medication is a contained resource
within a MedicationRequest and not subject to search. This is because either the
wrong type of resource would be returned (the MedicationRequest containing the Medication),
or the contained resource would be returned without its container resource (just the Medication),
which would be missing the required context provided by the container resource.
Clients can modify the search behavior for contained resources using the _contained
parameter, which can have one of the following values:
false (default): Do not search and return contained resourcestrue: search and return only contained resourcesboth: search and return both contained and non-contained (normal) resources
When contained resources are being returned, the server
can return either the container resource, or the contained resource alone. The
client can specify which by using the _containedType parameter, which can have one of the
following values:
container (default): Return the container resourcescontained: return only the contained resource
To return just the contained Medication (Medication/m1), the following search
could be used:
Show as: HTTP GET | HTTP POST
GET [base]/Medication?ingredient-code=abc&_contained=true&_containedType=contained
POST [base]/Medication/_search
Content-Type: application/x-www-form-urlencoded
ingredient-code=abc&_contained=true&_containedType=contained
This search would return a result bundle with the contained Medication records. Note
that the fullUrl of the entry points to the containing resource first and includes the
required resolution for the contained resource:
Show as: FHIR+JSON | FHIR+XML
{
"resourceType": "Bundle",
...
"entry": [{
"fullUrl": "http://example.com/fhir/MedicationRequest/23#m1",
"resource": {
"resourceType": "Medication",
"id": "m1",
...
},
"search": {
"mode": "match"
}
}]
}
<Bundle>
...
<entry>
<fullUrl value="http://example.com/fhir/MedicationRequest/23#m1"/>
<resource>
<Medication>
<id value="m1">
...
</Medication>
</resource>
<search>
<mode value="match"/>
</search>
</entry>
</Bundle>
Similarly, the search could be performed to return the MedicationRequests containing the Medication records:
Show as: HTTP GET | HTTP POST
GET [base]/Medication?ingredient-code=abc&_contained=true&_containedType=container
POST [base]/Medication/_search
Content-Type: application/x-www-form-urlencoded
ingredient-code=abc&_contained=true&_containedType=container
This search would return a result bundle with the container MedicationRequest records and the
relevant contained resources. Note that even though the request was for Medication resources,
the container MedicationRequest entries are categorized with the mode of match:
Show as: FHIR+JSON | FHIR+XML
{
"resourceType": "Bundle",
...
"entry": [{
"resource": {
"resourceType": "MedicationRequest",
"id": "23",
...
"contained": [{
"resourceType": "Medication",
"id": "m1",
...
}],
...
},
"search": {
"mode": "match"
}
}]
}
<Bundle>
...
<entry>
<resource>
<MedicationRequest>
<id value="23">
...
<contained>
<Medication>
<id value="m1">
...
</Medication>
<contained>
</MedicationRequest>
</resource>
<search>
<mode value="match"/>
</search>
</entry>
</Bundle>
When returning paged results for a search with _include resources, all _include resources that are
related to the primary resources returned for the page SHOULD also be returned as part of that
same page, even if some of those resource instances have previously been returned on previous
pages. This approach allows both sender and receiver to avoid caching results of other pages.
Search parameters can be defined in either the core specification or externally (e.g., via Implementation Guides). The parameters defined in the core specification fall into a few categories, as listed below. Note that all search parameters defined in this specification are listed by the search parameter registry.
Note that if a 'base' SearchParameter defined by HL7 or an implementation guide
(i.e., one that does not inherit from another SearchParameter definition) is referenced and the
SearchParameter does not otherwise enumerate the modifiers and comparators, then all
modifiers and prefixes that are permitted for that parameter's
search type are expected to be supported. If an implementation wishes to restrict which
modifiers they support, the implementation must define their own SearchParameter instance, which
SHOULD inherit from the original definition TU. The definition of any locally-defined
search parameters SHALL be available to clients, either as resources at the [base]/SearchParameter
endpoint or as contained resources in the
CapabilityStatement TU.
The following parameters apply to all resources: _content, _filter, _has, _id, _in, _language, _lastUpdated, _list, _profile, _query, _security, _source, _tag, _text, _type. In addition, the search
parameters _text and _filter, (documented below) also applies to all resources (as do the search result parameters).
The standard search parameter _content is used to allow searching all textual content of
a resource.
The _content search parameter is defined as a special type parameter.
While the actual format used by the parameter is implementation-dependant, the search is some form of string
which can be used for advanced searching (similar to _text).
For example, the following search: Show as: HTTP GET | HTTP POST GET [base]/Observation?_content=cancer OR metastases OR tumor POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded _content=cancer OR metastases OR tumor is a search for Observations that contain any of the phrases "cancer", "metastases", and "tumor" anywhere in the resource. For example, the key words may appear in:
Observation.text - Text summary of the resource, for human interpretationObservation.code.text - Type of observation, Plain text representation of the conceptObservation.note - Comments about the observationThe server MAY choose to search for related terms (e.g., "carcinoma", etc.), but is not required to do so.
More information can be found in the section Text Search Parameters.
The _has parameter provides limited support for reverse chaining - that is, selecting resources
based on the properties of resources that refer to them. Details and examples can be found in the
Reverse Chaining section of the search page.
The standard search parameter _id is used to allow searching based on the logical identifier
of resources (Resource.id). The parameter requires a resource type specified in the
search context - it can only be used in searches that contain a [type]
component in the search request.
The _id search parameter is defined as a token type parameter, with the
restriction that only the code segment is allowed (e.g., no vertical pipes). This means that
the literal provided as search input is matched as a code instead of a string - e.g., exact match instead
of case-insensitive starts-with.
For example, the following search: Show as: HTTP GET | HTTP POST GET [base]/Patient?_id=23 POST [base]/Patient/_search Content-Type: application/x-www-form-urlencoded _id=23 is a search for Patient records with a logical id of "23".
For information about the difference between performing a read operation and searching by identifier, see Searching Identifiers.
The standard search parameter _in is used to match resources against active membership in collection
resources. Matching is performed against the Resource.id of the resource against the membership
test of a collection resource (e.g., CareTeam, Group, List). Details about how each resource applies the
active membership test can be found on the relevant resource pages:
The _in search parameter is defined as a reference type parameter. The
target of the reference must be one of: CareTeam, Group, or List.
For example:
Show as: HTTP GET | HTTP POST
Description Search
Any resource in a CareTeam, List, or Group with id "101"
GET [base]/?_in=101
POST [base]/_search
Content-Type: application/x-www-form-urlencoded
_in=101
Conditions in List "102"
GET [base]/Condition?_in=List/102
POST [base]/Condition/_search
Content-Type: application/x-www-form-urlencoded
_in=List/102
Patients which are participants of CareTeam "103"
GET [base]/Patient?_in=CareTeam/103
POST [base]/Patient/_search
Content-Type: application/x-www-form-urlencoded
_in=CareTeam/103
Encounters for Patients in Group "104"
GET [base]/Encounter?patient._in=Group/104
POST [base]/Encounter/_search
Content-Type: application/x-www-form-urlencoded
patient._in=Group/104
Smooth muscle relaxant medications that are not in the allergy list "105"
GET [base]/Medication?code:below=http://snomed.info/sct|90000002&ingredient._in:not=List/105
POST [base]/Medication/_search
Content-Type: application/x-www-form-urlencoded
code:below=http://snomed.info/sct|90000002&ingredient._in:not=List/105
Note that inactive/excluded members are not considered 'in' the membership. If a full reference is required, chaining can be used to search all references.
For more information about membership testing, see Searching by Membership.
The standard search parameter _language is used to match resources based on the language of
the resource used. Note that match testing is performed against the element Resource.language
and does not match against the actual language used in elements.
The _language search parameter is defined as a token type parameter.
Resource.language is restricted to
Common Languages and All Languages.
For example, the search:
Show as: HTTP GET | HTTP POST
GET [base]/Questionnaire?_language=es
POST [base]/Questionnaire/_search
Content-Type: application/x-www-form-urlencoded
_language=es
will match Questionnaire resources with a Resource.language of es (Spanish).
The standard search parameter _lastUpdated is used to match resources based on when
the most recent change has been made.
The _lastUpdated search parameter is defined as a date type parameter.
Matching is performed against the element Resource.meta.lastUpdated,
or an implementation's internal equivalent.
For example, the following search: Show as: HTTP GET | HTTP POST GET [base]/Observation?_lastUpdated=gt2010-10-01 POST [base]/Observation/_search Content-Type: application/x-www-form-urlencoded _lastUpdated=gt2010-10-01
is a search for Observations changed since October 1, 2010. Applications considering using this parameter should also consider defined synchronization approaches - RESTful history and Subscriptions framework.
The standard search parameter _list is used to test resources against references in a
List resource.
The _list search parameter is defined as a special type parameter.
Input values are treated as token values - either the logical identifier (id) of
a List or a literal for a functional list, as defined in
Current Resource Lists. Note that when using functional lists,
servers are not required to make the lists available to the clients as List resources,
but may choose to do so.
For example:
Show as: HTTP GET | HTTP POST
Description Search
Any resource referenced by List "101"
GET [base]/?_list=101
POST [base]/_search
Content-Type: application/x-www-form-urlencoded
_list=101
Conditions referenced by List "102"
GET [base]/Condition?_list=102
POST [base]/Condition/_search
Content-Type: application/x-www-form-urlencoded
_list=102
Female Patients referenced by List "103"
GET [base]/Patient?_list=013&gender=female
POST [base]/Patient/_search
Content-Type: application/x-www-form-urlencoded
_list=013&gender=female
Encounters for Patients in Group "104"
GET [base]/Encounter?patient._in=Group/104
POST [base]/Encounter/_search
Content-Type: application/x-www-form-urlencoded
patient._in=Group/104
Current allergy list for patient "42"
GET [base]/AllergyIntolerance?patient=42&_list=\$current-allergies
POST [base]/AllergyIntolerance/_search
Content-Type: application/x-www-form-urlencoded
patient=42&_list=\$current-allergies
For more information about membership testing, see Searching by Membership.
The standard search parameter _profile is used to match resources based on values in the
Resource.meta.profile element. Note that the
profile search does not test conformance of a resource against any profile, just the values of that
element.
The _profile search parameter is defined as a reference type parameter.
For example, the search:
Show as: HTTP GET | HTTP POST
GET [base]/Observation?_profile=http://hl7.org/fhir/StructureDefinition/bp
POST [base]/Observation/_search
Content-Type: application/x-www-form-urlencoded
_profile=http://hl7.org/fhir/StructureDefinition/bp
will match Observation resources that contain a Resource.meta.profile of http://hl7.org/fhir/StructureDefinition/bp.
The standard search parameter _query is used to execute a pre-defined and named query operation.
Note that there can only ever be one _query parameter in a set of search parameters. Servers processing
search requests SHALL refuse to process a search request if they do not recognize the _query parameter value.
The _query search parameter is defined as a special type parameter. Input to the
parameter is treated as a token-based search TU, requiring an exact match to the query name,
as defined by the OperationDefinition.code element.
There can only ever be one _query parameter in a set of search
parameters. Servers processing search requests SHALL
refuse to process a search request if they do not recognize
the _query parameter value.
For example, the search:
Show as: HTTP GET | HTTP POST
GET [base]/Patient?_query=current-high-risk&ward=1A
POST [base]/Patient/_search
Content-Type: application/x-www-form-urlencoded
_query=current-high-risk&ward=1A
is a request to run the named query current-high-risk against Patient resources, with a parameter
named ward set to the value 1A. If a server does not have a definition for
current-high-risk, it would reject the request.
More information about named queries can be found in the section Named Queries.
The standard search parameter _security is used to match resources based on security labels in the
Resource.meta.security element.
The _security search parameter is defined as a token type parameter.
For example, the search:
Show as: HTTP GET | HTTP POST
GET [base]/Observation?_security=http://terminology.hl7.org/CodeSystem/v3-Confidentiality|R
POST [base]/Observation/_search
Content-Type: application/x-www-form-urlencoded
_security=http://terminology.hl7.org/CodeSystem/v3-Confidentiality|R
will match Observation resources that contain a Resource.meta.security value matching the
system http://terminology.hl7.org/CodeSystem/v3-Confidentiality and code of R.
For more information about security labels, please see the Security Labels page.
The standard search parameter _source is used to match resources based on source information in the
Resource.meta.source element. Meta.source is
a lightweight way of providing minimal provenance for resources. If more functionality is required, use of
Provenance is recommended.
The _source search parameter is defined as a uri type parameter.
For example, the search:
Show as: HTTP GET | HTTP POST
GET [base]/Patient?_source=http://example.com/Organization/123
POST [base]/Patient/_search
Content-Type: application/x-www-form-urlencoded
_source=http://example.com/Organization/123
will match Patient resources that contain the Resource.meta.source value of
http://example.com/Organization/123.
The standard search parameter _tag is used to match resources based on tag information in the
Resource.meta.tag element. Tags are intended to be used
to identify and relate resources to process and workflow.
The _tag search parameter is defined as a token type parameter.
For example, the search:
Show as: HTTP GET | HTTP POST
GET [base]/Observation?_tag=http://terminology.hl7.org/ValueSet/v3-SeverityObservation|H
POST [base]/Observation/_search
Content-Type: application/x-www-form-urlencoded
_tag=http://terminology.hl7.org/ValueSet/v3-SeverityObservation|H
will match Observation resources that contain a tag value matching the system
http://terminology.hl7.org/ValueSet/v3-SeverityObservation and code H, indicating
that an observation has been tagged as potentially life-threatening or with the potential cause permanent injury.
The standard search parameter _text is used to perform searches against the narrative content
of a resource.
The _text search parameter is defined as a string type parameter.
While the actual format used by the parameter is implementation-dependant, the search is some form of string
which can be used for advanced searching.
For example, the following search:
Show as: HTTP GET | HTTP POST
GET [base]/Observation?_text=cancer OR metastases OR tumor
POST [base]/Observation/_search
Content-Type: application/x-www-form-urlencoded
_text=cancer OR metastases OR tumor
is a search for Observations that contain any of the phrases "cancer", "metastases", and "tumor" in
their narrative text (Observation.text). For example, the key words may appear in:
Observation.text - Text summary of the resource, for human interpretationObservation.code.text - Type of observation, Plain text representation of the conceptThe server MAY choose to search for related terms (e.g., "carcinoma", etc.), but is not required to do so.
More information can be found in the section Text Search Parameters.
The standard search parameter _type is used to allow filtering of types in searches
that are performed across multiple resource types (e.g., searches across the server root).
The _type search parameter is defined as a special type parameter,
because there is no standard path expression for searching the types of resources. However, the parameter is
a token parameter restricted to the Resource Types Value Set.
For example, the following search:
Show as: HTTP GET | HTTP POST
GET [base]/?_type=Observation,Condition&patient=Patient/123
POST [base]/_search
Content-Type: application/x-www-form-urlencoded
_type=Observation,Condition&patient=Patient/123
is a search for Observations and Conditions that are about the patient Patient/123. Since
the patient search parameter is valid on both the Observation and Condition resources, the
search is valid. The same search would not be valid if the _type parameter was
excluded, since patient is not a search parameter that works across all resources.
More information can be found in the section Searching Multiple Resource Types.
In addition to the common parameters defined 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).
In general, the defined search parameters correspond to a single element in the resource, but this is not required, and some search parameters refer to the same type of element in multiple places, or refer to derived values.
Some search parameters defined by resources are associated with more than one path in a resource. This means that the search parameter matches if any of the paths contain matching content. If a path matches, the whole resource is returned in the search results. The client may have to examine the resource to determine which path contains the match.
Servers are not required to implement any of the standard search parameters. However, servers SHOULD
support the _id parameter TU. Servers MAY also define their own parameters.
Note that all search parameters defined in this specification, both common and resource-specific, are listed in the search parameter registry.
The special text search parameters, _text and _content, search
on the narrative of the resource, and the entire content of the resource respectively.
Just like string parameters using the :text modifier, these parameters 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. For example (note that the values are unescaped for clarity):
Show as: HTTP GET | HTTP POST
GET [base]/Condition?_text=(bone OR liver) AND metastases
POST [base]/Condition/_search
Content-Type: application/x-www-form-urlencoded
_text=(bone OR liver) AND metastases
This request returns all Condition resources with the word "metastases" and either "bone" or "liver" in the narrative. The server MAY choose to search for related words as well.
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.
In order to allow the client to be confident about what search parameters were used as criteria by the server, the server SHALL return the parameters that were actually used to process the search. Applications processing search results SHALL check these returned values where necessary. For example, if the 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.
In the case of a RESTful search, these parameters are encoded in the self link in the bundle that is returned: Show as: FHIR+JSON | FHIR+XML "link": { "relation": "self", "url": "http://example.org/Patient?name=peter" } <link> <relation value="self"/> <url value="http://example.org/Patient?name=peter"/> </link>
In other respects, servers have considerable discretion with regards to supporting search:
_id above)._include parameter._count as above_sort parameter.The results of a search operation are only guaranteed to be current at the instant the operation is executed. After the operation is executed, ongoing actions performed on the resources against which the search was executed will render the results increasingly stale. The significance of this depends on the nature of the search, and the kind of use that is being made of the results.
This is particularly relevant when the server is returning the results in a series of pages. It is at the discretion of the search engine of how to handle ongoing updates to the resources while the search is proceeding.
Performing a search operation does not change the set of resources on the server, with the possible exception of the creation of Audit Event resources auditing the search itself.
| Common Parameters defined for all resources: | |||
| Name | Type | Description | Paths |
_content | string | Text search against the entire resource | |
_filter | special | Filter search parameter which supports a more sophisticated grammar for searching | |
_has | special | Provides limited support for reverse chaining | |
_id | token | Resource id (not a full URL) | Resource.id |
_in | reference | Group, List, or CareTeam membership | Resource.id |
_language | token | Language of the resource content | Resource.language |
_lastUpdated | date | Date last updated. Server has discretion on the boundary precision | Resource.meta.lastUpdated |
_list | string | All resources in nominated list (by id, not a full URL) | |
_profile | reference | Search for all resources tagged with a profile | Resource.meta.profile |
_query | string | Custom named query | |
_security | token | Search by a security label | Resource.meta.security |
_source | uri | Search by where the resource comes from | Resource.meta.source |
_tag | token | Search by a resource tag | Resource.meta.tag |
_text | string | Text search against the narrative | |
| Search Control Parameters: | |||
| Name | Type | Description | Allowable Content |
_contained | string | Whether to return resources contained in other resources in the search matches | true | false | both (false is default) |
_containedType | string | If returning contained resources, whether to return the contained or container resources | container | contained |
_count | number | Number of results per page | Whole number |
_elements | token | Request that only a specific set of elements be returned for resources | |
_graph | reference | Include additional resources according to a GraphDefinition | |
_include | string | Other resources to include in the search results that search matches point to | SourceType:searchParam(:targetType) |
_maxresults | number | Hint to a server that only the first 'n' results will ever be processed | Whole number |
_revinclude | string | Other resources to include in the search results when they refer to search matches | SourceType:searchParam(:targetType) |
_score | token | Request match relevance in results | true | false |
_sort | string | Order to sort results in (can repeat for inner sort orders) | Name of a valid search parameter |
_summary | string | Just return the summary elements (for resources where this is defined) | true | false (false is default) |
_total | token | Request a precision of the total number of results for a request | none | estimate | accurate |
Cross-map between search parameter types and Datatypes:
| Datatype | number | date | reference | quantity | uri | string | token |
| Primitive Types | |||||||
| base64Binary | Not used in search | ||||||
| boolean | N | N | N | N | N | N | Y . true|false (System = http://terminology.hl7.org/CodeSystem/special-values but not usually needed) |
| canonical | N | N | Y | N | Y | N | Y |
| code | N | N | N | N | N | N | Y . (System, if desired, is defined in the underlying value set for each code) |
| date | N | Y | N | N | N | N | N |
| dateTime | N | Y | N | N | N | N | N |
| decimal | Y | N | N | N | N | N | N |
| id | N | N | N | N | N | N | Y |
| instant | N | Y | N | N | N | N | N |
| integer | N | N | N | N | N | N | N |
| markdown | Not used in search | ||||||
| oid | Not used in search (but see uri) | ||||||
| positiveInt | Not used in search (but see integer) | ||||||
| string | N | N | N | N | N | Y | Y |
| time | Not used in search | ||||||
| unsignedInt | Not used in search (but see integer) | ||||||
| uri | N | N | Y | N | Y | N | N |
| url | Not used in search (but see uri) | ||||||
| uuid | Not used in search (but see uri) | ||||||
| Datatypes | |||||||
| Address | N | N | N | N | N | Y search on any string element in the address | N |
| Age | N | N | N | Y | N | N | N |
| Annotation | Not used in search | ||||||
| Attachment | Not used in search | ||||||
| CodeableConcept | N | N | N | N | N | N | Y |
| CodeableReference | Not used in search (searches either refer to .concept or .reference) | ||||||
| Coding | N | N | N | N | N | N | Y |
| Count | Not used in search | ||||||
| ContactPoint | N | N | N | N | N | N | Y |
| Distance | Not used in search | ||||||
| Duration | N | N | N | Y | N | N | N |
| HumanName | N | N | N | N | N | Y Search on any string element in the name | N |
| Identifier | N | N | N | N | N | N | Y |
| Money | N | N | N | Y | N | N | N |
| Period | N | Y | N | N | N | N | N |
| Quantity | N | N | N | Y | N | N | N |
| Range | N | N | N | Y | N | N | N |
| Ratio | Not used in search | ||||||
| Reference | N | N | Y | N | N | N | N |
| SampledData | Not used in search | ||||||
| Signature | Not used in search | ||||||
| Timing | N | Y | N | N | N | N | N |
FHIR ®© HL7.org 2011+. FHIR R5 hl7.fhir.core#5.0.0 generated on Sun, Mar 26, 2023 15:26+1100.
Links: Search |
Version History |
Contents |
Glossary |
QA |
Compare to R4 |
Compare to R4B |
|
Propose a change