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🌎:
ideffectiveTimeactivemoduleIddefinitionStatusId
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
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:
propertyNameNstands for the property to expand;optionN: valueNare 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()
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:
activeactiveMemberOfancestors- controls the appearance ofancestorIdsas welldefinitionStatusIddoieffectiveTimeexhaustiveiconIdid- always included in the response, even when not present as afieldparametermapTargetComponentTypememberOfmoduleIdnamespaceparents- controls the appearance ofparentIdsas wellpreferredDescriptionsrefSetTypereferencedComponentTypereleasedscoresemanticTagsstatedAncestors- controls the appearance ofstatedAncestorIdsas wellstatedParents- controls the appearance ofstatedParentIdsas wellcreatedrevised
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:
The process can be repeated until the items array turns up empty, indicating that there are no more pages to return.
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 point-in-time path parameter should be used in consecutive search requests.
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. See above for the list of supported field names.
Request headers
Accept-Language: {language-range}[;q={weight}](, {language-range}[;q={weight}])*
Controls the logic behind Preferred Term and Fully Specified Name selection for returned concepts. See the documentation for expand options pt() and fsn() for details.
Find concepts (POST)
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:
Request headers
Accept-Language: {language-range}[;q={weight}](, {language-range}[;q={weight}])*
Controls the logic behind Preferred Term and Fully Specified Name selection for returned concepts. See the documentation for expand options pt() and fsn() for details.
Create concept (POST)
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
idproperty 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
idunset and populatingnamespaceIdwith the expected namespace identifier, eg."1000154". Requests usingnamespaceIdshould 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.
Request headers
X-Author: {author_id}
Changes the author recorded in the commit message from the authenticated user (default) to the specified user.
Update concept (PUT)
PUT requests to locations that identify a concept resource (same as when retrieving 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.
The following properties can be updated on any component. If they are not included in the request, the corresponding component property remains unchanged.
moduleId: stringactive: booleaneffectiveTime: string (inYYYYmmdd, "short" format)
When inactivating🌎 a concept, an object named inactivationProperties can be added that can point to possible replacement concepts and/or specify the reason for inactivation:
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: stringsubclassDefinitionStatus: "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:
descriptionsrelationshipsmembers
Each of the above can hold a collection resource of the respective component resource type. These resources are described in detail in sections Descriptions, Relationships and Reference set members, respectively.
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.
Query parameters
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.
Request headers
X-Author: {author_id}
Changes the author recorded in the commit message from the authenticated user (default) to the specified user.
Delete concept (DELETE)
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.
Query parameters
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.
Request headers
X-Author: {author_id}
Changes the author recorded in the commit message from the authenticated user (default) to the specified user.
Last updated
