Concepts
Introduction
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 Descriptions and Relationships, 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.
Resource format
A concept resource without any expanded properties looks like the following:
Properties
The resource includes all RF2 properties that are defined in SNOMED International's Release File Specification:
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 destinationId
s 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
A descriptive key for the concept's icon. The icon identifier typically corresponds to the lowercase, underscore-separated form of the hierarchy tag 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):
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
Currently unsupported. Indicates whether a parent concept's direct descendants form a disjoint union 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.
The default value is NON_DISJOINT_SUBCLASSES
where no such assumption is made.
Property expansion
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,
expand
s 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()
referenceSet()
Expands reference set metadata and content, available on identifier concepts.
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:
Note that the response object for property referenceSet
can also be retrieved directly using the Reference Sets API.
To retrieve reference set members along with the reference set in a single request, use a nested expand
property named members
:
Reference set members can also be fetched via the SNOMED CT Reference Set Member API.
preferredDescriptions()
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()
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()
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()
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).
Reference set members can also be fetched in a "standalone" fashion via the SNOMED CT Reference Set Member API.
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.
Allowed reference set type constants are (these are described in the Reference Set Types section of SNOMED International's "Reference Sets Practical Guide" and the Reference Set Types section of "Release File Specification" in more detail):
SIMPLE
- simple typeSIMPLE_MAP
- simple map typeLANGUAGE
- language typeATTRIBUTE_VALUE
- attribute-value typeQUERY
- query specification typeCOMPLEX_MAP
- complex map typeDESCRIPTION_TYPE
- description typeCONCRETE_DATA_TYPE
- concrete data type (vendor extension for representing concrete values in Snow Owl)ASSOCIATION
- association typeMODULE_DEPENDENCY
- module dependency typeEXTENDED_MAP
- extended map typeSIMPLE_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 typeOWL_ONTOLOGY
- OWL ontology declaration typeMRCM_DOMAIN
- MRCM domain typeMRCM_ATTRIBUTE_DOMAIN
- MRCM attribute domain typeMRCM_ATTRIBUTE_RANGE
- MRCM attribute range typeMRCM_MODULE_SCOPE
- MRCM module scope typeANNOTATION
- annotation typeCOMPLEX_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()
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()
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()
pt()
and fsn()
Expands the Preferred Term (PT for short) and the Fully Specified Name (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 Accept-Language request header, which clients can use to supply a list of locales in order of preference.
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()
descriptions()
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 SNOMED CT Description API.
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}"
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 Synonyms will be expanded.
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()
relationships()
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 SNOMED CT Relationship API.
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()
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.
The same set of options are supported within inboundRelationships
as in relationships
(see above), with three important differences:
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()
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()
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.
Operations
Read concept (GET)
A GET request that includes a concept identifier as its last path parameter will return information about the concept in question:
Query parameters
expand={options}
Concept properties that should be returned along with the original request, as part of the concept resource. See available options in section Property expansion above.
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 ofancestorIds
as welldefinitionStatusId
doi
effectiveTime
exhaustive
iconId
id
- always included in the response, even when not present as afield
parametermapTargetComponentType
memberOf
moduleId
namespace
parents
- controls the appearance ofparentIds
as wellpreferredDescriptions
refSetType
referencedComponentType
released
score
semanticTags
statedAncestors
- controls the appearance ofstatedAncestorIds
as wellstatedParents
- controls the appearance ofstatedParentIds
as well
andcreated
- these fields are associated with revision control, and even though they are listed as supported fields, they do not appear in the response even when explicitly requested.revised
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.
Request headers
Accept-Language: {language-range}[;q={weight}](, {language-range}[;q={weight}])*
Controls the logic behind Preferred Term and Fully Specified Name selection for the concept. See the documentation for expand options pt() and fsn() for details.
Specifying an unknown language or dialect results in a 400 Bad Request
response:
Find concepts (GET)
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:
Query parameters
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}
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 inferred view, based on the currently persisted inferred relationships.
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}
Same as ecl
, but the input expression is evaluated over the stated view by using stated relationships (if present) and OWL axioms for evaluation.
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}]*
The SCTID of matching concepts must have the specified 7-digit namespace identifier, 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.
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.
Field names supported for sorting are the same that are used for field selection; please see above for the complete list.
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: