With this approach, the full expression is stored in a single field, in the same way as the storage of single concept identifiers.
The following image illustrates the principle of storing the full expression in the expression repository.
The canonical version of the compositional grammar expression is recommended for the storage of the full expression, because this has a minimum of syntactic noise and specified sort order for the elements within the expression.
To use this approach, the health record must be able to record codes that are as long as the longest expression linked to one of the interface terms. The codes must also allow non-numeric values to be included, such as the colon and equal signs that are used in most expressions.
Some clinical systems, however, may have limits on the length or datatype of the codes that may be recorded in their health records. So, in these cases, a unique local identifier can be assigned to each expression, so that this shorter expression id can be stored in the health record in the place of the full expression (see Store Expression Identifier).
Terminology services
Storing the full expression in the EHR record requires the EHR to ensure that the stored expression represents a valid SNOMED CT expression. For this purpose, the following services may be required:
Validate and Transform Expression (note, that for this purpose the CTU expression form of the expression should be used for data storage )
In conjunction to the EHR data storage, this process may also require the expression being added to an expression repository, which require the following services
Lookup Expression
Add Expression
Storing Patient Data using Expressions
When implementing postcoordinated SNOMED CT expressions, there are different approaches to storage that may be considered.
These approaches are described in the following pages.
In some cases, it may be preferred or required to use a single identifier to represent the stored expression. With this approach, a unique local identifier is assigned to each expression, so that this can be stored in the health record in the place of the full expression. This approach may be selected if the clinical system has a limit on the length of the codes that are recorded in their health records.
When local expression identifiers are used, these are then linked to the corresponding full expression and display term within an Expression Repository, as illustrated in the image below.
Terminology services
Storing an expression identifier requires the expression to first be added to the expression repository, and assigned a unique identifier. The resulting identifier will be stored in the EHR data store. For this purpose, the following services may be required:
Add Expression. This is only required in cases where the expression does not already exist in the expression repository.
When clinical data is entered in an EHR using a number of interconnected data elements, the composition of the individual data items may derive a postcoordinated expression. This is exemplified in the image below where three data entry controls are used to form the clinical meaning of "an excision of the appendix structure", see the image below.
With this approach, it is recommended to store the data in an information structure that matches the fields on the form and to record the concept identifier and display term for each of the fields, within that information structure. This enables the system to efficiently display health records that have been recorded previously, and also provides full traceability of what the user selected at the point of data entry.
Aside from storing the individual data items, the associated postcoordinated expression may also be generated using an expression template and stored, if this is needed for other EHR tasks. The principle of this approach is illustrated in the diagram below where the derived expression represents the combined meaning of the selected values. In this example, the concept id for | surgical procedure| replaces the @procedure slot in the expression template. The concept id of | Appendix| replaces the @site slot, and the concept id for | Excision| replaces the @method slot.
The benefit of this approach is that changes to the modelling of a particular branch in SNOMED CT will only require an update to the applied expression, instead of every single expression.
Some implementations may choose to store this derived expression, in addition to the individual values of each field, to support run-time querying or exchange.
