One or more refinements may be added to a concept to qualify it. This is done by putting the concept to be qualified before a colon and the qualifying expression after. The qualifying expression is of the form "attribute = value". The example below describes an operation to remove an ovary (i.e. an 'oophorectomy') using a laser.

83152002 |Oophorectomy| : 405815000 |Procedure device| = 122456005 |Laser device|

The next example, shown below, describes the right hip joint.

182201002 |Hip joint| : 272741003 |Laterality| = 24028007 |Right|

Where more than one qualifying attribute is required, these can be separated using a comma. The example below describes the removal of an ovarian structure using a laser device.

71388002 |Procedure| :
405815000 |Procedure device| = 122456005 |Laser device| ,
260686004 |Method| = 129304002 |Excision - action| ,
405813007 |Procedure site - direct| = 15497006 |Ovarian structure|

A further example, below, describes the emergency removal of the appendix:

65801008 |Excision| :
405813007 |Procedure site - direct| = 66754008 |Appendix structure| ,
260870009 |Priority| = 25876001 |Emergency|

Refinements may also be applied to a conjoined concept. For example, the following two expressions are equivalent (because an 'ulna' is a bone in an 'upper limb'):

313056006 |Epiphysis of ulna| : 272741003 |Laterality| = 7771000 |Left|

119189000 |Ulna part| + 312845000 |Epiphysis of upper limb| : 272741003 |Laterality| = 7771000 |Left|

Note that there are no brackets around " 119189000 |Ulna part| + 312845000 |Epiphysis of upper limb| " in the above example, as the refinement automatically applies to the conjoined concept.

Clinical information recorded in EHRs using SNOMED CT is commonly represented using identifiers that refer to precoordinated concepts. These concepts may either be defined in the SNOMED CT international release or in an appropriate SNOMED CT extension. There are, however, times when a clinician needs to record and share a clinical meaning, which has not been defined in any release of SNOMED CT. In these situations, SNOMED CT postcoordinated expressions can be used to represent a new clinical meaning using the compositional grammar syntax.

Authoring SNOMED CT postcoordinated expressions can be performed using two main techniques:

1. Language-based authoring : This technique involves the author constructing a SNOMED CT expression using the Compositional Grammar syntax defined in Chapter 5.

2. Form-based authoring : This technique involves the author entering values into separate fields of a form, and the clinical system automatically composing the values together into a syntactically correct SNOMED CT expression.

Language-Based Authoring

Language-based authoring is useful for situations in which expressions must be defined which don't necessarily conform to a consistent structure. To use language-based authoring, the user must be familiar with the basic features of the Compositional Grammar syntax. There are, however, a number of ways in which a tool can support the user while creating expressions, including:

• Validating the syntactical correctness of the expression as it is authored;

• Checking the expression for conformance against the concept model;

• Automatically populating or correcting the term associated with a concept reference;

Some applications allow free text to be entered into patient records, which can either be manually or automatically processed to transform into SNOMED CT Compositional Grammar expressions. This approach relies on either trained staff that are available to do the processing in a timely manner, or NLP (Natural Language Processing) software which is able to generate reliable postcoordinated expressions for clinician review.

Form-based authoring is particularly useful when non-technical users need to create postcoordinated expressions which have a consistent structure. In these situations, it may be useful to create an 'expression template' in which the attribute values are represented by slots. The slots in these expression templates can then be replaced by the values that the user enters into the associated fields of the form. It may also be useful to restrict the valid values that may be entered into each field (and therefore each slot) using an expression constraint. The diagram below illustrates this approach.

A SNOMED CT postcoordinated expression may be used to express a clinical meaning that is either equivalent to or a subtype of the given expression.

Equivalent To

When the combination of focus concepts and attribute refinements are both necessary and sufficient to define the clinical meaning being represented, the 'equivalent to' definition status is used. Expressions with a definition status of 'equivalent to' may be used to express a fully defined clinical meaning in a health record or a message, to represent the definition of a fully defined precoordinated concept, or to represent an association between LOINC and an equivalent SNOMED CT expression.

To indicate that an expression has a definition status of 'equivalent to', three consecutive equals signs (i.e. "===") are placed at the start of the expression. For example, the following expression represents the definition of the fully defined concept 31978002 | Fracture of tibia| :

=== 46866001 |Fracture of lower limb| + 428881005 |Injury of tibia| :
116676008 |Associated morphology| = 72704001 |Fracture| ,
363698007 |Finding site| = 12611008 |Bone structure of tibia|

Because expressions are most often used to represent the full definition of a clinical meaning, 'equivalent to' is the assumed definition status when it is not explicitly stated. For this reason, the expressions above has an identical meaning to the following expression:

