This part of the guide introduces the design features of a terminology server supporting postcoordination with SNOMED CT.

This design meets the requirements outlined in Requirements and includes:

Provide Feedback

The image in this page illustrates an expression repository contains one or more expression versions.Each expression version must contain the following data:

• Versioning data , to represent the time and substrate of the given version of the expression

• A Close-to-user form expression , to represent the expression as it was stated upon creation

Each expression version should contain the following data:

• An expression identifier , if this is required to uniquely identify the expression

• A Classifiable form expression , to enable the generation of the NNF expression

• A Necessary Normal Form expression , to support querying the expression

All SNOMED CT concepts referenced by expressions in the repository at a particular point in time should all be included, and active, in a specific versioned edition of SNOMED CT. General expression repository design.

Interacting with a terminology server is done via a set of supported services designed to meet key user requirements. The following pages provide details about the services required for a terminology server supporting postcoordination. Please note that the services designed to support an expression repository will often be used in conjunction with the services available to access precoordinated content. The general services of a SNOMED CT-enabled terminology server can be found in the Terminology Services Guide.

Create Expression Repository

Objective

The objective of services for creating an expression repository is to set up the structures of the expression repository and provide an 'empty' expression repository.

Description

To set up an expression repository, it requires a terminology server with access to a SNOMED CT versioned edition. This is important because all concepts referenced by an expression must be interpreted in the context of a specific SNOMED CT Edition. To support processing of the expressions, access to information about the source concepts and to the particular version of the MRCM that is encoded within the version of the substrate is needed.

Note the MRCM does not change very frequently: several different consecutive versions of the substrate will contain different sets of concepts and their stated relationships, but may contain essentially the same MRCM content and version.

In addition to specifying the 'substrate' of the expression repository, it is important to specify the primary language, or languages, that should function as the default language for the repository. This is important to support the display of terms associated with the expressions. For the language configuration, it is recommended to specify which language reference set(s), available in the substrate, should be used as the default.

To retrieve details about a generated expression repository. The details of the repository can be used when referring to the content of this specific expression repository, e.g. for adding and updating content in the expression repository.

The objective of a service to update an expression repository is to support the ongoing maintenance and alignment with new versions of SNOMED CT used as the substrate for the expression repository.

Updating an expression repository involves changing the substrate of an expression repository to a new, or another, substrate. Often, the new substrate will be to a new version of the expression repository substrate. Any changes made to the terminology between the SNOMED CT version being the current substrate and the SNOMED CT version that will become the new substrate may impact the content of the expression repository. For example, if a concept included in one of the expressions stored in the repository has been made inactive, the expression is no longer valid after applying the new substrate. Or, if concept model rules stated in the Machine Readable Concept model have been modified, expressions may no longer be concept model compliant.

The services for updating of the expression repository needs, therefore, need to support

1. Validate the CTU of all existing expressions against the new substrate

2. Resolve any validation issues, e.g. by

   1. replacing inactive concepts with proper replacements

   2. adjusting expression to conform to the MRCM

The objective of the services described in this page is to enable the addition of a new expression in the expression repository.

Adding an expression to an expression repository requires the validation of the expression and the storage of the expression as it has been entered by the user with the additional data and expression forms that are needed for subsequent access and use.

The logical process of the add expression service is illustrated in the diagram below.

The objective of this service is to validate a CTU expression and transform it into a classifiable form (CF) which can be used as input to the Description Logic classifier.

This service involves both the validation and transformation of a CTU expression. Three types of validation are required, including syntactic validation, content validation, and MRCM validation. For expressions not fully compliant with the MRCM, a transformation is required to generate the classifiable form.

The syntactic validation is performed to determine if the expression conforms to the SNOMED CT compositional grammar syntax (see section Parsing).

Please refer to the (section Validating) for more details on the validation of expression, and the for details on the computer processable concept model rules.

The content validation is performed to determine if all concept references included in the expression exists and are active in the version and edition of SNOMED CT which is the substrate for the given expression repository.

