Skip to main content
The search operation lets you fetch resources by filtering them with supplied parameters. The parameters are a series of name=[value] pairs. The syntax for Read and Search is described here. Parameters can be encoded in the URL in case of search by GET method: 
GET [base]/[type]?name=value&...{&_format=[mime-type]}}
or as an application/x-www-form-urlencoded submission for a POST: 
POST  [base]/[type]/_search{?[parameters]{&_format=[mime-type]}}
The response to any search operation is always a list of resources in a Bundle or an OperationOutcome.

​
Supported global search parameters

The following parameters apply to all resources:
Parameters for all resourcesStatus
_idsupported
_lastUpdatedsupported
_tagsupported
_profilesupported
_securitysupported
_sourcesupported
_textunsupported
_contentunsupported
_listunsupported
_hasunsupported
_typeunsupported

​
Supported search parameter types

Each search parameter is defined by a type that specifies how the search parameter behaves. These are the defined parameter types:
Search Parameter TypeStatus
numbersupported
datesupported
stringsupported
tokensupported
referencesupported
compositesupported
quantityunsupported
urisupported
specialunsupported

​
Support of modifiers/prefixes for number/date search parameter type

Search Parameter Type/Modifier or Prefixmissinggtltgelesaebne
number++++++++
date++++++++
dateTime++++++++
instant++++++++
Period++++++++
Timing--------

​
Support of modifiers/prefixes for string search parameter type

Search Parameter Type/Modifier or Prefixmissingexactcontains
string-++
string.Address---
string.HumanName-++

​
Support of modifiers/prefixes for token search parameter type

Search Parameter Type/Modifier or Prefixmissingtextnotabovebelowinnot-inof-type
token+++----+

​
Support of modifiers/prefixes for reference search parameter type

Search Parameter Type/Modifier or Prefixmissingtypeidentifierabovebelow
reference+++--

​
Support of modifiers/prefixes for uri search parameter type

Search Parameter Type/Modifier or Prefixmissingabovebelow
uri---
Search in Kodjin FHIR is dynamic. In order to enable search on some new parameter SearchParameter resource should be added via API. Elastic Search index should also be configured.

​
Pagination

Search in Kodjin supports two types of pagination: -offset pagination (with skip or page params). Examples: 
	curl --location --request GET 'https://test.fhir.edenlab.tech/fhir/Coverage' \
	--header 'Prefer: pagination=offset-skip'

	curl --location --request GET 'https://test.fhir.edenlab.tech/fhir/Coverage' \
	--header 'Prefer: pagination=offset-page'
-cursor pagination. Example: 
	curl --location --request GET 'https://test.fhir.edenlab.tech/fhir/Patient?_count=3' \
	--header 'Prefer: pagination=cursor'
Default one is the cursor.

​
Handling errors

Kodjin will not return an error if a parameter refers to a non-existent resource e.g. GET [base]/Observation?subject=101, where “101” does not exist, or to an unknown code e.g. GET [base]/Observation?code=loinc|1234-1, where the LOINC code “1234-1” is not known to the server. The response will be an empty search bundle. Kodjin will return an error if it receives parameters from the client that it does not recognize, or parameters it recognizes but do not support (either in general, or for a specific search). By default Kodjin FHIR Server ignores unknown or unsupported parameters for the following reasons: various HTTP stacks and proxies may add parameters that aren’t under the control of the client. 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 parameter
-Prefer: handling=lenient: Client requests that the server ignore any unknown or unsupported parameter Example: 
{
    "resourceType": "OperationOutcome",
    "issue": [
        {
            "severity": "error",
            "code": "not-found",
            "details": {
                "text": "Unknown query param: test"
            }
        }
    ]
}