Overview
Table 5.1.1-1 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.
| Requirement | Priority | ||
|---|---|---|---|
| Expression forms | Close-to-user form expression | The expression repository must store the expression as it was entered by the user | 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 | |
| Identification | Expression id | The expression repository should store a unique identifier that can provide an easy reference to the expression | Optional |
| Versioning | 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 | |
Table 5.1.1-1: Expression repository requirements.
Requirements
Expression Forms
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
- 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
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.
Identification
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.
Versioning
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.
Effective Time
For each version of an expression, the date should be recorded to enable the lookup of an expression for a particular point in time.
Substrate
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 SNOMED CT URI Standard 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.
Feedback
Overview
Content Tools
Apps