With this approach, using an expression template can help to ensure that the selected values are added in the appropriate places within the expression.

The example shown in the image below illustrates how an expression template is used to apply a laterality to a selected diagnosis. In this example, if a user enters the values Open fracture of radius as the diagnosis, and the value left in the side field, the values entered are then used to populate the slots in the expression template and form an expression representing the meaning of an 'open fracture of radius with a laterality of left'.

Expression templates associated with a data entry form should be created during the design phase of the implementation, and then populated with values at run time, when the user selects values in each field. Please see section /expression template https://github.com/SNOMED-Documents/snomed-postcoordination-guide/blob/main/4-expressions-in-the-ehr/4.1-preparing-expression-repository/4.1.3-creating-expressions.md#id-4.1.3.3-expression-templatesfor details on expression templates.

When using the form-based approach for entering postcoordinated expressions in an EHR, 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. It also enables the possibility of re-generating a postcoordinated expression at a later date that is potentially different from that which was originally generated, e.g. if an error were found in the original template or if structural changes in SNOMED force a redesign of the expression template.

In addition to the storage of the individual concept identifiers, the derived expression (in terse form) may also be stored to meet specific EHR-requirements. Generating the derived expression may be done using an expression template.

Terminology services

Enabling form-based entry of expressions in the EHR requires the EHR to dynamically access at runtime SNOMED CT concepts as determined by the terminology binding specified for each data element. At the point of data entry, no specific services for postcoordination are required, however, if the resulting expression is stored as a single expression, or subsequently communicated, terminology services are required to add the expression to the expression repository. For this purpose, the following services are required:

• (including required sub-services)

When enabling postcoordination in an EHR, it is important to be aware of how the approach selected for entry of the expression impacts the storage and the display of the expression.

There are three main approaches to entering postcoordinated clinical data into an electronic health record.

• Prepopulated expressions

• Form-based selection of expression parts

• Free text with Natural Language processing to encode the free text with SNOMED CT

The following pages will elaborate on each of these approaches and clarify key requirements for each. Furthermore, best practice approaches to the storage and display of expressions will also be presented.

The essence of this approach is that the user is presented with a clinical phrase representing a specific clinical meaning, and in the backend of the system, this clinical phrase is associated with a postcoordinated expression (instead of a precoordinated concept).

In the example shown in the image below, the user interface includes a list of phrases such as “Open fracture of left radius”, and “Open fracture of right radius”. Some of these phrases may be associated with precoordinated content (either via mapping or the released SNOMED CT descriptions), while other phrases may be associated with postcoordinated expressions. In this example, the phrase “Open fracture of left radius” and “Open fracture of left ulna” is associated with postcoordinated expressions.

This approach requires the expressions to be created and mapped to an interface term by a SNOMED CT implementer. This occurs as part of the terminology binding process in the design stage of the implementation. Different approaches to the creation of the expressions exist and depend on the tools available. These approaches are described in the following pages.

Using postcoordinated expressions for items in a prepopulated list, or predefined values in a UI, each expression is associated with one field on the user interface. For precoordinated concepts, the best practice is to record the concept identifier as the code, and the term that was displayed or selected by the user as the original text.

The recommended approach to the storage of predefined postcoodinated expressions is similar to the storage of precoordinated concepts. This means that the display term used for the expression should be recorded in the health record, but the ‘code’ should either be the terse form of the full expression (i.e. the expression with the terms and spaces removed), or the unique identifier associated with the expression when this was added to the expression repository.

Terminology services

Enabling prepopulated expressions in the EHR requires the EHR to access expressions already created in the expression repository. For this purpose, the following services may be required:

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

Except where agreed business processes require structured and standardised recording, using free text fields are often a necessity to support the clinical documentation and established work processes. Free text in Electronic Health Records enables the user to enter information using the terms and phrases of his/her own choice.

With this approach, the clinical user enters the information in a dedicated text box, and the text is subsequently analyzed by a natural language processing (NLP) tool. The NLP tool is designed to codify the key terms as SNOMED CT concepts, and the rules specified in the Machine Readable Concept Model (MRCM) may be applied to help identify the relationships between these key terms, to form SNOMED CT expressions.

The image below illustrates how the phrase "The patient has an open fracture of the left radius" is processed by an NLP tool to form the expression:

42945005 |Open fracture of radius| : 272741003 |Laterality| = 7771000 |Left| . 

With this approach, the expressions are usually created at run-time, as the user types in the free text. This requires the system to incorporate a SNOMED CT- enabled NLP service that works in the local dialect.

