Purpose

This document describes a diagrammatic notation for representing the definition of a concept, an expression, or relation between expressions within SNOMED CT. The aim of this guideline is to:

• Provide a consistent, diagramming style in documentation

• Reduce ambiguity and misunderstandings caused by multiple different representations

• Improve the quality of diagrams through a consistent approach, prompting consideration of all relevant aspects

• Increase efficiency, allowing the SNOMED CT community to rapidly exchange ideas

• Reduce effort by providing templates supporting commonly used tools

This guideline is for use in all SNOMED International documentation and is strongly recommended for all other documentation representing SNOMED CT concepts and models.

Alongside this document, templates for Visio, Omni Graffle and PowerPoint are also published.

The intended audience for this document includes members of the SNOMED CT community of practice who wish to diagrammatically represent a SNOMED CT concept or expression.

This document defines a recommended form for diagrams representing SNOMED CT concepts.

Historically these diagrams have been created using ad hoc diagramming techniques and styles to express the author's thoughts. Approaches have included borrowing from UML notation and other diagramming standards. However using ad hoc techniques have resulted in:

• Confusion and misinterpretation

  • particularly when applying adapted forms of existing standards such as UML where the reader misinterprets the diagram due to their knowledge of the underpinning standard

• Errors and omissions

  • different diagramming techniques require varying levels of detail, some of which do not force the author to think through all aspects of the idea they wish to express

In order to address these issues, a diagramming guideline has been created and is presented in this document. The aim of this guideline is to aid a clear, efficient and consistent method of communication for the SNOMED CT community of practice.

SNOMED CT Diagramming - Visio template.vsd

SNOMED CT Diagramming template.docx

SNOMED CT Diagramming.gstencil

SNOMED CT Diagramming.pptx

Provide Feedback

This section shows some example uses, diagramming existing content from SNOMED CT.

The concept definition shown in Figure 25 shows that the concept 12676007 | Fracture of radius| is equivalent to the following distribution normal form expression -

429353004 |Injury of radius| + 65966004 |Fracture of forearm| : { 116676008 |Associated morphology| = 72704001 |Fracture| , 363698007 |Finding site| = 62413002 |Bone structure of radius| }

Figure 26 shows the definition of | 12676007 | Fracture of radius | again, however, this time in long normal form and without identifiers. The expression on the right had side of the diagram equates to the text expression - | 64572001 | Disease | : {116676008 | Associated morphology | = 72704001 | Fracture |, 363698007 | Finding site | = 62413002 | Bone structure of radius |}

• Appendix A - Template Expressions

• Appendix B - Additional Context

• Appendix C - Interactive Browsing Diagrams

• Appendix D - Technical Implementation Guide Examples

The diagramming notation described in this document can be used to represent three types of information

• Expressions

• Concept definitions

• Expression relations

These different types of diagram are described in the following sections in detail, although they have the three different forms as shown below.

Note that in the diagram above

• the elements labelled "Expression" are meant to represent expressions defined in the "Expression" diagram type (see 3.1).

• the element labelled "Concept" is a concept element as defined in section 4.1

• the "op" element represents a relational operator as defined in section 4.5

Within this document "expression" refers to SNOMED CT expressions, which are

A structured combination of one or more concept identifiers used to express an instance of a clinical idea.

Each expression is composed of sub parts, which are often expressions in their own right, with a single concept value being the simplest type of expression. An "Expression Diagram" represents an expression value and is equivalent to a SNOMED CT expression. A "Concept Definition Diagram" is a series of statements defining a concept using one or more expressions to make these statements. An "Expression Relation Diagram" shows how the values of two expressions relate to one another.

It is also worth noting that the current SNOMED CT Compositional Grammar only has sufficient features to represent the left most diagram type – Expressions as defined in section 3.1. However the ability to represent the definition of a concept in terms of an expression, or show the relationship between two expressions, is useful in diagramming even though it may never be useful or included in the SNOMED CT Compositional Grammar.

For this reason, the diagramming guideline has been permitted to extend beyond the notation in the SNOMED CT Compositional Grammar for these two use cases. Aside from these cases the diagramming guideline will remain synchronized with the capabilities of the SNOMED CT Compositional Grammar.

Generally, diagrams may be in one of the normal forms (short, long or distribution), or in stated form (for definitions) or close-to-user form (for expressions). To clearly indicate that a diagram represents a particular form, it should be labelled as such. Future versions of the Diagramming Guideline may include specific additional notation to indicate a diagram's form.