46866001 |Fracture of lower limb| + 428881005 |Injury of tibia| :
116676008 |Associated morphology| = 72704001 |Fracture| ,
363698007 |Finding site| = 12611008 |Bone structure of tibia|

Using 'equivalent to' as the assumed definition status helps to ensure the backward compatibility of this version of compositional grammar with the previous one.

When the combination of focus concepts and attribute refinements are necessary but not necessarily sufficient to define the clinical meaning being represented, the 'subtype of' definition status is used. Expressions with a definition status of 'subtype of' may be used to represent a primitive clinical meaning in a health record or a message, the definition of a primitive precoordinated concept, or an association between LOINC and a SNOMED CT expression that is necessary but not sufficient.

To indicate that an expression has a definition status of 'subtype of', three consecutive less than signs (i.e. "<<<") are placed at the start of the expression.

For example, the primitive precoordinated concept can be defined using the expression:

The definition status of 'subtype of' on this expression indicates that the definition is not necessarily sufficient to define the concept .

New attributes that are added to the SNOMED CT concept model (or to a SNOMED CT extension) may require their value to be concrete. Concrete values include integers (e.g. 500), decimals (e.g. 2.75), strings (e.g. "PANADOL"), and booleans (e.g. TRUE).

The expression shown below uses both concept values and concrete values to represent a product containing precisely 500 milligram amoxicillin per oral tablet. In this case, the dose form, the active ingredient, the basis of strength substance, and the strength unit all use a concept as their value, while the strength numerator and denominator are represented using a numeric value. Furthermore, the |Count of base of active ingredient| also uses a numeric value, and represents the number of substances that is the part of the ingredient that the strength of a given product is based upon. The numeric values are indicated in the expression by the preceding '#' symbol (e.g. #500).

SNOMED CT Compositional Grammar may also be used to state the definition of precoordinated concepts. The introduction of definition status to this version of the language makes this usage more feasible. In particular, the definition of a fully defined concept uses an 'equivalent to' definition status to indicate that the expression is necessary and sufficient to define the clinical meaning of the concept. This is the same as giving the concept a definition status of 900000000000073002 | Defined| . The definition of a primitive concept uses a 'subtype of' definition status to indicate that the expression is necessary but not necessarily sufficient to define the clinical meaning of the concept. This is the same as giving the concept a definition status of 900000000000074008 | Primitive| .

For example, 31978002 | Fracture of tibia| (a fully defined precoordinated concept) can be defined using a compositional grammar expression as being 'equivalent to' an 428881005 | Injury of tibia| and a 46866001 | Fracture of lower limb| , with an 116676008 | Associated morphology| of 72704001 | Fracture| and a 363698007 | Finding site| of 12611008 | Bone structure of tibia| . This definition is shown below in Figure 1 using the SNOMED CT Diagramming Guidelines.

Please note that SNOMED CT expressions are used to represent a single clinical idea, rather than stating the equivalence between two clinical ideas. For this reason, a concept definition written as a SNOMED CT expression includes only the definition itself, without reference to the concept being defined. For an extension to the grammar which includes both the concept and its definition together, please refer to Appendix A.

Precoordinated expressions consist of a single concept identifier, followed optionally by any term that is associated with that concept. While the use of a term is not mandated, it is often preferable to include preferred term from an appropriate dialect within the expressions to improve the human-readability of the expression.

For example: 73211009 | Diabetes mellitus|

As mentioned, the syntax does not require a term to be used with each concept identifier, so the following is also a valid expression:

73211009 | diabetes mellitus|

Provide Feedback

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). Figure 2 below illustrates the overall structure of a compositional grammar expression using an abstract representation. Please note that no specific semantics should be attributed to each arrow in this abstract diagram.

Figure 3 below shows an example of an expression with the main components marked. These components will be explained further in the subsequent sections of this document.

Details

Figure 4 below provides a more formal representation of the logical model of SNOMED CT Compositional Grammar using a UML class diagram.

...

The following sections describe the syntax used by the SNOMED CT Compositional Grammar expression language. This syntax is a serialised representation of the logical model, which is presented later in the document.

Normative Specification

The following ABNF definition specifies the syntax of SNOMED CT Compositional Grammar.

