Got it — here’s the GitBook-ready version with no section or table numbering, fully cleaned up for a smooth read.

Overview

\

SNOMED CT release files include data that allows tracking of all changes between different versions of any edition of the terminology.

\

In addition to a unique id, each row in every release file includes:

• effectiveTime – the date when the row became the effective version of that component or reference set member, either as a new component or a revision of the previous version.

• active – indicates whether the component is still intended for active use.

• moduleId – identifies the module that the component belongs to. A change to the moduleId indicates that a component has been moved to a different module, which may be:

  • another module maintained by the same organization, or

  • a module maintained by a different organization.

Before updating to a newer SNOMED CT version, it is essential to:

• Identify the inactivation of any concepts and descriptions used in:

  • data entry templates

  • picklists

  • reporting and analytics queries

This section focuses on services that identify and categorize these changes. Additional services that provide more detail about some changes are described later in Get History Data.

To identify changes, terminology services must be able to:

• Identify components and reference set members in the full release of the new version with an effectiveTime greater than the date of the previously installed version.

• For each identified component:

  • Check active status in the updated release (active or inactive).

  • Check whether it existed in the previous release and, if so, its status there (active, inactive, or none).

• Other Services

• Use Cases

• (including support for selecting two versions for comparison)

The Snowstorm and FHIR examples are presented in plain text and URL encoded versions. Always use the "Encoded URL" when testing the example service requests. The plain text version is included to aid readability but using this version in a service request may result in errors. These errors result from characters that have to be encoded as they are not permitted in a URL (see ).

FHIR API

Notes

• The significance of changes to membership of reference sets depends on the extent to which they are used by a particular application. For example, a change to language reference set membership may mean that a description is no longer acceptable in the language or dialect used in by an application. Similarly, a change to a the membership of a simple reference set used to constrain a searches, reports or analytics may alter the results of those actions.

• A delta release file may be available to provide information about changes since the previous release. However, in cases where an organization does not update the version they are using regularly, there may not be a single set of delta release files covering all the changes made between the version in use and the current version.

• Language and/or dialect should be specified if the service returns terms associated with referenced concepts.

Overview

Finding a specific concept is a fundamental requirement and a prerequisite for most other terminology service. To make practical use of SNOMED CT, users must be able search for concepts using using phrases, words or parts of words. The SNOMED CT Search and Data Entry Guide provides detailed descriptions of these essential search types. It also notes a range of important additional features that facilitate appropriate use of the terminology by constraining searches and appropriately ordering search results. This section does not repeat that detailed discussion of different search techniques. Instead, it focuses on technical and practical requirements for delivering and accessing services that meet those requirements.

Several services described earlier in the guide provide technical ways to constrain searches for concepts to meet particular requirements.

• Get a Concept, Description or Relationship introduced services that find concepts by identifier1.

• Get and Test Concept Subtypes and Supertypes includes consideration of services that find concepts based on subtype relationships to or from other concepts.

• includes services that find concepts that are members of a particular reference set.

• describes the way that the above approaches to finding concepts can be combined.

This section indicates ways in which term searches can and should be combined with those constraints to enable effective searches for concepts relevant to a particular context of use.

High-performance term search services are essential for most practical applications of SNOMED CT. Search services also need to employ effective strategies for rationalizing, sorting and presenting search results in ways that facilitate selection of concepts most frequently used in a given context of use. Term searches are typically language or dialect specific. Therefore requests for searches should include appropriate language codes or language reference set identifiers2.

Section in the Search and Data Entry Guide identifies a range of different search techniques that may be valuable. If a terminology server supports more than on search technique the service request will need to indicate the technique to be used.

In the simplest case a term search service should be able to take a term or phrase typed by a user and return matching results. For this purpose, the recommended default search technique is to search for words or parts of words in any order (see Search and Data Entry Guide ). Searches using this technique should be to return concepts associated with terms that include words that match or begin with all the words or part words in the search string. The order of words need not be the same in the search string and the matched term and the search string need not include all the words in the term.