Finally, a fourth use case not formally covered in this document is interactive browsing diagrams rendered by software for navigating SNOMED CT content. While not currently formally covered in this document, Appendix C - Interactive browsing diagrams does explore this use case and options for future inclusion.

Expression diagrams are the most general form of diagram, which represent a SNOMED CT expression as defined in the SNOMED CT Compositional Grammar. Diagrams representing expressions may exist on their own, or be part of a larger diagram representing a concept definition or relation between two expressions.

In its simplest form this may simply be a single concept

In more complex scenarios diagrams may represent coordination of attribute types, concepts and concrete values.

In all expressions other than a single concept value, it is necessary to start the diagram with a conjunction dot.

A more specific use of the diagramming notation is to represent the definition of a concept. This consists of

• the concept whose definition is being shown at the top left,

• connected to a series of one or more relational operators to an expression.

In all cases a concept definition should be complete. That is, they should include all defining attributes.

This can be used to represent "fully defined" concepts as follows:

Primitive concepts may be represented as follows:

The relationship between a concept and multiple expressions may also be represented, and in this manner multiple sets of attributes may be expressed.

Expressing multiple sufficient sets is not currently supported in SNOMED CT distribution content, however it may be in future, and regardless has utility in the diagramming notation and for this reason has been included.

The diagramming notation described in this document can also be used to describe the relationship between two different SNOMED CT expressions.

This is represented by two expression diagrams, one above the other, separated by a relational operator between. The diagram is read top to bottom.

As an example, below is a diagram showing two expressions that are equivalent:

Note that in this example, the equivalence relation connects the two expressions with lines, indicating that the relationship is bidirectional and can be read either way.

Figure 11 shows an expression (top) subsumed by another expression (bottom). Note that arrows have been used to connect the expressions to the relational operator to indicate the direction it must be read.

Figure 12 shows an expression (top) that subsumes an expression (bottom). Again, note that arrows have been used to indicate the direction this relationship must be read.

The following diagrams show examples taken from the SNOMED CT Technical Implementation Guide January 2013, redrawn using the notation specified in this document. If approved it is anticipated that the diagrams in the SNOMED CT Technical Implementation Guide would be replaced by the examples shown in this section.

For convenience the figure number and original diagram from the SNOMED CT Technical Implementation Guide have been included in this section.

Note that the diagrams drawn in this section are an exact copy of the diagrams from the SNOMED CT Technical Implementation Guide as at January 2013. Some of the concepts represented in the diagrams do not appear in the actual SNOMED CT January 2013 content; however this has been faithfully copied from the current diagrams in the SNOMED CT Technical Implementation Guide.

Figure 21: Refining a concept to add specificity from the SNOMED CT Technical Implementation Guide section 4.2.2.3.3

Would be redrawn as

Note that the redrawn expression diagram is distinguishable from a concept definition of "hand pain" - under the notation specified in this document concept definitions are rendered differently.

Diagram Types explores three different forms of diagram for expressing

• Expressions

• Concept definition

• Expression relation

This appendix explores a fourth type of diagram, essentially an extended use of the "Concept definition" diagram for use specifically in rendering interactive diagrams to navigate and explore SNOMED CT content.

This specific case is not included in the formal Diagramming Guideline at present, as it requires further exploration to be specified. However it may also be determined that there are multiple differing renderings that are useful in different browsing scenarios, and therefore one or a finite number of diagram styles may not be possible to define.

The following sections and examples are intended to demonstrate alternate layouts useful for browsing use cases, in an effort to elicit feedback and explore this scenario.

Figure Appendix C-1: depicts a concept definition diagram as used in the Workbench Utilities at the time of writing.

The most distinguishing feature of this approach is the removal of the "equivalence" symbol as an abbreviation. This enables the concept's parents to appear above the "concept in focus" while attributes appear on the right without excess clutter (as depicted in Figure 31).

Note that this diagram also includes child concepts of the "concept in focus" below, and attributes of which the "concept in focus" is a target on the left. This results in

• The arrows emanating from the "concept in focus" showing the definition of the "concept in focus"

• The arrows entering the "concept in focus" showing where the "concept in focus" is used in the definition of other concepts.

Figure Appendix C-3: depicts an alternate representation to that shown in Figure 30, where the "equivalence" symbol has not been abbreviated.

This approach is it conforms to the concept definition form in section 3.2; however it does present a more cluttered diagram than the abbreviated form in Figure 30.