expression = ws [definitionStatus ws] subExpression ws
subExpression = focusConcept [ws ":" ws refinement]
definitionStatus = equivalentTo / subtypeOf
equivalentTo = "==="
subtypeOf = "<<<"
focusConcept = conceptReference *(ws "+" ws conceptReference)
conceptReference = conceptId [ws "|" ws term ws "|"]
conceptId = sctId
term = nonwsNonPipe *( *SP nonwsNonPipe )
refinement = (attributeSet / attributeGroup) *( ws ["," ws] attributeGroup )
attributeGroup = "{" ws attributeSet ws "}"
attributeSet = attribute *(ws "," ws attribute)
attribute = attributeName ws "=" ws attributeValue
attributeName = conceptReference
attributeValue = expressionValue / QM stringValue QM / "#" numericValue / booleanValue
expressionValue = conceptReference / "(" ws subExpression ws ")"
stringValue = 1*(anyNonEscapedChar / escapedChar)
numericValue = ["-"/"+"] (decimalValue / integerValue)
integerValue = digitNonZero *digit / zero
decimalValue = integerValue "." 1*digit
booleanValue = true / false
true = ("t"/"T") ("r"/"R") ("u"/"U") ("e"/"E")
false = ("f"/"F") ("a"/"A") ("l"/"L") ("s"/"S") ("e"/"E")
sctId = digitNonZero 5*17( digit )
ws = *( SP / HTAB / CR / LF ) ; optional white space
SP = %x20 ; space
HTAB = %x09 ; tab
CR = %x0D ; carriage return
LF = %x0A ; line feed
QM = %x22 ; quotation mark
BS = %x5C ; back slash
digit = %x30-39
zero = %x30
digitNonZero = %x31-39
nonwsNonPipe = %x21-7B / %x7D-7E / UTF8-2 / UTF8-3 / UTF8-4
anyNonEscapedChar = HTAB / CR / LF / %x20-21 / %x23-5B / %x5D-7E / UTF8-2 / UTF8-3 / UTF8-4
escapedChar = BS QM / BS BS
UTF8-2 = %xC2-DF UTF8-tail
UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) / %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail )
UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) / %xF4 %x80-8F 2( UTF8-tail )
UTF8-tail = %x80-BF

Informative Comments

This section provides a brief description of each rule listed in the normative specification.

expression = ws [definitionStatus ws] subExpression ws

| An expression often consists only of a subExpression. However, in some cases a definition status is needed to state whether the clinical meaning being represented is equivalent to or a subtype of the subExpression. If no definition status is included, the clinical meaning being represented is assumed to be ‘equivalent to’ the subExpression. subExpression = focusConcept [ws ":" ws refinement]

| A subexpression consists of one or more focus concepts, optionally followed by a refinement. The meaning of the expression is a subtype of all the focus concepts constrained by the refinement. Note that where there is a requirement for multiple separately qualified concepts to be present these are expressed in attribute groups within a refinement of a general concept such as " situation with explicit context ". definitionStatus = equivalentTo / subtypeOf

| The definition status states whether the clinical meaning being expressed is equivalent to or a subtype of the given expression representation. equivalentTo = "==="

| A definition status of equivalentTo (i.e. “===”) indicates that the clinical meaning being represented is semantically equivalent to the given expression. If no definition status is included in the expression, this definition status is assumed. subtypeOf = "<<<"

| A definition status of subtypeOf (i.e. “<<<”) indicates that the clinical meaning being represented is a semantic subtype (or subclass) of the given expression. focusConcept = conceptReference *(ws "+" ws conceptReference)

| A focusConcept consists of one or more concept references separated by ‘plus’ signs. conceptReference = conceptId [ws " | " ws term ws " | "]

| A conceptReference is represented by a ConceptId optionally followed by a term enclosed by a pair of "|" characters. Whitespace before or after the ConceptId is ignored as is any whitespace between the initial "character" and the first non-whitespace character in the term or between the last non-whitespace character and second "|" character. conceptId = sctId

| The ConceptId must be a valid SNOMED CT identifier for a concept. The initial digit may not be zero. The smallest number of digits is six, and the maximum is 18. term = nonwsNonPipe *( *SP nonwsNonPipe )

| The term must be the term from any SNOMED CT description that is associated with the concept identified by the preceding concept identifier. For example, the term could be the preferred synonym for a given dialect. The term may include valid UTF-8 characters except for the pipe "|" character. The term begins with the first non-whitespace character following the starting "|" character and ends with the last non-whitespace character preceding the next "|" character. refinement = (attributeSet / attributeGroup) *( ws ["," ws] attributeGroup )

| A refinement contains all the grouped and ungrouped attributes that refine the meaning of the containing expression. attributeGroup = "{ " ws attributeSet ws "} "

| An attribute group contains a collection of attributes that operate together as part of the refinement of the containing expression. attributeSet = attribute *( ws " , " ws attribute )

| An attribute set contains one or more attribute name-value pairs, separated by commas. attribute = attributeName ws "=" ws attributeValue

| An attribute is a name-value pair expressing a single refinement of the containing expression. attributeName = conceptReference

| The attribute name is the name of an attribute (or relationship type) to which a value is applied to refine the meaning of a containing expression. The attribute name is represented in the same way as other concept references. attributeValue = expressionValue / QM stringValue QM / “#” numericValue / booleanValue

