After an expression template has been processed, it is important to validate the expressions that are generated. This validation process may include checking that:

• Each expression is syntactically valid;

• Each expression conforms to the structure and constraints defined in the template; and

• Each expression is valid according to the SNOMED CT concept model.

Please note that concept model validation may not be required in all use cases.

The SNOMED CT expressions generated when processing an expression template must be syntactically valid according the SNOMED CT compositional grammar syntax. To test for syntactic correctness, an expression parser, based on the ABNF rules defined in the SNOMED CT compositional grammar specification is used. For more information, please refer to the section on Parsing.

The SNOMED CT expressions generated when processing an expression template must conform to the structure and constraints defined in the template. This includes:

• Each part of the resulting expression should conform structurally to a correspond part of the template, in the same order that it appears in the template;

• All mandatory parts of the expression template must appear at least once in the resulting expression (i.e. where the minimum cardinality is > 0);

• All non-repeatable parts of the expression template must appear at most once in the resulting expression (ie. where the maximum cardinality is 1); and

• Each token, concept, expression or value in the resulting expression, that was added as a result of replacing a slot, must conform to the type (e.g. id, scg) and value constraint (e.g. expression constraint, value list or range) defined in the corresponding slot;

In most cases, the SNOMED CT expressions generated when processing an expression template should conform to the SNOMED CT concept model. This can be tested automatically by checking for conformance with the rules defined in the SNOMED CT machine readable concept model (MRCM) in conjunction with a specific SNOMED CT substrate (e.g. the active concepts in the current SNOMED CT international edition). This includes determining the domains that the focus concepts belong to, checking that the attributes are valid for the given domains, checking that the attributes appear an appropriate number of times, and ensuring that the value of each attribute is in the correct range. For more information on using the MRCM to validate postcoordinated expressions please refer to MRCM section 6. Considerations.

When an expression template is used, a number of steps must be performed to create a valid SNOMED CT expression that conforms to the given template.

In this section, we explain the steps involved in processing an expression template. We also explain the pre-processing and post-processing tasks involved.

The figure below illustrates this process. Please note that these steps do not necessarily need to be performed in this order.

Figure 7-1: Template processing steps

Template Processing

In this section, we explain the steps involved in generating a set of SNOMED CT expressions from a SNOMED CT expression template and a set of input data. As illustrated in Processing Expression Templates, this includes:

• Adding repetition and connectors;

• Replacing slot values;

• Removing information slots; and

• Cleaning up.

Please note that these steps do not necessarily need to be performed in this order.

Expression templates may use explicit or default cardinalities to indicate parts of the expression that may be repeated (i.e. where the maximum cardinality is great than 1). In particular, a focus concept may be repeated, a relationship group may be repeated, or an attribute-value pair may be repeated. Repetition, however, is only required when multiple values are provided in the input data for a particular part of the template (see ). When multiple values are found in the input data, and this corresponds to a repeatable part of the expression template, the associated part of the expression must be duplicated to enable each separate value to be included.

For example, let's consider the following expression template and input data.

The input data above includes 2 focus concepts, 2 relationship groups, and 2 CausedBy attribute-name value pairs in the first relationship group. To support this input data, the expression template must duplicate the focus concept, relationship group, and the attribute name-value pair (in the first relationship group).

When parts of an expression template are repeated, it is important to ensure that the correct connector is added between repeated parts. For example, a "+" is added between repeated focus concepts, a "," is added between repeated relationship groups (although this is optional), and a "," is added between repeated name-value pairs.

The result of adding repetition and connectors to the above expression template (for the given input data) is shown below:

Please note that when an expression is used to populate an attribute value, it may be required to add brackets around the attribute value to ensure syntactic correctness of the resulting expression

With the repetition and connectors in place, the replacement slots must now be replaced with values. Each definition status, focus concept, attribute name and attribute value replacement slot must be removed, and the corresponding value from the input data inserted into the expression. After this step, the expression template above would look like the following:

Once the information contained in the information slots has been interpreted and processed, the information slots can be removed from the template. After this step, the expression template above would look like the following:

Clean up is an activity that can occur at any or all stages of template processing. However, any clean up that has not occurred during the previous stages, should be performed before completion.

In particular, this step involves removing any extra brackets (i.e. "( ... )"), braces (i.e. "{ ... }"), colons (i.e. ":"), equals (i.e. "="), attribute names or connectors (i.e. "+" or ",") that would cause the resulting expression to be syntactically invalid. Extraneous characters are most likely to occur when optional parts of an expression template have no corresponding value in the populated expression. When this occurs, clean up may be required to remove these characters.

