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.

Overview

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.

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

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.

This chapter provides an introduction to SNOMED CT expressions and covers several aspects related to their representation and use.

It begins by outlining the key differences between pre- and postcoordination, including their relative benefits and limitations. It covers the syntax used to represent expressions, providing a detailed overview of the various expression parts and operators that are used. The chapter introduces the different forms that expressions can take, and it discusses the role of the concept model and editorial guidance required to ensure the accuracy and consistency of expressions.

Provide Feedback

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

These approaches are described in the following pages.

There is a range of use cases in which it may be helpful to use postcoordination, including:

Capture new clinical meanings in a health record, message structure, or query specification

• To support situations where clinicians need to record and share a clinical meaning, which has not been defined in any release of SNOMED CT. This applies to direct data entry, coding values in UIs, or other clinical situations. SNOMED CT postcoordinated expressions can be used to represent a new clinical meaning as an alternative to concept authoring.

Enable interoperability between different structural representations of the same clinical meaning

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.

This guide does not mandate a particular way to meet the requirements and the design of an expression repository as outlined in Requirements and Design. However, to ensure that terminology servers supporting postcoordination are implemented in a way that doesn't compromise terminological integrity and clinical safety, this section presents considerations important for the implementation of an expression repository. Also, different approaches to implementations are be presented.

Ensuring Safety

When implementing a terminology server supporting postcoordination with SNOMED CT, careful considerations must be taken to ensure that the approach taken doesn't compromise safety. As a combined effort between the terminology server and the client, the following criteria for expressions must, therefore, be ensured:

• All expressions should conform to the concept model when represented in their classifiable form

• No ambiguity is allowed, i.e. the transformation of the expression into its classifiable form must not result in a modification of the intended meaning of the expression

Meeting these criteria can be done in several ways and depends on the responsibility taken by the terminology server and client respectively.

Each terminology server designed to enable postcoordination with SNOMED CT should clearly specify the level of transformation supported, to enable requirements to be specified for the client side, and to support decisions about the use of postcoordination for the specific implementation. The diagram below illustrates four levels of support for postcoordination. At each level, the sum of restrictions provided by the terminology server and the client must ensure that the criteria for 'safe' postcoordinations are met.

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

SNOMED CT can be considered as a knowledge graph (direct acyclic graph), where each concept is represented as node in the graph structure, and the position of each node corresponds to its meaning and relationship to other concepts in the graph. These positions can be thought of as coordinates. Precoordinated concepts are predefined and accurately placed in the graph, while postcoordinated expressions require coordination into the graph by a description logic classifier. This is necessary to ensure that the combined concepts are positioned correctly in the graph to represent their relationships, and to allow for effective search and retrieval of the resulting concepts. In this context, the use of coordinates refers to the position of nodes in the SNOMED graph, and precoordination and postcoordination refer to the placement of concepts in the graph at a certain moment in time.

A SNOMED CT concept represents a clinical idea with a unique SNOMED CT identifier that is distributed as part of a SNOMED CT release. Concepts are linked to terms by descriptions, which provide a human-readable representation of the meaning of the concept. Additionally, they are related to each other by relationships, where each relationship represents a defining property of the concept being the source of the relationship. These defining relationships provide a machine-processable representation of the concept’s meaning.

Aside from the human-readable representation, all released SNOMED CT concepts can be represented in various ways, three of which are:

Semantic Forms

Similar to the stated and inferred view of precoordinated concepts, as described in Precoordination and Postcoordination, the meaning represented by postcoordinated expressions can also be represented in different ways. When enabling postcoordinated expressions within a system, it is important to be support these different views and understand why they are needed.

Close to User Form