Using the free-text approach with an NLP tool to generate the expressions, it is recommended, and often required for medicolegal reasons, to store both the free text as it was entered by the user, and also the coded expression that was generated by the NLP tool and confirmed by the user. You should also store the terms associated with the expression that was displayed to the user when they confirmed that it accurately reflects the meaning of the free text.

Terminology services

Enabling NLP with expressions in the EHR requires the EHR to add newly created expressions derived from the NLP algorithm. For this purpose, the following services may be required:

• Lookup Expression

• Add Expression

• Get Display Term. This may be required to display a human readable representation of the generated expression, to enable the end-user to confirm the result of the NLP analysis.

So, in this approach the expressions are usually created at run-time, as the user types in the free text. This requires the system to incorporate a SNOMED CT enabled NLP service that works in the local dialect. So, in this approach the expressions are usually created at run-time, as the user types in the free text. This requires the system to incorporate a SNOMED CT enabled NLP service that works in the local dialect.

When postcoordinated expressions are used to represent clinical information, this data needs to be queried and analyzed in the same way as data recorded using precoordinated concepts.

Systems supporting postcoordination should thus ensure that analytics features are enabled to take advantage of SNOMED CT's hierarchy and explicit representation of defining properties. Furthermore, this facility should allow queries to be generated that combine SNOMED CT-specific selection criteria with other health record criteria.

Key analytics features that should be supported include:

• Subsumption which involves the determination of whether one concept (or expression) is a kind of another concept (or expression) is the fundamental capability enabled by SNOMED CT. For example, answering the question 'Which patients have an infectious disease?' involves finding all the patients with any kind of infectious disease (e.g. viral pneumonia, tuberculosis).

• Selective retrieval which involves using the properties (relationships) derived from classification to retrieve concepts (or expressions) matching specified criteria.

Subsumption testing between expressions tests to see if the candidate expression (often recorded in a patient record) is subsumed by a predicate expression (typically part of the query being run across the patient record). To enable subsumption testing it is necessary to ensure that the expression is processed in the same way as the precoordinated content. This requires the expression to be positioned in the right coordinates of the SNOMED CT hierarchy (aka coordinated), as illustrated in the diagram below.

Subsumption testing may be performed to test if this expression is a subtype of the concept . This test could be required to identify a cohort of patients who have been diagnosed with some kind of lump in a body structure.

However, to enable systems to perform this test, the expression first needs to be classified with the precoordinated content to generate an inferred subtype hierarchy including both the postcoordinated expression and the query concept. If a classification is not performed, the software will not be able to automatically derive where the expression belongs in the SNOMED CT hierarchy relative to the query concept.

As illustrated in the image below, the candidate expression is subsumed by the predicate expression.

Systems supporting postcoordination should provide a mechanism to allow users to specify retrieval requirements based on the inferred properties of an expression. Attribute relationships in conjunction with the subtype hierarchies provide an efficient mechanism for specifying query criteria, e.g. a query for "all diseases with a of and an of ". As illustrated in the diagram below, the inferred properties can be used to identify the concepts and expressions matching these query criteria. However, as for subsumption testing, this kind of query feature demands for the expressions to be classified with the precoordinated concepts in order for the expressions to infer all necessary properties correctly.

Enabling queries over expressions to be performed requires the availability of the following terminology services:

• Query Expression - Including both services to perform subsumption testing and selective retrieval of expressions

This part of the guide describes one way in which postcoordination might be applied in an EHR. This involves introducing the steps involved with setting up an expression repository, including approaches taken to create and add expressions to the repository.

This section also introduces how postcoordination can be implemented to support essential EHR tasks including entering, storing, displaying, querying, and communicating expressions. In addition, references to the terminology services required to support these approaches will be provided to function as a practical source of reference for implementers wishing to enable postcoordination in their EHR.

Storing Patient Data using Expressions

When implementing postcoordinated SNOMED CT expressions, there are different approaches to storage that may be considered.

• Store the full expression in the same way as you would store any coded data item

• Reference the expression in the record storage using a local expression identifier, and hold the expressions in a separate expression repository

• Store the expression parts individually in separate fields

These approaches are described in the following pages.

The main options for sharing postcoordinated expressions are:

• To exchange the terse expression as the ‘code’ of the relevant field, with the displayed or auto-generated term.

  • For example, the HL7 version 3 CD data type (Release 2) allows the 'code' property to include SNOMED CT expressions (see HL7 TermInfo guide).

  • Within the coding also include a precoordinated concept, for systems that can not process expressions. This should be the proximal inferred parent concept of the expression.

  • This option is shown in the example below.