| An attribute value is either an expression, a string-based concrete value enclosed in quotation marks, a numeric concrete value (i.e. integer or decimal) preceded by a “#”, or a boolean. expressionValue = conceptReference / "( " ws subExpression ws ") "

| An expression value is either a single concept reference without brackets, or a more complex expression enclosed in round brackets. stringValue = 1*(anyNonEscapedChar / escapedChar)

| A string value includes one or more printable ASCII characters (these are also valid UTF8 characters encoded as one octet) and/or UTF8 characters encoded as 2- 3- or 4-octet sequences. Quotes and backslash characters must be preceded by the escape character (“\”). numericValue = ["-"/"+"] (decimalValue / integerValue)

| A numeric value is either an integer or a decimal. Positive numbers optionally start with a plus sign ("+"), while negative integers begin with a minus sign ("-"). integerValue = digitNonZero *digit / zero

| An integer value is either starts with a non-zero digit followed by zero to many additional digits, or is the integer zero itself. decimalValue = integerValue "." 1*digit

| A decimal value starts with an integer. This is followed by a decimal point and one to many digits. booleanValue = true / false

| A boolean value is either true or false. true = ("t"/"T") ("r"/"R") ("u"/"U") ("e"/"E")

| The boolean value of true is represented as "TRUE" using any combination of upper or lower characters. false = ("f"/"F") ("a"/"A") ("l"/"L") ("s"/"S") ("e"/"E")

| The boolean value of false is represented as "FALSE" using any combination of upper and lower characters. sctId = digitNonZero 5*17( digit )

| A SNOMED CT id is used to represent an attribute id or a concept id. The initial digit may not be zero. The smallest number of digits is six, and the maximum is 18. ws = *( SP | HTAB | CR | LF )

| Optional whitespace characters (space, tab, carriage return and linefeed) are ignored everywhere in the expression except:

1. Whitespace within a conceptId is an error. (Note: Whitespace before or after the last digit of a valid Identifier is ignored.)

2. Non-consecutive spaces within a term are treated as a significant character of the term. (Note: Whitespace before the first or after the last non-whitespace character of a term is ignored.)

3. Whitespace within the quotation marks of a concrete value is treated as a significant character.

SP = %x20

| Space character. HTAB = %x09

| Tab character. CR = %x0D

| Carriage return character. LF = %x0A

| Line feed character. QM = %x22 ; quotation mark

| Quotation mark character. BS = %x5C

| Back slash character. digit = %x30-39

| Any digit 0 through 9. zero = %x30

| The digit 0. digitNonZero = %x31-39

| Digits 1 through 9, but excluding 0. The first character of a concept identifier is constrained to a digit other than zero. nonwsNonPipe = %x21-7B / %x7D-7E / UTF8-2 / UTF8-3 / UTF8-4

| Non whitespace (and non pipe) includes printable ASCII characters (these are also valid UTF8 characters encoded as one octet) and also includes all UTF8 characters encoded as 2- 3- or 4-octet sequences. It excludes space (which is %x20) and the pipe character "|" (which is %x7C), and excludes CR, LF, HTAB and other ASCII control codes. See RFC 3629 ( UTF-8, a transformation format of ISO 10646 authored by the Network Working Group). anyNonEscapedChar = HTAB / CR / LF / %x20-21 / %x23-5B / %x5D-7E / UTF8-2 / UTF8-3 / UTF8-4

| anyNonEscapedChar includes any printable ASCII characters which do not need to be preceded by an escape character (i.e. “\”). This includes valid UTF8 characters encoded as one octet and all UTF8 characters encoded as 2, 3 or 4 octet sequences. It does, however, exclude the quotation mark (“) and the backslash (\). See RFC 3629 ( UTF-8, a transformation format of ISO 10646 authored by the Network Working Group). escapedChar = BS QM / BS BS

| The double quotation mark and the back slash character must both be escaped within a string-based concrete value by preceding them with a back slash. UTF8-2 = %xC2-DF UTF8-tail

| UTF8 characters encoded as 2-octet sequences. UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2(UTF8-tail) / %xED %x80-9F UTF8-tail / %xEE-EF 2(UTF8-tail)

| UTF8 characters encoded as 3-octet sequences. UTF8-4 = %xF0 %x90-BF 2(UTF8-tail) / %xF1-F3 3(UTF8-tail) / %xF4 %x80-8F 2(UTF8-tail)

| UTF8 characters encoded as 4-octet sequences. UTF8-tail = %x80-BF

| UTF8 characters encoded as 8-octet sequences.

In this page, we state the requirements of SNOMED CT Compositional Grammar. These requirements are grouped into General SNOMED CT Language Requirements , which are shared by all SNOMED computable languages, and Representation of Clinical Meaning Requirements, which enable the representation of clinical meanings in health records, messages or expression associations.

The general SNOMED CT language requirements include:

