Terminology Services 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.
Summary
Create expression repository
Creates a new repository
- substrate : the base edition for this repository
- languages (0-*): pairs of language refsetIds + language codes used to generate descriptions (optional)
Success: True, with identifier of the generated repository
Failure: False, with appropriate error message
Get Details of an Expression Repository
Objective
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.
Summary
Get details about an expression repository
Gets details of a repository
- substrate: the base edition for this repository
- repId: a unique reference to the expression repository
Success: Return details of the selected expression repository and dependencies
Failure: Return error message
Update Expression Repository
Objective
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.
Description
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
Validate the CTU of all existing expressions against the new substrate
Resolve any validation issues, e.g. by
replacing inactive concepts with proper replacements
adjusting expression to conform to the MRCM
Transform the updated expressions (update the classifiable form expressions)
Classify the expression repository against the new substrate, and where relevant, generate new versions of the necessary normal form
Summary
Update expression repository
Creates a new version of a specific repository
- substrate : the new base edition for this repository
- repId : identifier of the repository to be updated
- languages (0-*): pairs of language refsetIds + language codes used to generate descriptions (optional)
Success: True
Failure: False, with appropriate error message
Add Expression
Objective
The objective of the services described in this page is to enable the addition of a new expression in the expression repository.
Description
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.
Workflow
The logical process of the add expression service is illustrated in the diagram below.
Summary
Add expression
Adds a new postcoordinated expression to the expression repository
- substrate: the base edition for this repository
- repId: a unique reference to the expression repository - CTU: Close to user form expression
Success: Return data associated with the expression
Expression identifier, if generated
CTU expression
CF expression, if generated
NNF relationships, if generated
Failure: "Expression not added" plus an indication of the reason (e.g. transformation issue, classification issue, term generation issue)
Validate and Transform Expression
Objective
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.
Description
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.
Syntactic Validation
The syntactic validation is performed to determine if the expression conforms to the SNOMED CT compositional grammar syntax (see Compositional Grammar - Specification and Guide section Parsing).
Please refer to the Compositional Grammar - Specification and Guide (section Validating) for more details on the validation of expression, and the Machine Readable Concept Model for details on the computer processable concept model rules.
Content Validation
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.
MRCM Validation
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
Transformation
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 Implementation
Workflow
The logical process of the service to transform and validate an expression is illustrated in the diagram below.
Summary
Validate and transform expression
Check that the CTU is syntactically valid and conforms to the concept model rules, or allowed rules for postcoordination. Transforms the close-to-user form expression to a classifiable form
- id: a unique reference to the expression repository - expId: CTU expression or expression id
Success: True
Failure: False, with validation error indication
Generate Necessary Normal Form
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
Generate NNF
Classifies the expression (CF) and generates the necessary normal form of the expression
- repId: a unique reference to the expression repository - CF: Classifiable form
Success: As a minimum, returns the necessary normal form of the expression
Failure: Display an appropriate error message
Lookup Expression
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
Search Expression
Objective
The objective of this service is to enable text-based searching for expressions in the expression repository.
Description
As specified in Expression Repository Requirements, 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, see Get 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
Search for expression
Find expression by term
- repId: a unique reference to the expression repository
- Search string
- Search technique option (if required)
- Search filtering or sorting options (if supported)
Success: A collection of matching terms each of which is linked to an expression within the expression repository.
Display term (generated)
Expression identifier
Failure: Return an appropriate error message
Get Display Term
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.
Replace concept identifiers with terms
Apply simple term rules
Apply description templates and rules
Please refer to Appendix A: Techniques for Autogenerating Display Terms for details on these approaches. Please note that alternative approaches may be equally valid for this task.
Summary
Get term for expression
Gets an autogenerated term for the expression using the technique supported by the terminology server
- substrate: the base edition for this repository- id: a unique reference to the expression repository
- expression: a unique reference to the expression
- technique: if multiple techniques for generating terms exist, the technique to apply may be indicated
Success: Return the generated display term(s)Failure: Display an appropriate error message
Query Expression
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 Service Requirements.
Summary
Query expression
Subsumption - check if there is a subsumption relationship between two expressions
- repId: a unique reference to the expression repository
- source: CTU expression, expression id, or concept id
- target: CTU expression, expression id, or concept id
Success: Return data to inform which of the following outcomes are true:
Source is a subtype of target
Target is a subtype of source
No subsumption relationship between source and target
Failure: Display an appropriate error message
Query expression
Get concepts and expressions that conform to an expression constraint
- repId: a unique reference to the expression repository
- ecl: an expression constraint complying to the Expression Constraint Language
Success: Return a set of conceptIds and CTU expressions that conform to the expression constraintOptionally additional information such as the fully specified name or preferred term of each concept included in the expansion plus generated terms for included expressionsFailure: Return error message if expression constraint contains syntax errorsReturn error message if any concept identifiers in the expression constraint are not present in the specified edition
Last updated