Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
This describes the resources that make up the official Snow Owl® SNOMED CT Terminology API.
Swagger documentation is available on your Snow Owl instance at /snowowl/snomedct.
Snow Owl provides branching support for terminology repositories. In each repository there is an always existing and UP_TO_DATE branch called MAIN. The MAIN branch represents the latest working version of your terminology (similar to a master branch on GitHub).
You can create your own branches and create/edit/delete components and other resources on them. Branches are identified with their full path, which should always start with MAIN. For example the branch MAIN/a/b/c/d represents a branch under the parent MAIN/a/b/c with name d.
Later you can decide to either delete the branch or merge the branch back to its parent. To properly merge a branch back into its parent, sometimes it is required to rebase (synchronize) it first with its parent to get the latest changes. This can be decided via the state attribute of the branch, which represents the current state compared to its parent state.
There are five different branch states available:
UP_TO_DATE - the branch is up-to-date with its parent there are no changes neither on the branch or on its parent
FORWARD - the branch has at least one commit while the parent is still unchanged. Merging a branch requires this state, otherwise it will return a HTTP 409 Conflict.
BEHIND - the parent of the branch has at least one commit while the branch is still unchanged. The branch can be safely rebased with its parent.
DIVERGED - both parent and branch have at least one commit. The branch must be rebased first before it can be safely merged back to its parent.
STALE - the branch is no longer in relation with its former parent, and should be deleted.
Snow Owl supports merging of unrelated (STALE) branches. So branch MAIN/a can be merged into MAIN/b, there does not have to be a direct parent-child relationship between the two branches.
Response
Response
Input
Response
Response
Input
Response
Input
Response
Response
Response
This section describes common information about all available native APIs.
Custom media types are used in the API to let consumers choose the format of the data they wish to receive. This is done by adding one of the following types to the Accept header when you make a request. Media types are specific to resources, allowing them to change independently and support formats that other resources don’t.
The most basic media types the API supports are:
application/json (default)
text/plain;charset=UTF-8
text/csv;charset=UTF-8
application/octet-stream (for file downloads)
multipart/form-data (for file uploads)
We encourage you to explicitly set the accepted content type before sending your request.
All data is sent and received as JSON. Blank fields are omitted instead of being included as null.
Timestamps use the ISO 8601 format:
Effective time values used in SNOMED CT (and other terminology content as well) are sent and received in short format:
An example Location header looks like this:
Requests that return multiple items will be paginated to 50 items by default. You can request further pages with the searchAfter query parameter.
Where applicable, the expand query parameter will include nested objects in the response, to avoid having to issue multiple requests to the server.
Expanded properties should be followed by parentheses and separated by commas; any options for the expanded property should be given within the parentheses, including properties to expand. Typical values for parameters are given in the "Implementation Notes" section of each endpoint.
Response:
There are three possible types of client errors on API calls that receive request bodies:
In certain circumstances, Snow Owl might fail to process and respond to a request and responds with a 500 Internal Server Error.
Snow Owl is a revision-based terminology server, where terminology data (concepts, descriptions, etc.) is stored in multiple revisions across multiple branches. When requesting content from the terminology server, clients can specify a path value or expression to select the content they'd like to access and receive.
For example, Snow Owl supports importing SNOMED CT content from different sources, allowing eg. multiple national Extensions to co-exist with the base International Edition provided by SNOMED International.
Versioned editions can be consulted when non-current representations of concepts need to be accessed. Concept authoring and review can also be done in isolation. Both Java and REST API endpoints require a path parameter to select the content (or substrate) the user wishes to work with.
The following formats are accepted:
Absolute branch path parameters start with MAIN and point to a branch in the backing terminology repository. In the following example, all concepts are considered to be part of the substrate that are on branch MAIN/2021-01-31/SNOMEDCT-UK-CL or any ancestor (ie. MAIN or MAIN/2021-01-31), unless they have been modified:
Relative branch paths start with a short name identifying a SNOMED CT code system, and are relative to the code system's working branch. For example, if the working branch of code system SNOMEDCT-UK-CL is configured to MAIN/2021-01-31/SNOMEDCT-UK-CL, concepts visible on authoring task #100 can be retrieved using the following request:
An alternative request that uses an absolute path would be the following:
An important difference is that the relative path parameter tracks the working branch specified in the code system's settings, so requests using relative paths do not need to be adjusted when a code system is upgraded to a more recent International Edition.
The substrate represented by a path range consists of concepts that were created or modified between a starting and ending point, each identified by an absolute branch path (relative paths are not supported). The format of a path range is fromPath...toPath.
To retrieve concepts authored or edited following version 2020-08-05 of code system SNOMEDCT-UK-CL, the following path expression should be used:
The result set includes the ones appearing or changing between versions 2019-07-31 and 2021-01-31 of the International Edition; if this is not desired, additional constraints can be added to exclude them.
To refer to a branch state at a specific point in time, use the path@timestamp format. The timestamp is an integer value expressing the number of milliseconds since the UNIX epoch, 1970-01-01 00:00:00 UTC, and corresponds to "wall clock" time, not component effective time. As an example, if the SNOMED CT International version 2021-07-31 is imported on 2021-09-01 13:50:00 UTC, the following request to retrieve concepts will not include any new or changed concepts appearing in this release:
Both absolute and relative paths are supported in the path part of the expression.
Concept requests using a branch base point reflect the state of the branch at its beginning before any changes on it were made. The format of a base path is path^ (only absolute paths are supported):
Returned concepts include all additions and modifications made on SNOMEDCT-UK-CL's working branch, up to the point where task #101 starts; neither changes committed to the working branch after task #101, nor changes on task #101 itself are reflected in the result set.
Comparison for current terminology changes committed to a source or target branch can be conducted by creating a compare resource.
A review identifier can be added to merge requests as an optional property. If the source or target branch state is different from the values captured when creating the review, the merge/rebase attempt will be rejected. This can happen, for example, when additional commits are added to the source or the target branch while a review is in progress; the review resource state becomes STALE in such cases.
Reviews and concept change sets have a limited lifetime. CURRENT reviews are kept for 15 minutes, while review objects in any other states are valid for 5 minutes by default. The values can be changed in the server's configuration file.
Response
Terminology components (and in fact any content) can be read from any point in time by using the special path expression: {branch}@{timestamp}. To get the state of a SNOMED CT Concept from the previous comparison on the compareBranch at the returned compareHeadTimestamp, you can use the following request:
Request
Response
To get the state of the same SNOMED CT Concept but on the base branch, you can use the following request:
Request
Response
Additionally, if required to compute what's changed on the component since the creation of the task, it is possible to get back the base version of the changed component by using another special path expression: {branch}^.
Request
Response
These characters are not URL safe characters, thus they must be encoded before sending the HTTP request.
POST requests that create a resource will return a Location response header that holds the URL of the created resource. It is highly recommended that API clients use these. Doing so will make future upgrades of the API easier for developers. All URLs are expected to be proper URI templates.
To troubleshoot these please examine the log files at {SERVER_HOME}/serviceability/logs/log.log and/or .
Two categories make up Snow Owl's Reference Set API:
Reference Sets category to get, search, create and modify reference sets
Reference Set Members category to get, search, create and modify reference set members
Basic operations like create, update, delete are supported for both category.
On top of the basic operations, reference sets and members support actions. Actions have an action property to specify which action to execute, the rest of the JSON properties will be used as body for the Action.
Supported reference set actions are:
sync - synchronize all members of a query type reference set by executing their query and comparing the results with the current members of their referenced target reference set
Supported reference set member actions are:
create - create a reference set member (uses the same body as POST /members)
update - update a reference set member (uses the same body as PUT /members)
delete - delete a reference set member
sync - synchronize a single member by executing the query and comparing the results with the current members of the referenced target reference set
For example the following will sync a query type reference set member's referenced component with the result of the reevaluated member's ESCG query
Members list of a single reference set can be modified by using the following bulk-like update endpoint:
Input
The request body should contain the commitComment property and a request array. The request array must contain actions (see Actions API) that are enabled for the given set of reference set members. Member create actions can omit the referenceSetId parameter, those will use the one defined as path parameter in the URL. For example by using this endpoint you can create, update and delete members of a reference set at once in one single commit.
SNOMED CT concepts represent ideas that are relevant in a clinical setting and have a unique concept identifier (a SNOMED CT identifier or SCTID for short) assigned to them. The terminology covers a wide set of domains and includes concepts that represent parts of the human body, clinical findings, medicinal products and devices, among many others. SCTIDs make it easy to refer unambiguously to the described ideas in eg. an Electronic Health Record or prescription, while SNOMED CT's highly connected nature allows complex analytics to be performed on aggregated data.
Each concept is associated with human-readable descriptions that help users select the SCTID appropriate for their use case, as well as relationships that form links between other concepts in the terminology, further clarifying their intended meaning. The API for manipulating the latter two types of components are covered in sections and , respectively.
The three component types mentioned above (also called core components) have a distinct set of attributes which together form the concept's definition. As an example, each concept includes an attribute (the definition status) which states whether the definition is sufficiently defined (and so can be computationally processed), or relies on a (human) reader to come up with the correct meaning based on the associated descriptions.
Terminology services exposed by Snow Owl allows clients to create, retrieve, modify or remove concepts from a SNOMED CT code system (concepts that are considered to be already published to consumers can only be removed with an administrative operation). Concepts can be retrieved by SCTID or description search terms; results can be further constrained via Expression Constraint Language (ECL for short) expressions.
A concept resource without any expanded properties looks like the following:
id
effectiveTime
active
moduleId
definitionStatusId
It also contains the following supplementary information:
parentIds, ancestorIds
These arrays hold a set of SCTIDs representing the concept's direct and indirect ancestors in the inferred taxonomy. The (direct) parents array contains all destinationIds from active and inferred IS A relationships where the sourceId matches this concept's SCTID, while the ancestor array contains all SCTIDs taken from the parent and ancestor array of direct parents. The arrays are sorted by SCTID. A value of -1 means that the concept is a root concept that does not have any concepts defined as its parent. Typically, this only applies to 138875005|Snomed CT Concept| in SNOMED CT content.
See the following example response for a concept placed deeper in the tree:
Compare the output with a rendering from a user interface, where the concept appears in two different places after exploring alternative routes in the hierarchy. Parents are marked with blue, while ancestors are highlighted with orange:
statedParentIds, statedAncestorIds
Same as the above, but for the stated taxonomy view.
released
A boolean value indicating whether this concept was part of at least one SNOMED CT release. New concepts start with a value of false, which is set to true as part of the code system versioning process. Released concepts can only be deleted by an administrator.
iconId
administration_method, assessment_scale, attribute, basic_dose_form, body_structure, cell, cell_structure, clinical_drug, disorder, disposition, dose_form, environment, environment_location, ethnic_group, event, finding, geographic_location, inactive_concept, intended_site, life_style, link_assertion, linkage_concept, medicinal_product, medicinal_product_form, metadata, morphologic_abnormality, namespace_concept, navigational_concept, observable_entity, occupation, organism, owl_metadata_concept, person, physical_force, physical_object, procedure, product, product_name, qualifier_value, racial_group, record_artifact, regime_therapy, release_characteristic, religion_philosophy, role, situation, snomed_rt_ctv3, social_concept, special_concept, specimen, staging_scale, state_of_matter, substance, supplier, transformation, tumor_staging, unit_of_presentation
In the metadata hierarchy, the use of a hierarchy tag alone would not distinguish concepts finely enough, as lots of them will have eg. "foundation metadata concept" set as their tag. In these cases, concept identifiers may be used as the icon identifier.
subclassDefinitionStatus
The default value is NON_DISJOINT_SUBCLASSES where no such assumption is made.
Core component information related to the current concept can be attached to the response by using the expand query parameter, allowing clients to retrieve more data in a single roundtrip. Property expansion runs the necessary requests internally, and attaches results to the original response object.
Expand options are expected to appear in the form of propertyName1(option1: value1, option2: value2, expand(...)), propertyName2() where:
propertyNameN stands for the property to expand;
optionN: valueN are key-value pairs providing additional filtering for the expanded property;
optionally, expands can be nested, and the options will apply to the components returned under the parent property;
when no expand options are given, an empty set of () parentheses need to be added after the property name.
Supported expandable property names are:
referenceSet()If a corresponding reference set was already created for an identifier concept (a subtype of 900000000000455006|Reference set), information about the reference set will appear in the response:
To retrieve reference set members along with the reference set in a single request, use a nested expand property named members:
preferredDescriptions()Expands descriptions with preferred acceptability.
Returns all active descriptions that have at least one active language reference set member with an acceptabilityId of 900000000000548007|Preferred|, in compact form, along with the concept. Preferred descriptions are frequently used on UIs when a display label is required for a concept.
This information is also returned when expand options pt() or fsn() (described later) are present.
semanticTags()Returns hierarchy tags extracted from FSNs.
An array containing the hierarchy tags from all Fully Specified Name-typed descriptions of the concept is added as an expanded property if this option is present:
inactivationProperties()Collects information from concept inactivation indicator and historical association reference set members referencing this concept.
Members of 900000000000489007|Concept inactivation indicator attribute value reference set| and subtypes of 900000000000522004 |Historical association reference set| hold information about a reason a concept is being retired in a release, as well as suggest potential replacement(s) for future use.
The concept stating the reason for inactivation is placed under inactivationProperties.inactivationIndicator.id (a short-hand property exists without an extra nesting, named inactivationProperties.inactivationIndicatorId). It is expected that only a single active inactivation indicator exists for an inactive concept.
Historical associations are returned under the property inactivationProperties.associationTargets as an array of objects. Each object includes the identifier of the historical association reference set and the target component identifier, in the same manner as described above – as an object with a single id property and as a string value.
While most object values where a single id key is present indicate that the property can be expanded to a full resource representation, this is currently not supported for inactivation properties; an expand option of inactivationProperties(expand(inactivationIndicator())) will not retrieve additional data for the indicator concept.
members()Expands reference set members referencing this concept.
Note that this is different from reference set member expansion on a reference set, ie. referenceSet(expand(members())), as this option will return reference set members where the referencedComponentId property matches the concept SCTID, from multiple reference sets (if permitted by other expand options). Inactivation and historical association members can also be returned here, in their entirety (as opposed to the summarized form described in inactivationProperties() above).
Compare the output with the one returned when inactivation indicators were expanded. The last two reference set members correspond to the historical association and the inactivation reason, respectively:
The following expand options are supported within members(...):
active: true | false
Controls whether only active or inactive reference set members should be returned.
refSetType: "{type}" | [ "{type}"(,"{type}")* ]
The reference set type(s) as a string, to be included in the expanded output; when multiple types are accepted, values must be enclosed in square brackets and separated by a comma.
expand(...)
Allows nested expansion of reference set member properties.
SIMPLE - simple type
SIMPLE_MAP - simple map type
LANGUAGE - language type
ATTRIBUTE_VALUE - attribute-value type
QUERY - query specification type
COMPLEX_MAP - complex map type
DESCRIPTION_TYPE - description type
CONCRETE_DATA_TYPE - concrete data type (vendor extension for representing concrete values in Snow Owl)
ASSOCIATION - association type
MODULE_DEPENDENCY - module dependency type
EXTENDED_MAP - extended map type
SIMPLE_MAP_WITH_DESCRIPTION - simple map type with map target description (vendor extension for storing a descriptive label with map targets, suitable for display)
OWL_AXIOM - OWL axiom type
OWL_ONTOLOGY - OWL ontology declaration type
MRCM_DOMAIN - MRCM domain type
MRCM_ATTRIBUTE_DOMAIN - MRCM attribute domain type
MRCM_ATTRIBUTE_RANGE - MRCM attribute range type
MRCM_MODULE_SCOPE - MRCM module scope type
ANNOTATION - annotation type
COMPLEX_BLOCK_MAP - complex map with map block type (added for national extension support)
See the following example for combining reference set member status filtering and reference set type restriction:
module()Expands the concept's module identified by property moduleId, and places it under the property module. As the returned resource is a concept itself, property expansion can apply to modules as well by using a nested expand() option.
Property module does not appear in compact form (with a single id key) in the standard representation.
definitionStatus()Expands the definition status concept identified by the property definitionStatusId, and places it under the property definitionStatus. When this property is not expanded, a smaller placeholder object with a single id property is returned in the response. Nested expand() options work the same way as in the case of module().
pt() and fsn()In addition to the standard locales like en-US, Snow Owl uses an extension to allow referring to language reference sets by identifier, in the form of {language code}-x-{language reference set ID}. "Traditional" language tags are resolved to language reference set IDs as part of executing the request by consulting the code system settings:
An example response pair demonstrating cases where the PT is different in certain dialects:
descriptions()The collection resource's limit and total values are set to the same value (the number of descriptions returned for the concept) because a description fetch limit can not be set via a property expand option.
The following expand options are supported within descriptions(...):
active: true | false
Controls whether only active or inactive descriptions should be included in the response. (If both are required, do not set any value for this expand property.)
typeId: "{expression}"
sort: "{field}(:{asc | desc})?"(, "{field}(:{asc | desc})")*
Items in the collection resource are sorted based on the sort configuration given in this option. A single, comma-separated string value is expected; field names and sort order must be separated by a colon (:) character. When no sort order is given, ascending order (asc) is assumed.
expand(...)
Allows nested expansion of description properties.
relationships()limit and total values on relationships are set to the same value (the number of relationships returned for the concept) because a relationship fetch limit can not be set via an expand option.
The following expand options are supported within relationships(...):
active: true | false
Controls whether only active or inactive relationships should be included in the response. (If both are required, do not set any value for this expand property.)
characteristicTypeId: "{expression}"
An ECL expression that restricts the characteristicTypeId property of each returned relationship. As an example, when this value is set to "<<900000000000006009", both stated and inferred relationships will be returned, as their characteristic type concepts are descendants of 900000000000006009|Defining relationship|.
typeId: "{expression}"
An ECL expression that restricts the typeId property of each returned relationship.
destinationId: "{expression}"
An ECL expression that restricts the destinationId property of each returned relationship.
sort: "{field}(:{asc | desc})?"(, "{field}(:{asc | desc})")*
Items in the collection resource are sorted based on the sort configuration given in this option. A single, comma-separated string value is expected; field names and sort order must be separated by a colon (:) character. When no sort order is given, ascending order (asc) is assumed.
expand(...)
Allows nested expansion of relationship properties.
inboundRelationships()Retrieves all "inbound" relationships, where the destinationId property matches the SCTID of the concept(s), adding them to property inboundRelationships.
limit and total values on inboundRelationships are set to the same value (the number of inbound relationships returned for the concept), but differently from options above, a fetch limit is applied when it is specified.
destinationId: "{expression}"
This option is not supported on inboundRelationships; all destination IDs match the concept's SCTID.
sourceId: "{expression}"
An ECL expression that restricts the sourceId property of each returned relationship.
limit: {limit}
Limits the maximum number of inbound relationships to be returned. Not recommended for use when the expand option applies to a collection of concepts, not just a single one, as the limit is not applied individually for each concept.
descendants() / statedDescendants()Depending on which direct setting is used, retrieves all concepts whose [stated]parentIds and/or [stated]AncestorIds array contains this concept's SCTID. Results are added to property descendants or statedDescendants, based on the option name used.
Only active concepts are returned, as these are expected to have active "IS A" relationships or OWL axioms that describe the relative position of the concept within the terminology graph.
The following options are available:
direct: true | false (required)
Controls whether only direct descendants should be collected or a transitive closure of concept subtypes.
When set to true, property [stated]parentIds will be searched only, otherwise both [stated]parentIds and [stated]AncestorIds are used. The presence or absence of the "stated" prefix in the search field depends on the option name.
limit: 0
Applicable only when a single concept's properties are expanded. Collects the number of descendants in an efficient manner, and sets the total property of the returned collection resource without including any concepts in it. Not used when a collection of concepts are expanded in a single request, or any other value is given.
expand(...)
Allows nested expansion of concept properties on each collected descendant.
ancestors() / statedAncestors()Depending on which direct setting is used, retrieves all concepts that appear in this concept's [stated]parentIds and/or [stated]AncestorIds array. Results are added to property ancestors or statedAncestors, based on the option name used.
The following options are available:
direct: true | false (required)
Controls whether only direct ancestors should be collected or a transitive closure of concept supertypes.
When set to true, property [stated]parentIds will be used only for concept retrieval, otherwise the union of [stated]parentIds and [stated]AncestorIds are collected (the special placeholder value "-1" is ignored). The presence or absence of the "stated" prefix in the search field depends on the option name.
limit: 0
Collects the number of ancestors in an efficient manner, and sets the total property of the returned collection resource without including any concepts in it. Not used when any other value is given (however, this property expansion supports cases where multiple concepts' ancestors need to be returned).
expand(...)
Allows nested expansion of concept properties on each collected ancestor.
A GET request that includes a concept identifier as its last path parameter will return information about the concept in question:
expand={options}
field={field1}[,{fieldN}]*
Restricts the set of fields returned from the index. Results in a smaller response object when only specific information is needed.
Supported names for field selection are the following:
active
activeMemberOf
ancestors - controls the appearance of ancestorIds as well
definitionStatusId
doi
effectiveTime
exhaustive
iconId
id - always included in the response, even when not present as a field parameter
mapTargetComponentType
memberOf
moduleId
namespace
parents - controls the appearance of parentIds as well
preferredDescriptions
refSetType
referencedComponentType
released
score
semanticTags
statedAncestors - controls the appearance of statedAncestorIds as well
statedParents - controls the appearance of statedParentIds as well
createdrevised
Specifying any other field name results in a 400 Bad Request response:
Fields with a value of null do not appear in the response, even if they are selected for inclusion.
Accept-Language: {language-range}[;q={weight}](, {language-range}[;q={weight}])*
Specifying an unknown language or dialect results in a 400 Bad Request response:
A GET request that ends with concepts as its last path parameter will search for concepts matching all of the constraints supplied as query parameters. By default (when no query parameter is added) it returns all concepts.
The response consists of a collection of concept resources, a searchAfter key (described in section "Query parameters" below), the limit used when computing response items and the total hit count:
definitionStatus={eclExpression} | {id1}[,{idN}]*
An ECL expression or enumerated list that describes the allowed set of SCTIDs that must appear in matching concepts' definitionStatusId property. Since there are only two values used, 900000000000074008|Primitive| and 900000000000073002|Defined| for primitive and fully defined concepts, respectively, a single SCTID is usually entered here.
ecl={eclExpression}
As ECL syntax uses special symbols, query parameters should be encoded to URL-safe characters. The examples in this section are using the cleartext form for better readability.
statedEcl={eclExpression}
semanticTag={tag1}[,{tagN}]*
Filters concepts by a comma-separated list of allowed hierarchy tags. Matching concepts can have any of the supplied tags present (at least one) on their Fully Specified Names.
term={searchTerm}
Matching concepts must have an active description whose term matches the string specified here. The search is executed in "smart match" mode; the following examples show which search expresssions match which description terms:
descriptionType={eclExpression} | {id1}[,{idN}]*
Restricts the result set by description type; matches must have at least one active description whose typeId property is included in the evaluated ECL result set or SCTID list. It is typically used in combination with term (see above) to control which type of descriptions should be matched by term.
parent={id1}[,{idN}]*
statedParent={id1}[,{idN}]*
ancestor={id1}[,{idN}]*
statedAncestor={id1}[,{idN}]*
Filters concepts by hierarchy. All four query parameters accept a comma-separated list of SCTIDs; the result set will contain direct descendants of the specified values in the case of parent and statedParent, and a transitive closure of descendants for ancestor and statedAncestor (including direct children). Parameters starting with stated... will use the stated IS A hierarchy for computations.
doi=true | false
Controls whether relevance-based sorting should take Degree of Interest (DOI for short) into account. When enabled, concepts that are used frequently in a clinical environment are favored over concepts with a lower likelihood of use.
namespace={namespaceIdentifier}
namespaceConceptId={id1}[,{idN}]*
isActiveMemberOf={eclExpression} | {id1}[,{idN}]*
This filter accepts either a single ECL expression, or a comma-separated list of reference set SCTIDs. For each matching concept at least one active reference set member must exist where the referenceComponentId points to the concept and the referenceSetId property is listed in the filter, or is a member of the evaluated ECL expression's result set.
effectiveTime={yyyyMMdd} | Unpublished
Filters concepts by effective time. The query parameter accepts a single effective time in yyyyMMdd (short) format, or the literal Unpublished when searching for concepts that have been modified since they were last published as part of a code system version.
Note that only the concept's effective time is taken into account, not any of its related core components (descriptions, relationships) or reference set members. If the concept's status, definition status or module did not change since the last release, its effective time will not change either.
When searching for Unpublished concepts, the effectiveTime property will not appear on returned concept resources, as the value is null for all unpublished components.
active=true | false
Filters concepts by status. When set to true, only active concepts are added to the resulting collection, while a value of false collects inactive concepts only. (If both active and inactive concepts should be returned, do not add this parameter to the query.)
module={eclExpression} | {id1}[,{idN}]*
Filters concepts by moduleId. The query parameter accepts either a single ECL expression, or a comma-separated list of module SCTIDs; concepts must have a moduleId property that is included in the ID list or the evaluated ECL result.
id={id1}[,{idN}]*
Filters concepts by SCTID. The parameter accepts a comma-separated list of IDs; matching concepts must have an id property that matches any of the specified identifiers.
sort: "{field}(:{asc | desc})?"(, "{field}(:{asc | desc})")*
Sorts returned concept resources based on the sort configuration given in this parameter. Field names and sort order must be separated by a colon (:) character. When no sort order is given, ascending order (asc) is assumed.
The default behavior is to sort results by id, in ascending order. SCTIDs are sorted lexicographically, not as numbers; this means that eg. 10683591000119104 will appear before 10724008, as their first two digits are the same, but the third digit is smaller in the former identifier.
limit={limit}
Controls the maximum number of items that should be returned in the collection. When not specified, the default limit is 50 items.
searchAfter={searchAfter}
Supports keyset pagination, ie. retrieving the next page of items based on the response for the current page. To use, set limit to the number of items expected on a single page, then run the first search request without setting a searchAfter key. The returned response will include the value to be inserted into the next request:
The process can be repeated until the items array turns up empty, indicating that there are no more pages to return.
expand={options}
field={field1}[,{fieldN}]*
Accept-Language: {language-range}[;q={weight}](, {language-range}[;q={weight}])*
POST requests submitted to concepts/search perform the same search operation as described for the GET request above, but each query parameter is replaced by a property in the JSON request body:
Accept-Language: {language-range}[;q={weight}](, {language-range}[;q={weight}])*
POST requests submitted to concepts create a new concept with the specified parameters, then commit the result to the terminology repository.
The resource path typically consists of a single code system identifier for these requests, indicating that changes should go directly to the working branch of the code system, or a direct child of the working branch for isolating a set of changes that can be reviewed and merged in a single request.
The request body needs to conform to the following requirements:
include at least one Fully Specified Name (FSN)
include at least one preferred synonym (Preferred Term, PT)
The SCTID of created components can be specified in two ways:
Explicitly by setting the id property on the component object; the request fails when an existing component in the repository already has the same SCTID assigned to it;
Allowing the server to generate an identifier by leaving id unset and populating namespaceId with the expected namespace identifier, eg. "1000154". Requests using namespaceId should not fail due to an SCTID collision, as generated identifiers are checked for uniqueness.
When a namespaceId is set on the concept level, descriptions and relationships will use this value by default, so in this case neither id nor namespaceId needs to be set on them. The same holds true for moduleId – the concept's module identifier is applied to all related descriptions, relationships and reference set members in the request, unless it is set to a different value on the component object.
Please see the example below for required properties. (Note that it is non-executable in its current form, as the OWL axiom reference set member can not be created without knowing the concept's SCTID in advance.)
A successful commit will result in a 201 Created response; the response header Location can be used to extract the generated concept identifier. Validation errors in the request body cause a 400 Bad Request response.
X-Author: {author_id}
Changes the author recorded in the commit message from the authenticated user (default) to the specified user.
The following properties can be updated on any component. If they are not included in the request, the corresponding component property remains unchanged.
moduleId: string
active: boolean
effectiveTime: string (in YYYYmmdd, "short" format)
Specifying an empty string for inactivationIndicatorId will remove an existing indicator, while an empty array will delete historical association reference set members for the concept. This is handled automatically when the concept is re-activated, so inactivationProperties can be omitted from such requests entirely:
Properties that can be updated on the concept itself are:
definitionStatusId: string
subclassDefinitionStatus: "DISJOINT_SUBCLASSES" | "NON_DISJOINT_SUBCLASSES"
In addition to the above, core components and reference set members related to the concept in question can be updated in a single request by including any of the following properties:
descriptions
relationships
members
If a collection resource property is not included in the update request, the corresponding component type is unchanged. An empty array attempts to delete all existing related components. Otherwise, the components included in the collection are compared by SCTID/UUID to existing components, and it is decided whether:
a new component should be created (if the identifier did not appear previously in the terminology store)
an existing component should be updated (if the identifier existed previously in the terminology store)
an existing component should be deleted (if the identifier does not exist in the request, but existed previously in the terminology store)
Successful updates return 204 No Content from the server. Updates that attempt to modify the state of a missing or deleted concept result in a 404 Not Found response.
force=true | false
Specifies whether updating the effective time of the concept should be allowed. The default value is false; in such cases, supplying an effective time property for the update is disallowed. The component's effective time after an update is computed automatically at all times, when the force property is set to true, this can be overridden externally.
X-Author: {author_id}
Changes the author recorded in the commit message from the authenticated user (default) to the specified user.
DELETE requests sent to a URI where the last path parameter is an existing concept ID will remove the concept and all of its associated components (descriptions, relationships, reference set members referring to the concept) from the terminology repository.
Deletes are acknowledged with a 204 No Content response on success. Deletion can be verified by trying to retrieve concept information from the same resource path – a 404 Not Found should be returned in this case.
Note that resource branches maintain content in isolation, and so deleting a concept on eg. a task branch will not remove the concept from the code system's working branch, until work on the task branch is approved and merged into mainline.
force=true | false
Specifies whether deletion of the concept should be allowed, if it has components that were already part of an RF2 release (or code system version). This is indicated by the released property on each component.
The default value is false; with the option disabled, attempting to delete a released component results in a 409 Conflict response:
Only administrators should set this parameter to true. It is advised to delete redundant or erroneous components before they are put in circulation as part of a SNOMED CT RF2 release. In other cases, inactivation should be preferred over removal.
X-Author: {author_id}
Changes the author recorded in the commit message from the authenticated user (default) to the specified user.
The resource includes all RF2 properties that are defined in SNOMED International's :
A descriptive key for the concept's icon. The icon identifier typically corresponds to the lowercase, underscore-separated form of the contained in each concept's Fully Specified Name (or FSN for short). The following keys are currently expected to appear in responses (subject to change):
Currently unsupported. Indicates whether a parent concept's direct descendants form a in OWL 2 terms; when set to DISJOINT_SUBCLASSES, child concepts are assumed to be pairwise disjoint and together cover all possible cases of the parent concept.
Expands reference set metadata and content, available on .
Note that the response object for property referenceSet can also be retrieved directly using the .
Reference set members can also be fetched via the .
Reference set members can also be fetched in a "standalone" fashion via the .
Allowed reference set type constants are (these are described in the section of SNOMED International's "Reference Sets Practical Guide" and the section of "Release File Specification" in more detail):
Expands the (PT for short) and the (FSN for short) of the concept, respectively.
These descriptions are language context-dependent; the use of certain descriptions can be preferred in one dialect and acceptable or discouraged in others. The final output is controlled by the request header, which clients can use to supply a list of locales in order of preference.
Expands all descriptions associated with the concept, and adds them to a collection resource (that includes an element limit and a total hit count) under the property descriptions. These can also be retrieved separately by the use of the .
An ECL expression that restricts the typeId property of each returned description. The simplest expression is a single SCTID, eg. when this option has a value of "900000000000013009", only will be expanded.
Retrieves all "outbound" relationships, where the sourceId property matches the SCTID of the concept(s), adding them to a property named relationships as a collection resource object. The same set of relationships can also be retrieved in standalone form via Snow Owl's .
The same set of options are supported within inboundRelationships as in relationships (see ), with three important differences:
Concept properties that should be returned along with the original request, as part of the concept resource. See available options in section above.
Controls the logic behind Preferred Term and Fully Specified Name selection for the concept. See the documentation for expand options for details.
Restricts the returned set of concepts to those that match the specified ECL expression. The query parameter can be used on its own for evaluation of expressions, or in combination with other query parameters. Expressions conforming to the short form of ECL 1.5 syntax are accepted. The expression is evaluated over the , based on the currently persisted inferred relationships.
Same as ecl, but the input expression is evaluated over the by using stated relationships (if present) and OWL axioms for evaluation.
The SCTID of matching concepts must have the specified 7-digit , eg. 1000154. When matching by namespace concept ID, a comma-separated list of SCTIDs are expected, and the associated 7-digit identifier will be extracted from the active FSNs of each concept entered here.
Field names supported for sorting are the same that are used for field selection; please see for the complete list.
searchAfter keys should be considered opaque; they can not be constructed to jump to an arbitrary point in the enumeration. Keyset pagination also doesn't handle cases gracefully where eg. concepts with "smaller" SCTIDs are inserted while pages are retrieved from the server. If a consistent result set is expected, a path parameter should be used in consecutive search requests.
Concept properties that should be returned along with the original request, as part of the concept resource. See available options in section above.
Restricts the set of fields returned from the index. Results in a smaller response object when only specific information is needed. See for the list of supported field names.
Controls the logic behind Preferred Term and Fully Specified Name selection for returned concepts. See the documentation for expand options for details.
Controls the logic behind Preferred Term and Fully Specified Name selection for returned concepts. See the documentation for expand options for details.
PUT requests to locations that identify a concept resource (same as when concept content) will update the concept. Following a successful commit, the state of the concept on the branch should match the state received in the request body.
When a concept, an object named inactivationProperties can be added that can point to possible replacement concepts and/or specify the reason for inactivation:
Each of the above can hold a collection resource of the respective component resource type. These resources are described in detail in sections , and , respectively.