Requirement G.1 : Backward compatibility

The language must be backwardly compatible with any version of the language that has previously been adopted as an SNOMED International standard. This means that any expression that is valid based on the previous SNOMED CT Compositional Grammar standard

should also be valid based on this updated version. Please note that this requirement does not preclude extensions to the language which do not affect its backward compatibility.

Where a SNOMED CT concept definition comprises a number of qualifying attributes, it may be necessary to group these to avoid ambiguity as to how they apply. An example of a SNOMED CT concept whose definition comprises multiple attribute groups is: 116028008 | Salpingo-oophorectomy| This procedure comprises two sub-procedures: the excision of part or all of the ovarian structure and the excision of part or all of the fallopian tube structure. This is demonstrated by the SNOMED CT expression for salpingo-oophorectomy, as shown below:

71388002 |Procedure|:
{ 260686004 |Method|= 129304002 |Excision - action|,
405813007 |Procedure site - direct| = 15497006 |Ovarian structure|},
{ 260686004 |Method|= 129304002 |Excision - action|,
405813007 |Procedure site - direct|= 31435000 |Fallopian tube structure|}

Where it is necessary to unambiguously qualify individual attributes of a concept whose definition comprises a number of attribute groups, a postcoordinated expression with grouping may be used. The following example describes a salpingo-oophorectomy, with laser excision of the right ovary and diathermy excision of the left fallopian tube. Note that without the grouping, it would not be possible to tell on which structure the laser excision was used and on which structure the diathermy excision was used.

71388002 |procedure|:
{ 260686004 |method| = 129304002 |excision - action|,
405813007 |procedure site - direct| = 20837000 |structure of right ovary|,
424226004 |using device| = 122456005 |laser device|},
{ 260686004 |method| = 261519002 |diathermy excision - action|,
405813007 |procedure site - direct| = 113293009 |structure of left fallopian tube|}

A number of grouped qualifiers may thus be used to refine a concept. Note that the comma between adjacent groups is optional (and omitted in this example), while the comma between adjacent attributes is mandatory. Also note, the syntax does not limit the maximum number of attributes in a group or the maximum number of groups within an expression.

It is also worth noting that when all attributes in a refinement belong to the same attribute group the braces around the attribute group are optional. Therefore the following two expressions are considered to be equivalent:

It is also possible to nest expressions, one inside the other. Any valid expression may be enclosed in a pair of brackets, and included as the value of an attribute in another expression. For example, the following expression describes a medication product that has a single dose form, which is both a spray and a suspension:

In the example above, note the use of round brackets (i.e. "( )") to identify a nested expression, as opposed to braces (i.e. "{ }"), which is used to identify attribute groups.

The following examples show how complex expressions may be build up from simple ones, a layer at a time. This first expression describes a left hip structure:

This next expression uses the "left hip" expression above to describe a procedure to replace it:

Applying a further grouped refinement to the above describes a procedure to replace a left hip by inserting a prosthesis. Note that this example mixes an ungrouped qualification and a grouped qualification. Where this is done, the canonical representation of the expression includes all ungrouped attributes before the grouped ones (see Terminology Services Guide for more details). Please also note that in the previous version of this standard a comma was not permitted between the last ungrouped attribute and the first attribute group – however this comma is now optional to avoid unexpected syntax errors.

SNOMED CT is a clinical terminology with global scope covering a wide range of clinical specialties and requirements. The use of SNOMED CT expressions in Electronic Health Records (EHRs) provides a standardized way to represent clinical meanings captured by clinicians and enables the automatic interpretation of this meaning. SNOMED CT expressions are a structured combination of one or more concept identifiers used to represent a clinical idea in a logical manner.

The SNOMED CT Composition Grammar is a lightweight syntax for the representation of SNOMED CT expressions , which has proven to be both human readable and machine parsable.

The SNOMED CT Composition Grammar was initially specified as part of the document "SNOMED Clinical Terms Abstract Logical Models and Representational Forms, External Draft for Comment Version". This version (v1) was used extensively as both a human readable and machine parsable syntax.

A revised version (v2.0 to v2.2) of this specification was adopted as an IHTSDO standard in 2010. This version followed the prior version in most details, with the following enhancements:

Compositional Grammar expressions can be automatically validated to ensure that they conform to a variety of rules, including:

• Expressions must conform to the syntax defined before. This validation can be performed using an expression parser;

• Expressions must conform to the concept model. This validation can be performed by comparing the parsed expression against the rules defined in the SNOMED CT concept model;

The SNOMED CT Compositional Grammar allows SNOMED CT expressions to be represented as a text string that can be carried in messages. For example, in HL7 version 3 messages SNOMED CT expressions can be placed in the 'code' property of the ConceptDescriptor (CD) data type (Release 2). The compositional grammar described in this document is intended to replace the qualifier mechanism that formerly was in the CD data type (Release 1), and which was removed in Release 2.