• To decompose the expression into separate fields - one for a focus concept and then one for each of the attribute values in the expression.

  • In each field, the concept identifier may be used as the code, and one of the synonyms as the display text.

  • This approach assumes alignment between the message structure and the relevant parts of the SNOMED CT concept model.

• To use an expression identifier from your expression repository as the ‘code’, with the display term.

  • This approach requires the use of a shared expression repository enabling the recipient system to look up and resolve this identified to the relevant expression.

Example: A FHIR Resource including a postcoordinated expression

Terminology services

Enabling expressions to be included in communication messages requires:

• Lookup Expression. This will be used to get either the CTU form of the expression or the expression identifier to be included as the code for the coded data element in the message

• Get Display Term. This is required in cases where a single display term is required for the expression, and this approach is acceptable in the given setting.

The approach to the display of postcoordinated expressions will depend on how they are created, stored, and exchanged.

But the general recommendation is to display the expressions in the same way as they were entered or confirmed by the user. For example, if the expression has been constructed from the selections made in a form, the display of the expression would involve rendering the selected terms with an indication of the context in which the value was selected. Some situations may, however, require a single term to be constructed for an expression, e.g. to support data exchange.

The following pages introduce general approaches to the creation of display terms for postcoordinated expressions.

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:

• Lookup Expression - to get the identifier of the expression to be stored.

• Add Expression. This is only required in cases where the expression does not already exist in the expression repository.

Automatic Creation of Display Terms

Use Cases

Some situations may require expressions to be displayed differently from how they were created. For example

• Communication and display of expressions

  • When the information structures used to create the expression are different to those available for display or exchange

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 replaces the @procedure slot in the expression template. The concept id of replaces the @site slot, and the concept id for 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.

Enabling postcoordination in an EHR may involve the preparation of an expression repository. This involves the actual creation of the expression repository and often the addition of a set of postcoordinated expressions to be included in the value sets of the EHR.

Creating and Expression Repository

To enable expressions to be stored and accessed in the terminology server, the expression repository first needs to be created.

A SNOMED CT-enabled expression repository is not a standalone artifact. The expression repository is tightly coupled with the terminology repository in the sense that all expressions represented in the expression repository are composed of concepts included in the applied terminology repository, i.e. a specific version of a SNOMED CT Edition. The terminology content on which the expression repository depends is also referred to as the substrate. When a terminology repository is updated to include a new version of SNOMED CT, the expression repository will equally need to be updated to align with the applied terminology content.

Adding Expressions to Repository

Depending on the choices made as part of a SNOMED CT implementation project, the addition of expressions to an expression repository may be done at various stages of implementation and by different users. For example:

• Some implementations may restrict the creation of expressions to only during the implementation stage, where

  • Expressions are created by people involved with the implementation

  • Expressions are added to the expression repository to be made available for end users in the same way as precoordinated SNOMED CT content. By this approach, the end users can not themselves directly create new postcoordinated expressions

• Some implementations may enable runtime creation of postcoordinated expressions by end users, where

  • Expressions are created by end-users as part of the data entry process

  • Expressions are added to the expression repository as part of saving patient data in the EHR record store.

Manual Creation of Display Terms

When a postcoordinated expression is created during the implementation process, this may involve the manual creation of a display term for each expression. Two scenarios for the manual creation of display terms can be outlined:

1. The list of clinical phrases is developed first, based on user requirements or an existing library of clinical phrases, and then these will be mapped to SNOMED expressions

2. A set of postcoordinated expressions are created first to represent the clinical meanings that are required, and a display term is created for each expression

   1. This approach may be assisted by Natural Language Generation technologies and techniques to automatically suggest appropriate terms for each expression

The challenge associated with the creation of terms for expressions is that the meaning represented in the term may differ from the meaning of the expression itself. This deviation may arise due to limitation of the concept model or implementation constraints. Implementers should, therefore, consider if they want to support the creation of terms for expressions and in which case they should implement a process to assure the quality of the created terms.

The goal of assigning a term to an expression is to select a term that is an accurate synonym for the meaning conveyed by the expression, ensuring semantic equivalence between the two. If the display term does not fully capture the meaning expressed in the expression, the expression should be labeled as a primitive ('<<<') to indicate that some aspects of the term's semantics are not reflected in the expression.

To avoid inconsistency between the display term and the expression, the recommended approach for providing a human-readable term for an expression is to automatically generate a display term. This approach, even though it may require human validation, ensures that the terms used in the display term are derived from terms approved as part of the authoring of the concepts referred to by the expression.