Requirements

In this chapter, we state the requirements of the SNOMED CT Template Syntax. These requirements are grouped into general SNOMED CT language requirements (which are shared by all SNOMED CT computable languages), template design requirements and template processing requirements.

General SNOMED CT Language Requirements

The general SNOMED CT language requirements include:

Requirement G.1 : Backward compatibility

The language should be backwardly compatible with any version of the language that has previously been adopted as an IHTSDO standard. Note that the only exception to this rule is where an error in the syntax has been identified and subsequently fixed.

Requirement G.2 : Consistency

Each logical feature of the language should have a single, consistent meaning across all the languages in the SNOMED CT family of languages. Each logical feature should also have a consistent set of syntax representations.

Requirement G.3 : Sufficient and necessary

Each language must be sufficiently expressive to meet the requirements of the use cases for which it was designed. However, functionality without a corresponding use case will not be included, as this increases the complexity of implementation unnecessarily.

Requirement G.4 : Machine processability

In order to facilitate the easy adoption by technical audiences, instances of each language must be able to be parsed into a logical representation using a machine processable syntax specification. This requirement will be met by defining the language syntax in ABNF.

Requirement G.5 : Human readability

Non-technical stakeholders require that the language is as human readable as possible, while still meeting the other requirements. This is essential for both the clinical validation of language instances, as well as for education and training.

Template Design Requirements

The template design requirements include:

Requirement D.1 : Placeholders for values

Templates should allow for placeholders (i.e. slots) to be specified, wherever a concept, expression, token or attribute value can be used.

Requirement D.2 Slot names

Templates should allow each slot to be assigned a name, enabling the slot to be referenced outside the slot (e.g. for specifying input data).

Requirement D.3 Slot types

Template slots should be able to be constrained to only permit a specific type of value (e.g. only allowing precoordinated concepts to replace a slot).

Requirement D.4 : Template value constraints

Templates slots should be able to be constrained to only permit values from a specific value set (e.g. only allowing expressions that satisfy a given expression constraint).

Requirement D.5 : Repeatability of template components

Templates should support a way of indicating how many times each focus concept, relationship group and attribute value pair can be repeated when the template is populated.

Template Processing Requirements

The template processing requirements include:

Requirement P.1 : Processable input data

Input data must be available, which can be automatically processed with the template to populate the slots with values. Input data must be clear (either explicitly or implicitly) as to which slot it is intended to populate, and whether multiple values are intended to be used within the same relationship group, the same expression (but different relationship groups), or different expressions.

Requirement P.2 : Post-processing validity of constraints

After template processing, the resulting language instance (e.g. expression) must be valid against the cardinality, slot type and value constraints that were defined in the template.

Requirement P.3 : Post-processing syntactic validity

After template processing, the resulting language instance (e.g. expression) must conform to the ABNF syntax of the associated base language (e.g. SNOMED CT compositional grammar).

Requirement P.4 : Post-processing concept model validity

After template processing, the resulting language instance (e.g. expression) should be valid according to the concept model rules defined by the relevant MRCM.

Requirement P.5 : Post-processing use case validity

After template processing, the resulting language instance (e.g. expression) should conform to all additional rules that are imposed by the relevant use case. For example, if an expression template is being used to author precoordinated concepts, then the resulting expression must not use nested values (to enable representation in RF2).