In September 2009, the HL7 Version 3 Standard "Data Types - Abstract Specification, Release 2" was published for its fourth normative membership ballot. This revised standard defined what can be carried in the 'code' property of the CD data type as shown.

Definition of the 'code' property of the Concept Descriptor (CD) data type from HL7 Data Types Release 2 Code (code) : ST.SIMPLE Definition: The plain code symbol defined by the code system, or an expression in a syntax defined by the code system which describes the concept. (emphasis added) If provided, the code SHALL be an exact match to a plain code symbol or expression defined by the codeSystem. If the codeSystem defines a code or expression that includes whitespace, the code SHALL include the whitespace.

An expression can only be used where the codeSystem either defines an expression syntax, or there is a generally accepted syntax for the codeSystem. (emphasis added)

The syntax described in this document is intended to satisfy the need for a "syntax defined by the code system" as stated above, when the "code system" is SNOMED CT. For specific guidance on using SNOMED CT Compositional Grammar in the CD data type (Release 2), please refer to Appendix B.4 of "HL7 Version 3 Implementation Guide: TermInfo – Using SNOMED CT in CDA R2 Models, Release 1".

A number of options exist for displaying SNOMED CT expressions, including:

• Displaying the expression using compositional grammar in its originally authored and stored form;

• Displaying the human-readable term that was shown to the user when originally selecting the expression;

• Enhancing the compositional grammar by adding in terms that may have been omitted, or replacing the existing terms with either local-dialect Preferred Terms or Fully Specified Names;

• Enhancing the display by using different font colors for each different part of the expression (e.g. identifiers, terms, vertical bars, and operators), and by using whitespace in a way that improves the readability of the expression;

• Automatically transforming the expression into a human-readable term using a predefined algorithm. For example, a simple algorithm may just remove the concept identifiers and nesting – e.g. "fracture of bone: finding site = arm, laterality = left". More sophisticated algorithms may use pattern matching and predefined templates to construct a more natural term – e.g. "fracture of bone in left arm";

• Representing the attribute values of the expression by populating a structured form. This approach is primarily suited to expressions with a consistent template, where the form can be pre-designed. However populating dynamically-generated forms from an expression is possible.

Please note that while various options exist, care should be taken to ensure that the selected solution is medico-legally safe and acceptable.

In order to automatically understand the inferred relationships between SNOMED CT expressions and/or precoordinated concepts, the expressions should be classified using a semantic reasoner. A number of reasoners exist, such as Snorocket, ELK and FACT++, which can classify and reason over OWL 2 EL.

Before a SNOMED CT compositional grammar expression can be classified using one of these reasoners, it must first be parsed, normalised and then translated into OWL 2 EL. The specific normalisation transformations that are required prior to translation into OWL include:

• Grouping all ungrouped attributes with a relationship type that is allowed to be grouped, and

• Transforming expressions to ensure that they conform to the concept model – in particular, where a laterality refinement has been applied to a focus concept that is not subsumed by , apply this laterality to all lateralisable finding sites within the definition of this focus concept.

The translation into OWL can then be performed in a variety of programming languages, including Perl.

The recommended approach to querying over SNOMED CT expressions is to first parse, translate (into OWL 2 EL) and classify the expressions together with the precoordinated content of SNOMED CT. A query language (such as the SNOMED CT Expression Constraint Language, SPARQL or DL Query) can then be used to construct queries, which are similarly parsed, translated and executed using an appropriate query engine.

Provide Feedback

1. Cooperation Agreement dated July 2013 between the International Health Terminology Standards Development Organisation (IHTSDO) and The Regenstrief Institute Incorporated (RII) , http://snomed.org/loinc-agreement

2. HL7 Version 3 Implementation Guide: TermInfo – Using SNOMED CT in CDA R2 Models, Release 1 , HL7 5th DSTU Ballot, January 2014, http://wiki.hl7.org/index.php?title=File:V3_IG_SNOMED_R1_D5_2014JAN.docx.

3. SNOMED CT Diagramming Guideline

4. SNOMED CT SNOMED International Glossary

5. SNOMED CT Starter Guide , IHTSDO

6. SNOMED CT Technical Implementation Guide , IHTSDO

There are a number of alternative techniques that may be used when exchanging SNOMED CT expressions in messages. These include:

• Placing the full SNOMED CT compositional grammar expression in the relevant code field of the message.

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

• Using an alternative structure for representation of the logical structure of an expression.

  • For example an OWL serialization.

• Placing a unique expression identifier in the relevant code field of the message

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

• Decomposing the expression into separate codes that can be placed in different fields within the message structure.

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

