Expression Repository in RF2

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

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