The MRCM validation is performed to determine if the expression complies to the concept model rules as expressed in the SNOMED CT Concept Model and specified by the machine readable concept model (the version of the MRCM applying to the version and edition of SNOMED CT which is the substrate for the given expression repository)

An expression that does not conform to the concept model cannot be relied upon to correctly classify. Therefore, it cannot be reliably tested for subsumption by another concept or inclusion in (or exclusion from) the results of an expression constraint or analytics query.

Specific terminology services required to support MRCM validation are described in the general Terminology Services Guide here: SNOMED CT concept model

Expressions that are fully compliant with the Machine Readable Concept will not need a transformation to be represented in the classifiable form. This means that for fully MRCM compliant expressions the close-to-user form and the classifiable form of the expression are the same.

An expression may be invalid when tested against the concept model but may contain refinements that would be valid if correctly structured. There are several situations where predictable structural adjustments enable a valid expression to be constructed from an informal expression that does not fully conform to the concept model.

Examples include:

• Moving a loose attribute to an attribute group in which it is valid

• Moving a loose attribute so it provides a nested refinement to the value of another attribute

A loose attribute is an attribute that is included in the refinement of an expression without being placed in a group, although the concept model rules require it to be grouped.

The extent to which a terminology server supports the transformation of non-MRCM compliant expressions into MRCM-compliant expressions may vary between terminology servers. Each terminology server should, therefore, clearly state the level of transformations supported for expressions that are not fully MRCM compliant. A recommended practice for this it to support an API call by which it is possible to determine the transformation level. For more detail on these levels, see

The logical process of the service to transform and validate an expression is illustrated in the diagram below.

Summary

Objective

The objective of this service is to support classification and Necessary Normal Form generation

Related Use Cases

Classification is required to enable the following use case: Query Expressions

Description

To enable postcoordinated expressions to be queried in the same way as pre-coordinated SNOMED CT concepts, the necessary normal form of the expression is required, as illustrated in the diagram below.

Workflow

Summary

Objective

The objective of this service is to get data associated with an identified expression.

Description

Services for retrieving data associated with an expression rely on an input pointing to the expression of interest. For this purpose, a unique identifier associated with the expression within an expression repository should be input to this service. If the CTU of the expression itself is used to uniquely identify the expression, this will be used for the lookup. If multiple versions of the expression exists, the service will return the most recent version of the expression.

Workflow

Objective

The objective of this service is to enable text-based searching for expressions in the expression repository.

Description

As specified in , an expression repository includes the canonical form of the stored expressions. The canonical form excludes any terms associated with the referenced concepts.Consider storing a term associated with the expression to aid searching.Please note that this guide does not include guidance on the storage of a human-readable term for expressions, but it recommends implementing services to automatically generate a display term. Some implementations may choose to store an autogenerated display term for each expression in the repository as part of adding the expression. This may be chosen to support easy lookup of the terms associated with the expressions to support services for searching.

Summary

Objective

The objective of services to get a display term for an expression, is to support the automatic generation of a term that can be used for the human-readable representation of the term, e.g for display or exchange.

Description

Three different approaches to automatically creating display terms for postcoordinated expressions is presented, ranging from the simplest to the most complex.

1. Replace concept identifiers with terms

2. Apply simple term rules

3. Apply description templates and rules

Please refer to for details on these approaches. Please note that alternative approaches may be equally valid for this task.

Summary

Objective

A terminology server should support services that are required for patient- and population-oriented data retrieval and analytics tasks. The objective of expression query services is to enable subsumption testing between expressions and enable selective retrieval of postcoordinated expressions satisfying stated criteria.

Description

Subsumption TestingWhen 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 4.5 Get and Test Concept Subtypes and Supertypes.

Selective Retrieval

As for precoordinated concepts, expressions may be queried based on the inferred properties derived from the classification process. Expression constraints may be formulated and executed against the expression repository and the associated substrate to return both precoordinated concepts and expressions that match the specified constraint, see .

Summary