SNOMED CT Compositional Grammar provides a syntax that enables clinical ideas to be represented, even when a single SNOMED CT concept does not capture the required level of detail. This is important as it enables a wide range of clinical meanings to be captured in a record, without requiring the terminology to include a separate concept for every detailed combination of ideas that may potentially need to be recorded. Application software that supports the use of SNOMED CT expressions enables detailed clinical information to be recorded, retrieved and analysed. The logic on which the SNOMED CT concept model is based allows alternative representations of the same or similar information to be recognised and compared.

Clinical expressions using SNOMED CT concepts can be of two types: precoordinated expressions, which use a single SNOMED CT concept identifier; and postcoordinated expressions, which contain more than one SNOMED CT identifier. Postcoordination greatly increases the depth of detail that SNOMED CT can represent, while avoiding a combinatorial explosion of precoordinated concepts.

In the following we describe four of the main use cases for SNOMED CT Compositional Grammar.

Expressions In Health Records

Clinical information recorded in EHRs using SNOMED CT is commonly represented using identifiers that refer to precoordinated concepts. These concepts may either be defined in the SNOMED CT international release or in an appropriate SNOMED CT extension. There are, however, times when a clinician needs to record and share a clinical meaning, which has not been defined in any release of SNOMED CT. In these situations, SNOMED CT postcoordinated expressions can be used to represent a new clinical meaning using the compositional grammar syntax.

The SNOMED CT Compositional Grammar allows SNOMED CT expressions to be represented as a text string that can be carried in messages. For example, in HL7 version 3 messages SNOMED CT expressions can be placed in the 'code' property of the ConceptDescriptor (CD) data type (Release 2). The compositional grammar described in this document is intended to replace the qualifier mechanism that formerly was in the CD data type (Release 1), and which was removed in Release 2.

In September 2009, the HL7 Version 3 Standard "Data Types - Abstract Specification, Release 2" was published for its fourth normative membership ballot. This revised standard defined what can be carried in the 'code' property of the CD data type as shown.

Definition of the 'code' property of the Concept Descriptor (CD) data type from HL7 Data Types Release 2 Code (code) : ST.SIMPLE Definition: The plain code symbol defined by the code system, or an expression in a syntax defined by the code system which describes the concept. (emphasis added) If provided, the code SHALL be an exact match to a plain code symbol or expression defined by the codeSystem. If the codeSystem defines a code or expression that includes whitespace, the code SHALL include the whitespace.

An expression can only be used where the codeSystem either defines an expression syntax, or there is a generally accepted syntax for the codeSystem. (emphasis added)

The syntax described in this document is intended to satisfy the need for a "syntax defined by the code system" as stated above, when the "code system" is SNOMED CT. For specific guidance on using SNOMED CT Compositional Grammar in the CD data type (Release 2), please refer to Appendix B.4 of "HL7 Version 3 Implementation Guide: TermInfo – Using SNOMED CT in CDA R2 Models, Release 1".'

SNOMED CT Compositional Grammar may also be used to state the definition of precoordinated concepts. The introduction of definition status to this version of the language makes this usage more feasible. In particular, the definition of a fully defined concept uses an 'equivalent to' definition status to indicate that the expression is necessary and sufficient to define the clinical meaning of the concept. This is the same as giving the concept a definition status of . The definition of a primitive concept uses a 'subtype of' definition status to indicate that the expression is necessary but not necessarily sufficient to define the clinical meaning of the concept. This is the same as giving the concept a definition status of .

For example, (a fully defined precoordinated concept) can be defined using a compositional grammar expression as being 'equivalent to' an and a , with an of and a of . This definition is shown below in Figure 1 using the SNOMED CT Diagramming Guidelines.

Please note that SNOMED CT expressions are used to represent a single clinical idea, rather than stating the equivalence between two clinical ideas. For this reason, a concept definition written as a SNOMED CT expression includes only the definition itself, without reference to the concept being defined.

For an extension to the grammar which includes both the concept and its definition together, please refer to Appendix A.

Expressions can be used to support SNOMED CT implementations in circumstances where the available pre-coordinated content does not fully meet the requirements for clinical representation. By employing postcoordination, existing concepts can be combined into a single expression that conveys a more precise or context-specific meaning.

For detailed guidance on the use of postcoordination within SNOMED CT, please refer to

Parsing is the process of analysing a string of characters according to the rules of a formal grammar. Parsing a Compositional Grammar expression involves processing the expression string, using the ABNF syntax defined before, and breaking it into its constituent parts. This creates a representation of the expression that can be further processed. Parsing an expression is required to perform syntactic validation, concept model validation, translation, querying or classification.

A number of parser development tools are available which can generate a parser from a context-free grammar written in ABNF, such as the one defined in this document. These tools include:

• APG