Specific data storage and development environments also support specific solutions for searching text. These include boolean searches (which require some words to be present and other words to be absent, natural language searches which may include words with similar meanings. In addition to these there are more general pattern matching approaches including the use of wildcard character and searches using regular expressions. While these techniques can be useful, end users should be able to search SNOMED CT effectively without being required to understand a specific technical syntax.

Section in the Search and Data Entry Guide identifies a range of options for filtering and ordering the results of a search. Filtering options include avoiding displaying multiple matching terms that refer to the same concept as well as ensuring that by default descriptions associated with inactive concept are not displayed (though there should be an option to include inactive concepts as these may be relevant to historical data). Ordering options include displaying the closest matches, shortest matching terms or most commonly used concepts at the top of the list of results.

Many practical use cases are best addressed by applying term searches to a constrained set of concepts. Searches that are appropriately constrained result in shorter lists of matching results and thus make it easier for a user to find the required concept. Constrained searches also reduce the risk of inadvertently selecting a concept in a hierarchy that is not appropriate to the data entry context. Thus this technique simplifies data entry and leads to improvements in data quality.

Example

Searching the entire content of SNOMED CT when looking for a diagnosis or reason for admission is likely to include many concepts that are are not valid diagnoses or reasons for admission. This can make if difficult for the user to find the concept that they need and, in some case, may lead to recording of concepts that have terms that do not represent the intended meaning. Examples of errors arising from failing to constrain searches include recording the names of substances and morphological abnormality rather than the name of symptom or disorder. The results of such errors can result in errors in reporting, analysis and decision support even in cases where the selected term may appear to capture the required meaning.

The recommended approach to constrained searches is to use expression constraints to specify the constraints. Ideally, the service should implement all the features of (ECL). However, even if the service does not support some of the more advanced features, it should enable use of ECL to represent and combine subtype tests and reference set membership tests.

Services that do not support ECL should as a minimum support constraints based on reference set membership and the position of the concept in the subtype hierarchy. The recommended approach to testing the location of a concept in the hierarchy is the use of subtype tests. However, if these tests are not supported, a more limited approach that filters search results by hierarchy tags may be used.

• Other Services

• Use Cases

Notes

It should never be necessary for an end-user to enter a concept identifier. However, there are practical situations in which concept identifiers may be available to be used to find a specific concept or set of concepts. These situations include coded data in existing records or messages; templates, pick lists and other user interface controls that are bound to specific concept identifiers. If concept identifiers are available they provide a direct way to find data about specific concepts.

One or more languages and/or dialects should be specified for searches. If more than one language or dialect is specified, the search should return matching terms that are acceptable in any specified language or dialect.

The nature of the search string may vary according the search techniques supported and any options selected (see ).

The search technique needs to be specified if the service supports different techniques (see ).

If the service supports alternative ways of filtering or ordering results, these options chosen need to be specified (see ).

As noted in , the use of expression constraints is recommended. However, other representations of constraints may be used if the service does not support expression constraint language.

In the Snowstorm service requests [snowstorm] should be replaced by the URL to the Snowstorm server endpoint.

In the FHIR service requests [fhir] should be replaced by the URL to the FHIR terminology server endpoint. FHIR® is a registered trademarks of ().

The SNOMED CT MySQL example database is not designed as a terminology server and is not intended for use in a live system. It is referenced in this guide as an illustration that some readers may find helpful. For more information about the SNOMED CT example database see the . For instructions on how to build the example database refer to .

Overview

Editions

Several different SNOMED CT editions are available. All editions include the content of the SNOMED CT International Edition but some also include extensions that contain additional content designed for use in a particular country, region, speciality or organization. Terminology services may support access to more than one edition, so the service must enable the client to select the appropriate edition.

It is important to specify the edition to enable access to national or local terminology content that is not available in other editions. Content specific to an edition may include locally added concepts and additional descriptions that provide terms in a national language or local dialect. An edition may also include additional reference sets representing subsets or maps.

Versions

SNOMED CT editions are maintained with regular updates. Each update to an edition is referred to as a SNOMED CT versioned edition. Terminology services should enable access to more than one edition, so the service must enable the client to select the appropriate version.

It is important to specify the version as each version update adds, changes or inactivates some components and reference set members. Therefore, the result of a terminology service may differ depending on the version.

An organization maintaining a SNOMED CT edition or extension will also have internal development versions and prerelease versions for testing. Therefore, services designed to support terminology development and maintenance also need to enable selection of specific terminology development versions or branches.

SNOMED CT specifications define a full release that represents a complete record of the history of all released components, and a snapshot release type that only represents the state of those components at a specified date.

Some services described in this guide involve checking for changes between versions. Direct support for these services requires two versions to be specified to enable comparison of the before and after state of components that have changed between versions.

Selection of a specified edition, versioned edition or extended versioned edition is a prerequisite for all other terminology services as it determines the terminology substrate to be used when responding to those service requests. The selection process needs to be supported by services that enable the client application to find out information about available editions, versioned editions, and extended versioned editions. The required services are listed in the table below.

For performance reasons, scalable terminology services should be stateless and this rules out prior configuration of a session to work with a particular edition or version. Therefore, all service requests must explicitly identify the edition and version to be accessed.

• Servers that support access to development versions of an edition must enable access to specified development branches as well as versions.

• Servers that provides access to development branches needs to provide a service that identifies the available development branches.

• Terminology services that support comparison between versions (or between development branches), must allow both the versions (or branches) to be specified.

Required By:

• All other terminology services

• All use cases

Explanation: Terminology services depend on the explicit selection of an edition and version (or development branch) to ensure accurate querying, classification, and interpretation of SNOMED CT data.

In minimal implementations (e.g., a server with only a single pre-configured snapshot), version/edition selection may not be an explicit service. Instead, the selection is implicitly determined by the data loaded into the server.

However, more flexible and scalable systems—especially those supporting multiple editions and version comparisons—must expose version selection as a configurable parameter in every request.

Depends On:

• The terminology server must contain data for all versioned editions that may be requested.

Any version of the edition supported by the schema, can be accessed provided the schema was built using the full release files. The most recent version and two earlier versions can be accessed simultaneously by referring to different views (snap1 and snap2). The versions in each of the two earlier views are specified in a configuration file. The version settings for each of these the earlier views can be set to specify the version at any past date.

Queries run on a specific snapshot view return the data as it was at the configured date.

An expression is a structured combination of one or more concept identifiers that represents an idea. Expressions can be used to represent concept definitions. They can also be used to represent meanings that are not currently represented by a concept in the current SNOMED CT release.

When expressions are used, it is necessary to determine whether the meaning of a particular expression is a subtype of a specified concept or more generally is subsumed by a particular expression constraint. The terminology services required are similar to those described for testing concepts in sections and . However, in this case the first step is to determine the meaning of the expression relative to existing defined concepts.

The required services are listed in the table below.

Services Required

Overview

Reference set files provide a standard format for maintaining and distributing a set of references to SNOMED CT components.

Notes

• A reference set can be used to represent a subset of components (concepts, descriptions or relationships).

• A reference set may also associate referenced components with additional information such as:

  • Ordered lists of components

  • Sets of associations between components

  • Mapping between SNOMED CT concepts and other systems codes, classifications, or knowledge resources.

A concept or description is a member of a reference set if that reference set contains an active row with a referencedComponentId matching the id of that concept or description.

Two services are specified in this section. One of these returns the list of members of a specified reference set. The other tests whether a candidate concept or description is a member of a specified reference set.

The union, intersection or complement of two or more reference sets can be determined using the (ECL). Terminology service requirements for accessing expression constraints are described in .

The services listed in the table below can be used to determine whether a concept or description is a member of any identified reference set. These services are primarily applicable to simple reference sets that represent subsets of concepts or descriptions (). Members of other types of reference set contain additional data and services that provide access to this additional data are described in .

• Other Services

• Use Cases

Notes

• The reference set specification should indicate which component types are permitted to be members. The members of some reference sets are concepts while the members of other reference sets are concepts. It is also possible, for some reference sets to contain both concepts and descriptions as members. Services that only return the referencedComponentId do not need to be aware of the types of component in the reference set. However, if a service returns terms or other additional data, the service must take account of the component type.

• The value TRUE may be represented in a variety of ways. For example: as a Boolean value, as a non-zero count of matching members or by a data object representation of the candidate component. Similarly the value FALSE may be represented by a Boolean, by a zero count, or by an empty or null returned object.

• In the Snowstorm service requests [snowstorm] should be replaced by the URL to the Snowstorm server endpoint.

Each SNOMED CT concept has a concept definition.

A concept definition is a set of one or more axioms that partially or sufficiently specify the meaning of a SNOMED CT concept.

The table below describes several distinct types of access to concept definitions and the client application functionalities that each of these access types supports.

General purpose terminology services that are able to access subtype relationships relationships can be used to meet a limited set of SNOMED CT use cases. However, SNOMED CT terminology services should also provide access to the inferred view of concept definitions.

Advanced SNOMED CT terminology services require the ability to access and interpret the axioms that represent the stated view of concept definitions. They should also enable description logic classification either as a built in service or via an interface to separate classifier. Services that support classification provide added value for data retrieval and analysis by enabling post-coordinated expressions to be classified and appropriately located in the subtype hierarchy.

The required services listed in the table below omit services that only require access to subtype relationships, as these are described in .

Overview

Each concept is associated with descriptions. Each description is an association between a human-readable phrase (term) and a particular SNOMED CT concept.

There are different types of descriptions and there may be descriptions of each of the following types in several languages:

• A synonym is a word or phrase that expresses the meaning of a SNOMED CT concept in a specified language.

  • Synonyms are terms that represent the meaning of the concept in a way that is familiar and readily understandable. However, when taken out of context a synonym may not be unambiguous and in some cases the same term may be associated with more than one concept.

  • Each concept has at least one synonym and a concepts may have several synonyms. One of the synonym descriptions in each language is marked as the preferred term for the associated concept and others may be marked as acceptable for use. The preferred term is the term deemed to be the most clinically appropriate way of expressing a concept in specified language context.

• A fully specified name is a description that represents the meaning of a concept in a way that is unambiguous and independent of the context in which it is used.

  • Fully specified names are essential for disambiguation of the meaning of a concept. These term used in the fully specified name includes a hierarchy tag that specifies the branch of the SNOMED CT hierarchy the concept is in. The hierarchy tag is enclosed in brackets at the end of the term.

  • There is only one fully specified name in each language. In some languages there may not be a fully specified name, in which case the English fully specified name may be used where necessary for disambiguation.

• A text definition is a narrative text explanation of the meaning of a concept that may exceed the maximum permitted length for a fully specified name.

  • Text definitions are only included for some concepts where longer terms are deemed to be necessary or useful to add clarity to the meaning of the concept.

Terminology services must enable access to the term in each active description associated with an identified concept. They should also be able to selectively filter the descriptions for which terms are returned based on the following criteria:

• Active status (description.active)

  • Inactive descriptions associated with a concept should not be returned unless explicitly requested.

• Description type (description.typeId)

  • Fully specified name

The required services are listed in the table below.

• Use Cases

• Service Types

A concept definition is a set of one or more axioms that partially or sufficiently specify the meaning of a SNOMED CT concept.

Concept definitions must conform to the SNOMED CT Concept Model as specified by the machine readable concept model. A concept with a definition that does not conform to the concept model cannot be accurately classified.

• Terminology services supporting SNOMED CT authoring must validate concept definitions based on concept model rules.

• Services only for terminology use do not need to meet this requirement.

An expression is a structured combination of one or more concept identifiers that represents an idea.

The inferred definition of each concept includes a set of one or more subtype relationships relationships.

A subtype relationship is a relationship that asserts that a concept is a subtype of another concept.

• Subtype relationships are represented by relationship type .

• A subtype relationship asserts that a concept conforms to all the defining characteristics the supertype concept but also has at least one feature or refinement that distinguishes it from that concept.

An expression constraint is A computable rule that is used to define a set of clinical meanings.

• SNOMED CT expression constraints are defined using the expression constraint language (ECL).

• Expression constraints can be used for a variety of purposes including:

  • Specifying value set bindings that constrain the values that can be entered in a particular data entry context.

Overview

Reference set files provide a standard format for maintaining and distributing a set of references to SNOMED CT components.

Notes

• A reference set can be used to represent a subset of components (concepts, descriptions or relationships).

• A reference set may also associate referenced components with additional information such as:

  • Ordered lists of components

  • Sets of associations between components

  • Mapping between SNOMED CT concepts and other systems codes, classifications, or knowledge resources.

The services required to identify the members of a reference set are described in Section . This section describes general requirements for services that are able to access additional data stored in reference sets.

The following services, described in earlier sections, require access to a single data value from each reference set row:

• requires access to the acceptabilityId in a to determine the preferred and acceptable terms for a concept in a specified language or dialect.

• requires access to the owlExpression in the to get the stated view of a concept definition.

The following services described in the next few sections, require access to one or more data values from each reference set row:

• uses historical reference set data to determine the reason for inactivation and to identify related active concepts.

• uses mapping reference set data to access maps to or from SNOMED CT concepts or expressions.

• uses MRCM reference set data to access concept model domain, attribute and range related rules.

Other reference set types that are not specifically documented in this section of the guide also contain additional data to which a client application may require access. Furthermore when new reference sets are introduced, there will be requirements to access additional data items in those reference sets. The service described in this section provides a general solution by providing access to all additional data associated with a reference set member in any type of reference set.

• Other Services

  • Get Terms for a Concept

  • Get Definition of a Concept

  • Get History Data

• Select Edition and Version

• Get and Test Reference Set Membership