Figure Appendix C-5: shows an alternative layout of Figure 31. This layout uses the same layout used in 3.2 for the definition of the "concept in focus" - parent concepts shown on the right hand side.

This is matches the representation in 3.2, and achieves more space for rendering where the "concept in focus" is used in the definition of other concepts. However the resulting diagram is less intuitive than displaying the focus concept's parents above the focus concept.

The diagram options in this appendix have been largely focussed on a concept definition centric interaction/navigation; however there are other focuses that may also be useful.

For example it is common to consider browsing or navigating SNOMED CT purely from its sub/supertype relationships in a full hierarchical view back to the root node. While the examples in this section do provide immediate parents, sometimes hierarchical views showing full lineage are useful. However given the real-estate requirements of full lineage and full concept definition, it is unlikely that both renderings can coexist on the same diagram concurrently. Consequently an alternate style may be required for this view, of which there are many examples in SNOMED CT browsers at present.

Another example scenario is browsing a reference set/s or SNOMED CT content in context of a reference set/s. Again this use case is likely sufficiently at odds with the examples provided in this appendix that an alternate diagram style is required.

As this Diagramming Guideline is focussed on expressions and concept definitions, these and other potential views are out of scope and as yet unexplored formally by this document. Many examples of these renderings exist in the numerous SNOMED CT browsers, and may be left unspecified for the continued innovation of browser vendors, or explored in future versions of the Diagramming Guidelines if considered worthwhile.

Diagrams are laid out and read top to bottom, left to right.

Orthogonal lines are used to connect elements; arrowheads, located on the end of lines pointing away from the line centre, indicate the direction to read the diagram.

Lines are preferred to run left to right, top to bottom, however other orientations are acceptable when required. Lines emanate from and connect to diagram elements at the top, bottom, left and right sides of the elements.

Attributes (rounded rectangles) must always have two lines connected to them, one with its arrowhead pointing at the attribute, the other with its arrowhead pointing at the concept that is the target of the attribute.

Where a single concept must appear multiple times on a diagram, authors are strongly encouraged to use SNOMED CT IDs and/or Fully Specified Names on the diagram to remove potential ambiguity. It is possible to render only one box per unique concept and connect multiple lines into that concept/s, however this is discouraged as it is likely to create difficult routing for lines and consequently poor readability.

The elements should be ordered as follows, top to bottom:

1. "Is-a" supertypes,

2. ungrouped attributes,

3. grouped attributes.

For finer grained ordering of relationships, the sort order defined in the Technical Implementation Guide should be used.

Earlier versions of the Diagramming Guideline included a section on providing additional context for concepts in diagrams - that is expanding concepts on diagrams to provide further information or context to a diagram.

These approaches, while potentially useful, also increase complexity and introduce the possibility of ambiguity and misinterpretation, and have therefore been omitted from the Diagramming Guideline. Feedback from readers is sought for future versions of the Diagramming Guideline, at present this appendix includes the two forms of additional context previously proposed to elicit feedback.

Concept Parents

A concepts parents may be added to a diagram for context using "Is a" relationships as shown in section 4.2.1. For example in the following diagram the parents of 6596004 | Fracture of forearm | have been added as extra context:

Note that this in no way changes the meaning of the diagram, which represents the expression

429353004 |Injury of radius| + 65966004 |Fracture of forearm| : { 116676008 |Associated morphology| = 72704001 |Fracture| , 363698007 |Finding site| = 62413002 |Bone structure of radius| }

The full definition of a concept may be added to the diagram to provide additional context for readers. Below is a diagram of the same expression used in section B.1, however this time the full definition of 6596004 | Fracture of forearm | has been provided:

A further suggested visual clarification to either approach specified in sections B.1 and B.2 is to use

• a dotted/dashed box around the segments of the diagram providing "additional context"

• and/or change connectors in segments reflecting "additional context" to use dotted or dashed lines

Is a complementary, not a competing, proposal to those specified in sections B.1 and B.2.

This appendix describes potential future changes designed to support template expressions. That is, expressions with predefined variables which when assigned values populate the expression.

As these are potential future extensions, this section is not a normative part of this document. It exists to gather feedback on proposed handling of template expressions. Once appropriate extensions are made to the SNOMED CT Compositional Grammar to support template extensions this section will be updated with feedback and moved to the normative part of this document.

Slots

For diagrams representing a template expression or definition, it is possible to represent "slots" which represent a placeholder a concept can fill when the template is used (see A.3). Slots are expressed using a parallelogram as shown below. The name of the slot can be considered like a variable for replacement and is surrounded by angle brackets "<" and ">".