Two or more concepts may be combined to form a new concept by joining them with the "+" symbol. This is particularly useful where both concepts are primitive. The resultant expression is the child of each of the concepts in the expression. The resultant expression below represents a drug dose form that is both a spray and a suspension.

421720008 |Spray dose form| + 7946007 |Drug suspension|

Although not stipulated by the syntax, the two concepts joined in this way must (in nearly every case) come from the same top level hierarchy. A rare exception to this rule is those expressions which refer to products that are both drugs and devices, and are therefore descendants of both 373873005 |pharmaceutical / biologic product| and 260787004 |physical object|.

The syntax does not mandate which concepts in the expression should have associated terms and which should not, so it is valid (although not advisable) to mix and match. For example, the following syntax is valid:

421720008 + 7946007 |Drug suspension|

The syntax allows spaces, tabs and carriage returns in most places. The following example has an identical meaning to the one above:

421720008
+ 
7946007 | Drug suspension|

Provide Feedback

SNOMED CT Compositional Grammar is a syntax for representing SNOMED CT expressions. SNOMED CT expressions are a structured combination of one or more concept identifiers used to express a clinical idea. When documenting a full concept definition or an expression relationship statement, which asserts the relationship between two expressions, it is often useful to use a syntax that is consistent with SNOMED CT Compositional Grammar. For these purposes, the following ABNF syntax extension may be used:

statement = ws "(" ws subExpression ws ")" ws definitionStatus ws "(" ws subExpression ws ")" ws

where 'subExpression' and 'definitionStatus' are defined as per SNOMED CT Compositional Grammar.

For example, the following statement documents the definition of the fully defined concept 95617006 | Neonatal cyanosis| .

( 95617006 |Neonatal cyanosis| ) === ( 3415004 |Cyanosis| + 363696006 |Neonatal cardiovascular disorder| : 246454002 |Occurrence| = 255407002 |Neonatal| , 363698007 |Finding site| = 113257007 |Structure of cardiovascular system| )

Figure 6 illustrates this concept definition using the SNOMED CT Diagramming Guideline.

In this second example, the definition of the primitive concept is shown:

( ) <<< ( : = )

Figure 7 illustrates this concept definition using the SNOMED CT Diagramming Guideline.

In this last example, the equivalence of two expressions is defined (as illustrated in Figure 8):

( : = ) === ( : = , = )

The SNOMED CT Compositional Grammar is a formal, lightweight syntax for representing SNOMED CT expressions - structured combinations of one or more concept identifiers that convey precise clinical meaning. Designed to be both human-readable and machine-parsable, the grammar has evolved through multiple versions since its initial specification, incorporating formal ABNF definitions, enhanced character encoding rules, and support for concrete values such as numbers, strings, and booleans. This specification defines the grammar, provides examples, and offers guidance for implementing it in systems such as EHRs, decision support tools, and terminology services, ensuring consistent and interoperable representation of clinical ideas across diverse healthcare contexts.

Provide Feedback

Storing SNOMED CT postcoordinated expressions in Electronic Health Records enables clinical systems to capture a wider range of clinical meanings than would be possible using precoordinated expressions alone. When storing postcoordinated expressions written using SNOMED CT Compositional Grammar in health records, a number of options are available including:

• Storing the entire expression as a string in the relevant field of the patient's record. This requires the maximum length of the field to be large enough to support the required expressions;

• Storing a list of expressions in an Expressions table, and associating each expression with a local identifier.. These local expression identifiers are then stored within the relevant field of the patient's record. The Expressions table enables a lookup service to match the local expression identifier stored in the patient's record with the associated postcoordinated expression. This allows shorter identifier strings to be recorded within the patient record, instead of the longer postcoordinated expressions. While this approach may have a slightly detrimental effect on the retrieval of a patient record, it can reduce the storage requirements and enable indexing over expressions for faster searching. These local identifiers, however, cannot be shared with other applications, which do not have access to the associated postcoordinated expressions;

• Using a shared expression repository to generate expression identifiers that can be stored in the relevant field of the patient's record. This approach allows shorter identifiers to be recorded in the patient records (as per the previous approach), while using identifiers which can be shared between applications that share access to the same expression repository.

Please note that while transforming an expression to other equivalent forms (e.g. a normal form) may be useful to support effective data retrieval, even minor corrections to the definition of a concept in future releases may significantly alter the resulting form of the same expression. Therefore it is recommended that:

• The primary or original record should be stored using the representation that is as close as possible to the form in which it was recorded;

• If transformations to alternative representations are used to enhance the efficiency of retrieval, these should be stored as secondary supporting tables or indices. This has the advantage that these alternative forms can be regenerated based on the most up to date set of definitions when a new release of SNOMED CT is installed, without affecting the integrity of the original records.

For alternative approaches for storing postcoordinated expressions, that do not use SNOMED CT Compositional Grammar.