This page introduces the users, use cases and resulting service requirements for a terminology server supporting postcoordination.
Expression Repository Users
The tables below shows the set of services will enable users interacting with an expression repository to perform required tasks.
Services should be available to support the creation of an expression repository, involving the creation of the structures required to hold the data of the expression repository, as described in . These services are required to provide an 'empty' expression repository.
Services should be available for getting details about a generated expression repository. The details can be used when accessing content of this specific expression repository, e.g. when adding, updating or querying expressions.
Services should be provided to support the addition of new expressions to the expression repository. These services should ensure that all data required to represent and process expressions are available.
Services for adding expressions will often include the services for validating the expression, transforming the expression and generating the necessary normal form.
Services should be provided to support transformation of the close-to-user form expression to a classifiable form which is required to generate the necessary normal form.
Considerations and approaches to transformation are described in .
Services should be available to check if the close-to-user form of the expression is syntactically valid and conforms to the concept model rules, or any allowed rules for postcoordination.
Services should be provided to support the generation of the necessary normal form of the expression, which is a prerequisite for supporting expressions to be queried in the same way as pre-coordinated content.
Considerations and approaches to the generation of the necessary normal form are described in .
Services should be provided to support the updating of expressions while retaining full traceability of previous versions of the expression (similarly to the principles of updating precoordinated SNOMED CT content).
Services should be provided to support the indication that an expression is no longer recommended for use. Although inactivated, the expression should be retained in the repository and full traceability of previous versions (similarly to the principles of inactivating precoordinated SNOMED CT content).
Services should be provided to support access to details about the individual expressions in the repository.
Services should be provided to support searches for expressions in the repository. Lexical searches should be supported based on the terms associated with the concepts included in the expression.
Services should be provided to support a human-readable representation of the expression. This service is required to enable the display of expressions in user interfaces, or to support term searching.
Services should be provided to test the subsumption relationship between a pair of expressions given the semantics of subsumption
Services should be available to enable subsumption testing between expressions and enable the selective retrieval of postcoordinated expressions satisfying stated criteria. Query services should enable queries to be performed over the content of a specific expression repository plus the content of the versioned edition of SNOMED CT that the repository depends on.
Should be able to set up the expression repository when preparing for an implementation
Create expression repository
Should be able to retrieve details about the expression repository to enable referencing the content of this specific expression repository, e.g. for adding and updating content in the expression repository.
Get repository details
Should be able to add expressions to the repository when these are created prior to the implementation within an EHR
Add expression
Should be able to check if an expression constraint conforms to the concept model rules
Validate expression
Should be able to check if expressions exists in the repository, e.g. as part of exploring if new expressions should be created
Lookup expression
Should be able to view the details of each expression in the expression repository
Lookup expression
Should be able to search for expressions using term search
Search for expression
Should be able to retrieve expressions matching specific search criteria, e.g. as part of bulk edit features, expression reviews, etc.
Query expressions
Should be able to update expressions in an expression repository to enable correction of errors or to support updates to a new substrate
Update expression
Should be able to disable or inactivate expressions that are no longer recommended for use
Inactivate expression
Should be able to add expressions to the expression repository, e.g.when the EHR supports runtime creation of expressions using form-based data entry
Add expression
Should be able to see a term for an expression, e.g. when this is rendered as an option in a clinical user interface
Get display term
Should be able to search for expressions using text-based search, e.g. when expressions are included in a value set bound to a search field
Information Manager
This user represents the people involved with the implementation of SNOMED CT-enabled systems and the maintenance of postcoordinated expression repositories
This user group interacts with an Expression Management System, designed to support key tasks required to create and maintain postcoordinated expressions in an expression repository
Clinical user
This user represents the people involved with the entry of clinical data in an EHR system (or another type of clinical information system)
This user represents the people involved with the entry of clinical data in an EHR system (or another type of clinical information system)
Search for expression
Should be able to store expressions in the EHR data store
Add expression
Should be able to share details about an expression, e.g. to support communication and exchange
Lookup expression
Should be able to query expressions in the same way as pre-coordinated concepts to support tasks such as reporting, clinical data analysis and decision support
Query expressions
The table below provides an overview of key requirements for an expression repository. Additional requirements may be relevant for certain use cases, and this overview should, therefore, be used as a minimum set. The definition of the terms used in this table can be found below.
Close-to-user form expression
The expression repository must store the expression as it was entered by the user
The following three expression forms may be supported by the expression repository:
Close-to-user form
The CTU represents the expression as it was entered or created
The CTU is the primary stored and communicated view of the expression
The CTU is immutable, i.e. it will not change even though the repository is updated to new versions of SNOMED CT
When included, the CTU, CF, and NNF should be stored in the expression repository in their canonical form. The canonical form is produced by applying a set of rules to the SNOMED CT expression to ensure a single unique representation of the expression.
The expression repository should support the unique identification of all expressions in the expression repository. The Canonical Close-to-user Form of an expression may be used to identify itself, but some implementations may require the storage of a fixed length, unique identifier for expressions used in an operational environment.
Some clinical systems have a limitation on the number of characters that can be used to identify clinical meanings in their databases. In systems that limit the length of these clinical meaning representations to 18 digits or less, postcoordinated expressions that are longer than this must be stored using a globally unique and unambiguous identifier containing 18 digits or less. A maximum of 18 digits is considered appropriate for this requirement, as this is the maximum length of standard SNOMED CT concept identifier. Therefore, any clinical system which supports SNOMED CT precoordinated concepts must support this number of characters.
The expression repository should support version history. Although there will only ever be one version of the CTU, there is likely to be many versions of the CF and NNF over time. Versioning is therefore required to allow lookup and analysis of previous versions of expressions. This involves the representation of the effective time and the substrate.
For each version of an expression, the date should be recorded to enable the lookup of an expression for a particular point in time.
For each version of the expression, the substrate used to generate the expression should be stored.
The substrate is the SNOMED CT content used for creating the expression. Because medical knowledge is constantly changing, and SNOMED CT evolves to reflect these changes, the concepts used to create an expression may be impacted over time. Therefore, it is important that the substrate is kept current to ensure that the meaning of the expression can be interpreted. With this in mind, both the SNOMED CT edition and the specific version of that edition (released on a given date) need to be included when determining the SNOMED CT substrate for an expression.
The defines a common format of URIs for identifying various SNOMED CT artefacts, including components and RF2 releases. This includes URIs for formally identifying the SNOMED CT international edition, national editions, and any specific versions thereof and can, therefore, be used to represent the substrate for the repository.
Classifiable form
The CF expression is a syntactically valid and concept model compliant representation of the close-to-user form expression
The CF serves as the input to the classifier, enabling expressions to be classified together with other SNOMED CT content
The CF may change when an expression repository is updated to a new version of SNOMED CT
When multiple classifiable forms exists for a CTU, these will be considered as different axioms when generating the NNF
Necessary normal form
The NNF is the output of classifying the CF expression with a given SNOMED edition
The NNF represents the necessary relationships used for querying, so this becomes part of your substrate when you’re running an Expression Constraint query
The NNF includes refinements representing inferred relationships, without any redundant refinements or relationship groups
For each CTU, there will be one NNF
Mandatory
Classifiable form expression
The expression repository should store the expression in a form that can be used as input to the classifier when generating the necessary normal form
Optional
Necessary normal form expression
The expression repository should store the expression in a form that is suitable for querying
Optional
Expression id
The expression repository should store a unique identifier that can provide an easy reference to the expression
Optional
Effective Time
The expression repository must store an effective time for each version of an expression. Although the CTU will never change, the CF and NNF may.
Mandatory
Substrate
The expression repository must include a reference to the SNOMED CT content used to generate the expression.
Mandatory
A terminology server supporting postcoordination should support the general features of a SNOMED CT-enabled terminology server, and additionally, support the features required to manage and use postcoordinated expressions. This involves an expression repository to store the postcoordinated expressions, and a set of services to access, process and query the expressions in the same way as pre-coordinated SNOMED CT content. This section provides an overview of the general requirements of an expression repository and the associated services.