The Close to User Form (CTU) Expression is the faithful representation of the clinical meaning as it was entered by the user. It is the{ primary stored and communicated view of the clinical information that’s encoded using SNOMED CT. The CTU Expression includes any refinement that was applied by the system, based on the selections made in a data entry form, or those made explicitly.

And, importantly, it does not include any additional relationships that are added, based on classifier rules to make the expression complete or to normalize it. It only includes the parts of the clinical meaning that were specifically intended by the user.

Classifiable Form

The Classifiable Form (CF) expression is a syntactically valid and concept model compliant representation of the CTU expression. It serves as the input to the classifier, enabling expressions to be classified together with other SNOMED CT content.

And in the classifiable form, any ungrouped attributes and role groups have been validated and appropriately applied to the definition of the focus concept.

The Necessary Normal Form (NNF) expression is the inferred view of the expression, and it includes all the relationships that are necessarily true, with redundancy removed. This is the output of the process that took the classifiable form expression and classified it 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 that represent inferred relationships, without any redundant refinements or redundant relationship groups.

Within the released SNOMED CT content, the stated definitions of SNOMED CT concepts are represented as Description Logic OWL axioms, and these are the clinical definition that SNOMED authors state when they define the meaning of a concept. For postcoordinated expressions, the CTU expression can be compared to the stated concept definition, as it represents the expression as it was created.

When querying SNOMED CT concepts , the inferred definitions are used. The inferred definition of a concept is derived (or inferred) by classifying the stated definitions using a Description Logic reasoner. The output of this classification process is represented in the release using the relationship table and includes the necessary normal form for each concept. The necessary normal form represents the set of ‘necessary’ inferred relationships. For more information on concept definitions, please refer to Appendix D of the release file specification: . In the same way as for precoordinated concepts, the inferred view, or the NNF expressions, needs to be generated to support querying over postcoordinated expressions, see the image below.

To enable the classification of the CTU expression, a transformation is required to provide a form that can serve as input to a Description Logic reasoner. Such reasoner requires a form which is syntactically valid and complies to the concept model rules. This is why all support for postcoordination also requires the ability to generate the CF of each expression.

Although the Compositional Grammar syntax supports a standard way of representing SNOMED CT expressions, expressions that contain exactly the same concept identifiers and refinements, may still differ from one another in the following ways:

• Inclusion of whitespace between elements

• Inclusion of specific terms associated with identified concepts

• The order in which focus concepts, refinements, attributes, and attribute groups appear

The canonical form of an expression is a serialized representation produced by applying a set of rules that ensure a single unique representation for any expression.

Before you launch into a postcoordinated solution it’s important to understand that in some cases there are alternatives to postcoordination that may be easier to implement.

The two main alternatives to postcoordination are:

Create extension concepts:

• Firstly, and perhaps the most obvious alternative to postcoordination is to add the new clinical meanings to an extension, as precoordinated content. This approach enables the use of standard SNOMED authoring tools to classify the concepts and distribute them in a way that supports queries. However, this alternative is not an option for everyone, and in those cases, postcoordination may be considered.

Use information model structure:

• The second alternative is to define the postcoordination structure using the information model, using separate coded data elements for the focus concept, and each of the refinement values in the expression. For example, rather than using an expression for ‘fracture of the foot’, two separate data elements could be applied, one for the SNOMED CT concept for 'fracture' and the other for the SNOMED CT concept for 'foot'. This approach has good accuracy for data capture but introduces significant limitations for the execution of semantic queries over the clinical data, as the focus concept is separated from the refinements and is not combined into a single SNOMED expression. In some situations where data is captured separately and follows the SNOMED CT concept model, post-processing can be applied to convert information models into postcoordinated expressions, after data capture.

This part of the guide introduces the design features of a terminology server supporting postcoordination with SNOMED CT.

This design meets the requirements outlined in and includes:

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

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 terminology services required for postcoordinated expressions are similar to the ones used when authoring content within a published SNOMED CT edition.

When submitting postcoordinated expressions to a terminology server, the expressions can be seen as a derivative, or a supplement, to the SNOMED CT Edition content available in the terminology server. Postcoordinated content lives alongside and can only be interpreted or understood in the context of a specific SNOMED CT Edition version.

Because of the dependency on a versioned SNOMED CT Edition, the successful implementation of expressions involves services to continuously ensure validity and traceability. Similar to the approach to creating SNOMED CT extensions containing clinical concepts, postcoordinated expressions, therefore, need to follow the general principles for extensions, including validation, classification, and versioning.

As illustrated in the image below, the terminology server should, therefore, be designed to hold the given versioned SNOMED CT Edition, and an expression repository to hold the postcoordinated expressions. Furthermore, in addition to the services required by the EHR to use the content and derivatives of released SNOMED CT Editions (see Terminology Services Guide), services are required to support the use of the postcoordinated content.

The following pages will elaborate on the requirements, overall design, and implementation of a SNOMED CT-enabled expression repository, and present the services needed for supporting expressions in a terminology server.

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 for 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.

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.

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.

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:

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.

The image in this page illustrates an expression repository contains one or more expression versions.Each expression version must contain the following data:

• Versioning data , to represent the time and substrate of the given version of the expression

• A Close-to-user form expression , to represent the expression as it was stated upon creation

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.

To represent an expression repository using FHIR terminology services, the required solution will depend on what approach is taken to uniquely refer to the expressions:

• The expressions themselves may be used as an identifier

  • With this approach, a CodeSystem Supplement will be created and function as the expression repository

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

Implementation Examples

The following pages provides examples of how specific terminology servers support the implementation of expression repositories.

SNOMED CT Concept Model

The SNOMED CT Concept Model is a set of rules that govern the ways in which SNOMED CT concepts are permitted to be modelled using relationships to other concepts. These rules are critical to the consistent modelling of SNOMED CT content, which in turn determines the extent to which reproducible logical inferences can be drawn. These logical inferences are the foundation for effective use of SNOMED CT for retrieval and reuse of clinical information.

For each attribute (relationship type) defined in SNOMED CT, the concept model specifies a set of rules to support the proper application of SNOMED CT attributes, including:

• Attribute Domain : The set of concepts to which the attribute may be applied

• Attribute Range : The set of concepts which may be used as the value for the attribute

• Attribute Cardinality : The minimum and maximum number of times that the attribute may appear in a concept definition

• Attribute Grouping : Whether an attribute may or may not belong to a relationship group

• Attribute In-group cardinality : The minimum and maximum number of times that the attribute may appear in each relationship group

The Machine Readable Concept Model (MRCM) represents rules of the SNOMED CT concept model in a form that can be read by a computer and applied to test that concept definitions and expressions comply with the rules.

The diagram below shows a few example of concept model rules, as they can be derived from the MRCM reference sets.

Given the machine processable nature of SNOMED CT, the Compositional Grammar and the MRCM, postcoordinated expressions may be tested against the rules specified in the MRCM, for example to validate the expression, or to support the creation of MRCM-compliant expressions.

To support the creation and validation of SNOMED CT postcoordinated expressions, the following MRCM process can be used:

1. Determine which domains the expression belongs to using the

   • An expression belongs to a given domain if any focus concept is either:

     1. Valid when tested against the associated domainConstraint ; or

Please note that in the above process only rules with a contentType = << should be used. Rules with a ruleStrength of should be enforced when authoring and cause an error during validation, while rules with a ruleStrength of should be used as a recommendation for authoring and result in a warning during validation.

An alternative approach to authoring and validating postcoordinated expressions is to use the domainTemplateForPostcoordination from the to ensure compliance with the full set of attribute rules. The domainTemplateForPostcoordination can also be specialized into an expression authoring template that meets the needs of a particular use case, while still conforming to the overall rules of the domain.

In addition to the concept model, SNOMED International also rely on editorial principles when authoring the content of SNOMED CT. The SNOMED CT Editorial Guide covers a wide range of topics, including the principles of SNOMED CT, and the structure and organization of the terminology. In addition, it documents guidelines for the modelling of content within specific domains and sub-domains that and it defines the role of the attributes available. The SNOMED CT Editorial Guide plays a critical role in ensuring the quality of SNOMED CT content, as it documents the authoring principles that require human analysis and interactions to ensure that concepts are accurate, consistently modelled, and clinically relevant.

Implementing postcoordination with SNOMED CT is similar to authoring SNOMED CT concepts, as it involves creating clinical meanings by combining existing concepts. However, it is crucial to ensure that the implementation of postcoordination does not impact clinical safety.

It is essential to involve relevant stakeholders such as clinicians, informaticians, and quality assurance personnel to ensure that the approach taken is appropriate and safe for use in clinical practice. Thorough testing and evaluation of the postcoordinated expressions can help identify potential safety concerns early in the implementation process, ultimately leading to safer and more effective healthcare.

Postcoordination with SNOMED CT offers significant benefits for users who need to capture and express clinical meanings accurately. Postcoordination enhances the flexibility and expressivity of SNOMED CT, making it more adaptable to current clinical practice. However, postcoordination also presents a variety of challenges, encompassing both human and technical issues that are crucial to handle as part of an implementation, ensuring that postcoordination is used judiciously and consistently to maximize its benefits while minimizing its potential drawbacks.

Benefits

Two overall benefits can be described for postcoordination:

Postcoordination supports the ability to express or capture new meanings or clinical ideas that are not already in SNOMED CT

SNOMED CT implementers without the means to create and manage a proper extension may require clinical meanings to be represented using SNOMED CT without being dependent on specific precoordinated concepts existing. In such cases, postcoordination may be considered as part of a SNOMED CT implementation.

Postcoordination supports the ability to compose clinical meanings from separate input values and then classify to identify existing precoordinated content

Some SNOMED CT implementations are dependent on a fixed information structure, user requirements may enforce a specific way of entering clinical data, or new clinical meanings are created dynamically (for example within a natural language processing tool). These are cases in which implementations may require clinical meanings to be represented as expressions.

To realize the benefits of postcoordination, careful analysis of the following described challenges needs to be undertaken and solutions need to be implemented.

Tooling and guidance in the area of postcoordination are still in a developmental stage

A key challenge for the implementation of postcoordination is the lack of mature or well-developed tools and practical experience within this area.

Creating expressions, in a way that conforms to all the rules and consistent with existing content in order to classify correctly, is not simple!

As described in and , expressions that represent the desired semantics must follow both terminological and editorial principles of SNOMED CT. In addition, expressions should be consistent with the modeling applied for the released SNOMED CT content. Therefore, the creation of expressions should be performed by people with the required knowledge, or assisted by tools that facilitate the proper creation of expressions.

Expressions are tied to a specific SNOMED CT release and upgrading that release requires maintenance

Maintenance processes need to be established to ensure that the expressions used in the system continue to work properly with the updated version of SNOMED CT.

Interpretation by humans is a challenge

Generated expressions may not use natural language

Task of manually assigning terms that accurately represent the meaning of expressions require training and is cognitively demanding

Interpretation by machines is a challenge

Advanced tooling is required to create, maintain, understand and use expressions

• When expressions are communicated to other systems:

  • Interpretation in the receiving system is not guaranteed

  • The burden of advanced tooling is put upon the receiving system

This playlist brings together all videos on Postcoordination with SNOMED CT from the SNOMED International Implementation Course. The videos introduce key concepts, practical implementation considerations, and real-world examples to help you understand how to enable Postcoordination with SNOMED CT.

Open playlist on YouTube:

👉 Click here to view the full playlist on YouTube

How to navigate the playlist in GitBook

When a YouTube playlist is embedded in GitBook, only one video is shown on the page at a time, but all playlist videos are still available.

• Use the forward () and back () arrows on the video player to move between videos in the playlist

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:

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.

Enabling postcoordination in an Electronic Health Record (EHR) usually requires an EHR design that is prepared to support the use of expressions.

When developing EHRs, these are usually designed with both a health record data store to record health-related information about each patient, and a terminology server to store the codes and terms that may be used in the health records as illustrated in the image below.

A SNOMED CT-enabled terminology server stores the terminology content and provides the services required by the EHR to access the content. A terminology repository is included to hold the released terminology content, for example, a specific version of a national Edition of SNOMED CT plus any required SNOMED CT derivatives. When supporting postcoordination, the terminology server should support the storage of expressions, for example using an expression repository. In addition, dedicated services are required to enable the processing and use of the expressions in the same way as the released, precoordinated SNOMED CT content.

The recommended approach to ensure efficient use of a SNOMED CT-enabled terminology server is to use a service-oriented approach where dedicated terminology services are provided via an API enabling access and processing of the content within the terminology and expression repository.

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.

Expression Repository Extension

Implementing an expression repository using the standard format specified by SNOMED International is comparable to the implementation of a SNOMED CT extension. As for SNOMED CT extensions, the content contained in the expression repository depends on a specific versioned Edition of SNOMED CT, and it requires ongoing maintenance to align with new versions of SNOMED CT.

The difference between a common SNOMED CT Extension and an Expression Repository Extension can be summarized as follows:

Difference in the representation of clinical meanings

• Clinical meanings expressed in a common extension are represented as SNOMED CT concept components and require creation and management by SNOMED CT authors

• Clinical meanings expressed in an expression repository extension are represented as SNOMED CT expression components

Difference in the content included

• A common SNOMED CT Extension may contain various components and derivatives (see )

• An expression repository extension contains only the components and derivatives required to represent postcoordinated expressions Consequently, the following components and derivatives may be contained to meet the requirements outlined in :

  • Expression components to uniquely identify the expressions

The image below illustrates the logical model of an expression repository extension.

Implementing an expression repository involves the creation of expression components, where the expression identifier uses the partition id of '16'. For more information about SNOMED CT identifiers, please refer to the

This identifier enables the unique identification of an expression and is used to establish a link between all required forms of the expression.

• The expression identifier is:

  • Used as the id for the expression component

  • Referenced in the as the value of the referencedComponentId

The moduleId attribute of the expression component refers to a concept that represents and names the module in which the expressions are maintained. This concept is a subtype of , and the terms associated with this concept should clearly indicate that this module is an expression repository, e.g. .

The CTU is stored in a separate reference set which is of the type .

Expressions in the close-to-user form will get an effectiveTime as soon as they are saved, this will match that of the current dependent code system version.

The CF is stored in a separate reference set which is of the type .

Members in the classifiable form reference set are given an effectiveTime. This will happen before the code system is upgraded to a new dependent version. Once these components are versioned they will keep the effectiveTime until the values of their fields are changed, via the transformation or classification processes. At this point changed components will have their effectiveTime cleared and will be versioned again when the code system is next versioned.

Following the classification of the CF expression, the NNF of the expression is represented as relationships. In the same way as SNOMED CT concepts, expression components include subtype and attribute relationships to represent the properties of the expression.

Components of expressions in the classifiable and necessary normal forms will have an effectiveTime set when the expression code system is versioned. This will happen before the code system is upgraded to a new dependent version. Once these components are versioned they will keep the effectiveTime until the values of their fields are changed, via the transformation or classification processes. At this point changed components will have their effectiveTime cleared and will be versioned again when the code system is next versioned.

As SNOMED CT evolves with each new release, maintaining the relevance and accuracy of postcoordinated expressions becomes imperative. Postcoordinated expressions allow for detailed and nuanced clinical concepts by combining multiple SNOMED CT codes. However, without a robust maintenance process, these expressions can become outdated, leading to failures in subsumption by any concept in SNOMED CT and exclusion from Expression Constraint Language (ECL) results.

• Concept Evolution : SNOMED CT regularly updates its content, which may include the addition of new concepts, modification of existing ones, or retirement of outdated concepts.

• Accuracy in Clinical Representation : Expressions that reference inactive concepts will no longer effectively represent valid clinical meanings, leading to misinterpretation of patient data.

Compositional Grammar

The syntax used to represent SNOMED CT expressions is called the Compositional Grammar. This is a formal grammar describing the symbols you can use and how the different parts of an expression can be constructed. Please refer to Compositional Grammar - Specification and Guide for the full detail on this.

While alternative syntaxes are possible, the compositional grammar syntax is considered to be the normative standard for interoperability purposes. Therefore, the recommended practice for anyone supporting postcoordination within their clinical information system, is to represent expressions using this syntax.

Structure

The diagram below illustrates the key parts of a SNOMED CT expression through an example. The expression used in this example represents the stated view of the concept 16554361000119106 | PET CT of brain| .

A SNOMED CT Compositional Grammar expression begins with an optional definition status, contains one or more focus concepts (represented by a concept identifier) and optionally has a refinement. Each refinement may contain grouped or ungrouped attributes (or both). An attribute consists of the attribute name (represented by a concept identifier) together with the value of the attribute. The attribute value is either an expression or a concrete value (i.e. string, integer, decimal or boolean). Please note that, in the context of an expression, the word 'Attribute' is used to refer to the name/value pair within a refinement. However, in the context of the SNOMED CT concept model, the word 'Attribute' is often used to refer specifically to the 'attribute name' (i.e. the concept used as the relationship type).

Overall, postcoordination may be performed to either refine or qualify the meaning of a SNOMED CT concept. The refinement part of a postcoordinated expression may thus represent either a 'refinement' or a 'qualification' of the stated focus concept.

Refining the meaning of a focus concept is done by applying more specific values to particular attributes of the concept. The definition of the focus concept, therefore, determines the refinements that are possible for the concept.

Consider the following expression representing the meaning 'Spiral fracture of tibia':

The focus concept of this expression has the following stated definition:

The attribute value of used in the expression (|Fracture, spiral (morphologic abnormality)|) is a subtype of the attribute-value present in the definition of the concept (|Fracture (morphologic abnormality)|), as shown below.

Qualifying the meaning of a concept can be done by adding a qualifying characteristic to a concept, e.g. by applying and attribute-value pair to the focus concept, where that attribute-value pair does not refine an existing attribute-value pair present in the definition of the focus concept. If a particular qualifying characteristic is applied to a concept, the resulting expression represents a more tightly defined subtype of that concept. All attribute-value pairs stated to qualify a focus concept should fall within the acceptable domain and range determined by the SNOMED CT concept model.

Examples of qualifications include:

The concept may be qualified according to its clinical course (<< 288524001 |Courses (qualifier value)| ) or severity ( << 272141005 |Severities (qualifier value)| )

The concept may be qualified according to its priority (<< 272125009 |Priorities (qualifier value)|) or intent (<< 363675004 |Intents (nature of procedure values) (qualifier value)|)

At this level, the terminology server requires all submitted expressions to already be in valid classifiable form. This form is a syntactically valid and concept model compliant representation expression that can be directly used as input to the classifier, enabling expressions to be classified together with other SNOMED CT content.

To enable postcoordination at Level 0, it is important that the system used to create the expressions supports any transformation needed to represent the expressions in their classifiable form. This may be enabled using one of the following techniques:

• Form-based Creation

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

• Design-time authoring of expressions

  • When postcoordinated expressions are created during the design of an EHR implementation

Communication and Display of Expressions

Autogeneration of display terms for postcoordinated expressions may be required when an expression is created in a different clinical system, or a different form on the same system, or it needs to be exchanged using a different information structure. In these cases, the information structure used to create the expression may be different to the ones available to display or exchange the expression and, therefore, the autogeneration of terms may be required.

This situation is illustrated in the image below where the meaning of "open fracture of ulna" is captured in an information structure using two data elements and communicated to a target structure with only a single data element for the same meaning. In some settings, it may be applicable to support the display of the expression in the target system by automatically generating a term.

Another situation where autogenerated terms may be useful is in systems used to create postcoordinated expressions during the design of an EHR implementation. At design time, an expression could be created using a form-based expression template, and then the system could suggest a display term that captures the meaning of the whole expression.

This scenario is illustrated in the image below.

Terminology services

The techniques to generate a display term for the expressions may differ between implementations, but the following service is required by a terminology server supporting the automatic generation of a display term for an expression:

• Get Display Term

Three different approaches to automatically creating display terms for postcoordinated expressions are presented, ranging from the simplest to the more complex.

1. Replace concept identifiers with terms

2. Apply simple term rules

SNOMED CT is a global clinical terminology that represents medical concepts with unique identifiers. These concepts can be combined into expressions to capture complex clinical meanings.

A precoordinated expression includes a single concept. A postcoordinated expression combines multiple concepts based on SNOMED CT rules, allowing detailed clinical information to be recorded without creating a new concept for every possible detail.

Postcoordination enables richer EHR documentation, supports data sharing, natural language processing, and interoperability with other code systems. However, it requires careful implementation, skilled staff, and specialized tools.

To support postcoordination, EHR systems need to handle expressions just like standard SNOMED CT content. This also requires a terminology server that can store and process both regular SNOMED CT concepts and user-created expressions, linked to a specific SNOMED CT edition.

Terminology servers can offer different levels of support. At Level 0, only fully valid expressions are accepted. Level 1 allows slightly more flexibility. Currently, it’s advised to stick to Level 0 or 1 to ensure data quality, as higher-level support still needs further development.

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.

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.

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.

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

1. Validate the CTU of all existing expressions against the new substrate

2. Resolve any validation issues, e.g. by

   1. replacing inactive concepts with proper replacements

The objective of the services described in this page is to enable the addition of a new expression in the expression repository.

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.

The logical process of the add expression service is illustrated in the diagram below.

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.

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.

The syntactic validation is performed to determine if the expression conforms to the SNOMED CT compositional grammar syntax (see section Parsing).

Please refer to the (section Validating) for more details on the validation of expression, and the for details on the computer processable concept model rules.

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.

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

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

The logical process of the service to transform and validate an expression is illustrated in the diagram below.

Summary

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

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

Objective

The objective of this service is to enable text-based searching for expressions in the expression repository.

Description

As specified in , 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. 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

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.

1. Replace concept identifiers with terms

2. Apply simple term rules

3. Apply description templates and rules

Please refer to for details on these approaches. Please note that alternative approaches may be equally valid for this task.

Summary

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 .

Summary

Expression Repository Users

Functional Requirements

The tables below shows the set of services will enable users interacting with an expression repository to perform required tasks.

Requirements for Information Managers

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.

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.

Store Derived Expression

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.

Terminology servers at Level 1 will accept any expressions represented in valid classifiable form, as in Level 0. Additionally, some expressions that are not already in classifiable form will also be accepted. These will mainly be syntactically compliant expressions that are not MRCM compliant, but which the server can unambiguously transform to derived expressions that are MRCM compliant, using predefined automated transforms.

Loose Attributes

A loose attribute is any attribute within a CTU expression that is not in an attribute group AND the MRCM specifies:

• that it should be grouped, or

• that it is in the wrong domain

Level 1 transformations of CTU expressions may apply to expressions meeting the following criteria.

• Transformations can only apply where there is no definition status

• There must be only one focus concept

• Level 1 transformations can only apply to loose attributes (as defined above)

Expression syntax, concepts being active and MRCM attribute-range validation should be applied before the transformation step. Implementations should fail fast if these are not met and not attempt transformation. This simplifies the preconditions for specific transformations.

The process of applying the transformations is iterative. This includes: collecting the set of remaining loose attributes, then applying the next transformation, and repeating until each transformation has been applied once. When each specific transformation is applied it should be greedy and transform all the loose attributes that meet the conditions of that transformation.

The list of transformations must be applied in a specific order; to ensure that the same classifiable expression is reached every time by all implementations.

The allowed patterns can be summarized as follows:

1. Refining Existing Attribute

2. Adding a Self-grouped Attribute

3. Adding Severity to Clinical Findings

4. Lateralizing Clinical Findings

The following sections elaborate on the preconditions and behaviour of each pattern.

In this case, the terminology server will accept attributes-value pairs with the following characteristics:

• The attribute is already present in the NNF of the focus concept

• The attribute value stated in the expression is a subtype of the attribute value of the focus concept

Important Notes

• If no groups are stated in the CTU expression (i.e. attributes are declared as loose attributes), the terminology server will accept attribute-value pairs correctly belonging to role groups of the focus concept as follows:

  • The terminology server will accept attribute-value pairs that refine one or more of the attribute-value pairs of the focus concept, i.e.

    • The attribute type should be the same as, or a subtype of, an attribute that already exists in the NNF of the focus concept, for which

This transformation will be applied to all loose attributes that meet the following conditions:

• The attribute applies to the MRCM domain of the focus concept (see table below)

• Only one instance of the attribute is stated in the CTU expression

  • Although the MRCM allows multiple instances, this transformation condition aims to avoid misinterpretation of the intended meaning

Please refer to the Editorial Guide for instructions on the use and the implied meaning of these attributes:

• Clinical Finding Defining Attributes

• Procedure Defining Attributes

As part of the expression transformation process, the terminology server will place the attributes in groups on their own, as shown in the examples below.

At level 1, the terminology server will accept CTU expressions matching the following pattern:

This means that CTU expressions that includes the severity attribute will be accepted if the following criteria are met:

• The focus concept is a subtype of |Clinical finding| (but not a subtype of )

• The attribute value must be a subtype of

• When applied as a loose attribute, only one instance of the attribute may be stated in the CTU expression

As part of the transformation process, the terminology server will place the attribute in a group on its own, similar to the self-grouped attributes.

The terminology server will accept CTU expressions matching the following pattern:

The transformation of expressions following this pattern will include the following steps:

1. Copy the defining properties and role groups of the focus concept (as present in the NNF) to the classifiable form expression

2. Replace the value of the |Finding site| attribute with a nested expression:

From:

To:

Important Notes

When applying the concept as the value for the attribute, the transformation should be done in accordance with the modeling applied to the content in the International Edition of SNOMED CT.

This means that the transformation steps described above should be applied twice; one for each lateral half, as illustrated in the example below.

The terminology server will accept CTU expressions matching the following pattern:

The transformation of expressions following this pattern will include the following steps:

1. Copy the defining properties and role groups of the focus concept (as present in the NNF) to the classifiable form expression

2. Replace the value of the |Procedure site| attribute (or any of its subtypes / @siteAttribute) with a nested expression:

From:

To:

When applying the concept as the value for the attribute, the transformation should be done in accordance with the modeling applied to the content in the International Edition of SNOMED CT.

This means that the transformation steps described above should be applied twice; one for each lateral half, as illustrated in the example below.

At level 1, the terminology server will accept CTU expressions matching the following pattern:

This pattern allows attributes applicable to the domain to be used to add contextual information to clinical finding concepts.

The generated classifiable form must be based on the following expression with as the focus concept and the following default attributes and values unless otherwise specified by the CTU. The value of the Associated finding attribute will be replaced by the focus concept of the CF expression.

At level 1, the terminology server will accept CTU expressions matching the following pattern:

This pattern allows attributes applicable to the domain to be used to add contextual information to procedures.

The generated classifiable form must be based on the following expression with as the focus concept and the following default attributes and values, unless otherwise specified by the CTU. The value of the Associated procedure attribute will be replaced by the focus concept of the CF expression.