Color for Slots

Slots as described in section A.1 are optionally coloured with RGB FF9999 (decimal 255, 153, 153) as shown below:

Concept Definition Template Diagrams

Using the "slot" element described in A.1 it is possible to define diagrams that represent a template for concept definition or expressions. It is then possible to use this template to create concepts or expressions by filling the "slots" with appropriate concepts.

These template diagrams are a specialisation of concept definition diagrams as described in section 3.2; however, some of the attribute value concepts are replaced by "slots", making the definition general and reusable.

Note the names provided for the "slots" are enclosed in angle brackets "<" and ">". These slot names are inserted into the name of the concept in the top left of the diagram.

The names associated with slots operate as unique variable names for a diagram or set of diagrams. When populated, every slot with the same name on a diagram, or set of related diagrams, receives the same concept value associated with that slot name. Unless all slots names used are assigned concept values, the expression is not complete.

This document defines the recommended diagramming specification for representing SNOMED CT concepts, expressions, and relationships in a clear, consistent, and unambiguous way. It establishes a standard visual language to support effective communication, reduce interpretation errors, and improve efficiency when creating and reading diagrams.

By providing common notation, layout rules, and templates for widely used tools, this guideline ensures that diagrams across SNOMED International publications share a consistent style and structure. It is intended for all members of the SNOMED CT community of practice who need to represent clinical concepts, definitions, or expression relationships visually, and serves as a foundation for precise, high-quality documentation.

This section describes the elements of the diagramming notation, including their shape/style and colour if applicable.

• Concepts

• Concrete Values

• Attributes

Concepts are represented by a rectangle, containing the name of the concept as shown below:

Optionally the definition status of a concept may be represented. Concepts that are fully defined may be represented using a double line border as shown below:

A concrete value is represented by a rectangle with diagonal lines in the corners. The value itself is added to the rectangle as text, with numeric values (i.e. integers and decimals) preceded by a '#', string values enclosed in double quotes, and boolean values represented as "true" or "false" with no adornment.

Relationships, or attributes, are represented using a rectangle with rounded ends and a double line border, as shown below:

"Is a" (subtype) relationships are highlighted by using an open-headed arrow as shown below:

Attribute groups are represented with a circle:

A conjunction is represented with a black "dot" (black filled small circle). It is only necessary when two or more attributes are being joined in a diagram. It is optional when attaching a single attribute.

Relational operators may be represented between expressions using the notation shown in the table below:

The characters ≣, ⊑ and ⊒ are only present in fonts that support the full set of Unicode characters. For example users of Microsoft tools will find these characters in the font called "Arial Unicode MS".

An arrow as shown below is used to connect related elements where the connection is unidirectional:

Similar to the Arrow above, the Line shown below is used to connect elements in the diagram where the connection is bi-directional.

Each element contains a name as specified. The diagram elements may be resized and/or the text of the name given to the element may be wrapped as needed to achieve readability. When resizing it is highly recommended that concept and attribute elements remain rectangular and wider than they are tall where possible.

Names chosen must be fully specified names or (usually preferred) synonyms as stated, however a single diagram must consistently use either fully specified names or synonyms for all diagram elements.

It is highly recommended that an element's name be preceded by its concept identifier. This is to eliminate any potential ambiguity.

Diagrams may be produced in black and white, or colour may be added to aid readability.

In order to provide consistency the following sections specify the colours to be used for each type of element. Specified colours are websafe, do not affect black and white printing and are generally perceptible by most common colour blindness.

Primitive concepts are coloured with RGB 99CCFF (decimal 153, 204, 255) as shown below.

Attributes are coloured with RGB FFFFCC (decimal 255, 255, 204) as shown below.

Concrete values are coloured with RGB A5E0B6 (decimal 165, 224, 182) as shown below.

Attribute groups are not coloured, and are always presented as a circle with a white interior.

Conjunctions are not coloured, and are always presented as a black dot as shown in .

Relational operators are not coloured and are always represented as shown in

Graded shading provided by modern diagramming tools is NOT permitted, as they

• Can vary substantially in style

• May reduce readability and consistency.

For example, the following are not acceptable.

For consistency, all text within diagram elements is to use a sans-serif font such as "Helvetica" and font size is to be consistent across all elements within a single diagram.

Authors are also strongly encouraged to keep the apparent size of the text in the final image close to that of the surrounding text (usually 8-12 points).