In our example expression above, this step would involve removing the second instance of the attribute name , the comma before it, and the equals signs after. The resulting expression would look like:

Preparing Input Data

Before a template can be processed, it is important that the input data is represented in a clear and unambiguous way. This is required to ensure that the template is processed in the expected manner, and the intended results are produced. In this section, we explain some of the considerations in representing and preparing the input data for processing.

Input Data Representation

Template input data may be represented in a variety of forms, ranging from flat tabular structures to nested serializations. Irrespective of the format, however, it is important that there is no ambiguity as to how each piece of input data should be used to create the resulting expressions. This can be particularly challenging where repetition of relationship groups or attribute name-value pairs is required.

The UML diagram below illustrates the logical structure of expression template input data. Each set of Expression Template Input Data includes the data intended to be used to create one or more expressions. The data used to populate a single expression is referred to in this model as Expression Data. Each Expression Data (identified by an expression id), may include at most one Definition Status Slot (with a slot name and a definitionStatus value), zero or more Focus Concept Slots (each with a slotName and zero or more values), zero or more Relationship Group Slots (each with a group name), and zero or more ungrouped Attribute Name-Value Pair Slots (each with a name). Each Relationship Group Slot has zero or more Relationship Group Data instances in the input data (each identified by a group id). Each of these Relationship Group Data instances has input data for one to many Attribute Name-Value Pair Slots. And for each Attribute Name-Value Pair Slot within a Relationship Group Data instance, there are zero to many Attribute Name-Value Pair Data instances (identified by an anvPair id), each with at most one Attribute Name Slot (with name and value), and at most one Attribute Value Slot (with name and either a simple data value, or an Expression Data instance of its own).

In this section, we provide some examples of unambiguous expression template input data, and discuss how this input data can be used to populate each expression.

The expression template below is used to create expressions that represent a with one or more and . When using expression templates, such as this one, in which attribute name-value pairs and relationship groups may be repeated, the input data should be explicit about which data values are used to populate each slot, and how these values are grouped into relationship groups.

To support the creation of input data for this expression template, the logical model in

The expression template below is used as a pattern for family history expressions. It contains a nested relationship group (i.e. SSgroup) inside the outer relationship group (i.e. AFgroup). To populate this expression template, the input data must be clear as to where each value should be used, and how these values should be grouped into relationship groups and expressions.

To support the creation of input data for this expression template, the logical model can be specialized as shown below. Please note that this model has been simplified by removing unnamed logical classes, which have a cardinality of 1..1 and no data attribute.

Using the input data shown above to process the given expression template will result in following three expressions.

The expression template below represents a procedure with a single method and one or more procedure devices. Please note that in the first attribute name-value pair, both the attribute name and the attribute value use a slot. Because this name-value pair is repeatable, the input data needs to include an attribute name-value pair slot to ensure that the corresponding attribute name and attribute value stays connected.

To support the creation of input data for this expression template, the logical model above can be specialized as shown below. Please note that this model has been simplified by removing unnamed logical classes, which have a cardinality of 1..1 and no data attribute.

This logical model can be populated with input data, as shown below in the table. Please note that because the first attribute name-value pair is repeatable and uses a replacement slot for both the attribute name and attribute value, the input data needs to include the attribute name-value pair slot to ensure that the corresponding attribute name and attribute value stays connected.

Using the input data shown in the table above to process the given expression template will result in the following two expressions.

The expression template below represents a with one or more values for and , grouped into one or more relationship groups.

To support the creation of input data for this expression template, the logical model above can be specialized as shown below. Please note that this model has been simplified by removing unnamed logical classes, which have a cardinality of 1..1 and no data attribute.

The table below shows some example input data for the above template represented using the tabular format used in the previous examples.

In addition to this tabular representation, there are a wide variety of other possible formats for representing template input data, including json, xml, tsv, csv etc. The exact format used will depend on the format required by the template processor. For example, the above input data can be represented in JSON as shown below.

Example JSON Representation of Input Data

While it is important that there is no ambiguity as to how each piece of input data should be used in processing the associated expression template, there are often opportunities to make the input data much simpler than is represented in the full logical model above. In particular:

• When the maximum cardinality of a relationship group is 1, there is no need to include the relationship group slot in the input data to group the attributes it contains;

• When the maximum cardinality of an attribute name-value pair is 1, there is no need to include the attribute name-value pair slot in the input data to group the corresponding name and value pairs;

• When there is either an attribute name slot with a fixed attribute value, or a fixed attribute name with an attribute value slot, there is no need to include the attribute name-value pair slot in the input data to group the corresponding name and value pairs.

With this in mind, the examples in simplify the input data, where appropriate, using these assumptions and an implicit association with the logical model described above.