SNOMED CT Annotations

Background

SNOMED CT is an OWL 2 EL ontology that conforms to the OWL standard specification after the Logical Profile Enhancements explicitly represent axioms in OWL expressions. In the OWL structural specification, annotations are considered as ‘first-class citizens’.  

Open

https://www.w3.org/TR/owl2-syntax/

There is a need to clarify what SNOMED CT annotations are and how they should be represented in SNOMED CT. Furthermore, how they should be transformed from the aspect of the OWL ontology. The descriptions and definitions are annotations for the OWL ontology. However, they are excluded from the annotation refsets to avoid impacts on the exiting release file specifications and implementations. This issue has been addressed by specifying the mappings between metadata concept description types and annotation attributes. (https://snomed.org/owl).

• Fully specified name is mapped to rdfs:label

• Synonym is mapped to skos:altLabel

• Preferred term is mapped to skos:prefLabel

• Definition is mapped to skos:definition

The present approach to annotations is sub-optimal in SNOMED CT because

• Despite the development of the annotation refset, the annotation properties are not explicitly expressed because the Object-Value pattern of the refset. Should the concepts, for example, |Image (foundation metadata concept)| or |Associated image reference set (foundation metadata concept)| be considered annotation attributes?

• The existing annotation type refset only allows concepts to be annotated using the String datatype. Annotations to other SNOMED CT components or members of a refset are not permitted.

• It is not ideal to mix the clinical terms and metadata information of the same concept in the description file. The descriptions is the component type and require highly specific information that are not necessary for annotations, e.g. case significant, preferred or acceptable. Annotation should not be used for data entries in clinical records, which is different from clinical terms as controlled vocabularies.

• The potential annotation attributes are organised in different hierarchies, such as core metadata concept, foundation metadata concept, and linked assertion. It is unclear what annotation properties are available in SNOMED CT.

• When a new annotation type is required, a new reference set has to be created. This will require implementors to keep track of new annotation reference sets and create applications for each one. 

The enhancement for representing annotations in SNOMED CT is needed to make it easier for creation and implementation of new annotation properties and annotations. An annotation can be assigned to any component or artefact in SNOMED CT terminology. For example, the metadata of a refset, e.g. domain, organization, audience, etc. can be represented by new annotations for a refset concept. The new annotation attributes and values can be added as part of the standard terminology content editing process.  Annotation attributes can provide explicit meanings and prevent the "synonym" description type from being misused. 

Proposed changes

The proposal is to create a new subhierarchy to formally represent annotation attributes in SNOMED CT. An annotation attribute is a non-defining SNOMED CT attribute. An annotation is the value of an annotation attribute. In addition, the existing annotation refset will be replaced by two new types of annotation refsets with the Object-Attribute-Value pattern. 

Annotation attribute hierarchy

The annotation attributes accept values, such as metadata, references, notes, and associate them with entities, axioms and ontologies. The Descriptions Logic reasoners do not use these annotation attributes for classifications.

A new |Annotation attribute (attribute)| needs to be added as a subconcept of 246061005 |Attribute (attribute)|, which is an sibling to 410662002 |Concept model attribute (attribute)|. The |Annotation attribute| serves as the root for a new subhierarchy for any new annotation attributes, such as "inactivation note", "attribution" etc. The following hierarchy only demonstrate some new annotation attributes. 

Annotation attribute hierarchy:

• 246061005 |Attribute (attribute)|

  • 410662002 |Concept model attribute (attribute)|

  • |Annotation attribute (attribute)| - new annotation attribute

    • |Attribution (attribute)| - new annotation attribute

    • |Namespace owner (attribute)| - new annotation attribute

    • |Change note (attribute)| - new annotation attribute

      • |Inactivation note (attribute)| - new annotation attribute

    • |Additional relationship attribute (attribute)|  - new annotation attribute to indicate its subtypes are addtional relationships

      • |Language tag (attribute)| - new annotation attribute for addtional relationships

      • |Language (attribute)| - new annotation attribute for additional relationships

The descriptions in SNOMED CT are mapped to OWL annotations. They are critical clinical terms that should not be mixed with other annotations. The annotation attribute hierarchy excludes the core metadata concepts for fully specified names, synonyms and definitions. 

Display of annotations

The descriptions in SNOMED CT are mapped to OWL annotations. They are critical clinical terms that should not be mixed with other annotations. The existing descriptions of concepts are a special kind of annotations, "controlled vocabularies", in the terminology. The additional annotation attributes and values of concepts could be displayed along with the existing descriptions. There should be a clear indication of the difference between these two types of annotations. For example,

The layout and format for how annotations should be displayed are out of the scope of the specification. However, it is required that both annotation attribute and value should be displayed together.

Two new annotation refset types with two data types:

These two new annotation refsets will replace the existing annotation refset. The new annotation refsets should be used for representing all annotations that are stated by content authors. It does not require to make changes to the exiting file structures and their content to avoid impact on current implementations. Annotations should be an integral part of SNOMED CT terminology. The derivatives should not be represented as annotations, such as mappings to/from other terminologies.

It is possible that some annotations could be represented as non-defining relationships. These non-defining relationships are effectively annotations following the OWL standard and should be stated in the annotation refsets. Some implementers may choose to mix them with the necessary conditions based on the logic definitions in the inferred relationship files. The relationship file for concrete values has been developed for supporting logical definitions in concrete domains. The annotation values in datatype of string are not concrete domains in logical definitions though the file format can support the storage. This is a significant change to the inferred relationship files that represent the necessary conditions of logical definitions unless they are changed to content model that are not restricted to the logic model. Furthermore, the specifications for MRCM and diagramming need to be updated to distinguish the defining and non-defining relationships.

These four annotation refsets should cover most use cases. They can be used by national extensions without creating new annotation refsets. 

Metadata

The following metadata supports these reference sets :

The concepts, descriptions, relationships are commonly referred component types in SNOMED CT and they are represented by SNOMED Identifies. Two additional components that are members of refsets or postcoordinated expressions and they are represented by UUIDs. 

Component annotation reference set type

The new component annotation reference set needs to be created to support annotations on any components.  The new annotation type refset includes specific attributes:

• referencedComponentId - A component ID in SNOMED CT.

• languageCode - 900000000000465000 |String (foundation metadata concept)| 

• typeId - Any descendant of |Annotation attribute (attribute)| in the attribute hierarchy. 

• value - Any descendant of 900000000000459000 |Attribute type (foundation metadata concept)| in the metadata hierarchy.

Descriptor refset for Component annotation reference set

The attributeType for the 900000000000518009 |Annotated component| field can be any descendant of the |Component type (foundation metadata concept)| excluding the postcoordinated expression and rerfset member type components in the metadata hierarchy.

The attributeType for the |Annotation type (foundation metadata concept)| field can be any descendant of |Annotation attribute (attribute)| that is a kind of |Concept type component (foundation metadata concept)| (or more specifically any new annotation attributes that is a subtype of attribute). 

The attributeType for the 900000000000519001 |Annotation value (foundation metadata concept)| field can be any descendant of 900000000000465000 |String (foundation metadata concept)| or 900000000000460005 |Component type (foundation metadata concept)|. 

Component annotation reference set example

Note: 

Some new annotation attributes are added to demonstrate that these are new content of the existing refset without the additional new refsets and refset descriptors. 

"GB English" should not be a synonym of |Great Britain English language reference set|. The new annotation attribute |Language (attribute)| can resolve the misuse of synonym. 

The new annotation attribute |Language tag| can be used to assign ISO 639-1 code  and include two letter country codes (ISO 3166) when applicable by following RFC 5646. For example, Any descendant of 900000000000506000 |Language type reference set (foundation metadata concept)| can have a language tag annotation to facilitate technical implementations of queries by language tags. There are only 10 entries for language tags in the International Edition.

Similarly, a new annotation attribute |Namespace owner (attribute)| can be added without creating a new refset. The instance data, such as namespace owned by NHS Digital can be store in the same component refset. There would be about 300 entries for namespace owners. 

Member annotation reference set type

The new member annotation reference set type needs to be created to support annotations on a member of any reference sets. The new annotation type refset includes specific attributes:

• referencedComponentId - A component ID in SNOMED CT. 

• referencedMemberId - An UUID of a member in a reference set in SNOMED CT.

• annotationTypeId - Any descendant of |Annotation attribute (attribute)| in the attribute hierarchy. 

• Annotation - Any descendant of 900000000000459000 |Attribute type (foundation metadata concept)| in the metadata hierarchy.

Descriptor refset for member annotation reference set

The attributeType for the 900000000000518009 |Annotated component| field can be any descendant of the |Component type (foundation metadata concept)| excluding the postcoordinated expression and rerfset member type components in the metadata hierarchy.

The attributeType for the |Annotated member (foundation metadata concept)| field is the 900000000000464001 |Reference set member type component (foundation metadata concept)| in the metadata hierarchy.

The attributeType for the |Annotation type (foundation metadata concept)| field can be any descendant of |Annotation attribute (attribute)| that is a subtype of attribute).  

The attributeType for the 900000000000519001 |Annotation value (foundation metadata concept)| field can be any descendant of 900000000000465000 |String (foundation metadata concept)| or 900000000000460005 |Component type (foundation metadata concept)|. 

Member annotation reference set example

There are three potential options for the reference component in the |Member annotation refsernce set|.

1. The referenced component in the target refset - The same value of the referencedComponentId from an annotated refset is assigned in the annoation refset. For example, this OWL axiom has a referencedComponentId 91302008 |Sepsis (disorder)| in the OWL expression refset. The annotated text could indicate the intended annotation target is the OWL axiom though it is not referenced in referencedComponentId.

2. A specific field in the target refset for annotation - The value referencedComponentId is the concept ID of a selected target field in the target refset for annotation. The combination of the referenceComponentId (field) and referencedMemberId (row) represent the specific cell in the target refset. The referenced entry in the above example is the following OWL axiom that has been assigned a change note annotation. The value of referencedComponentId is |OWL expression| (field) and referencedMemberId (row). The targeted cell for annotation is the following expression in the refset.
   EquivalentClasses(:91302008 ObjectIntersectionOf(:238147009 ObjectSomeValuesFrom(:609096000 ObjectIntersectionOf(ObjectSomeValuesFrom(:116676008 :409774005) ObjectSomeValuesFrom(:363698007 :113343008) ObjectSomeValuesFrom(:370135005 :769256002))) ObjectSomeValuesFrom(:609096000 ObjectSomeValuesFrom(:42752001 :40733004))))

3. The refset ID in the target refset - The value of referencedComponentId is the target refset for annotation. 

The second and third options provide fine tuned information about the target for annotations, e.g. cell, or refset. However, they cannot be utilised for the ECL queries because the default field is the referencedComponentId when it is in conjunction with other expressions. The target reset and member annotation refset should have the same value for the referencedComponentId field.  Therefore, option 1 is the only valid approach to utilise ECL queries. 

Representation of annotation data type

The restriction on datatype of annotation is relaxed in the new annotation refsets. The datatype can be any descendant of the 900000000000459000 |Attribute type (foundation metadata concept)| in the metadata hierarchy. The annotations could be a String, SNOMED CT component (concept, description, relationship), or number (integer, decimal). If a specific restriction is needed,  the specific datatype of each annotation attribute can be specified.

In conventional approach, the datatype of each annotation is specified by the attributeType of each attributeDescription in the |Descriptor reference set|. A new refset and refset descriptor need to be created for each new annotation attribute.

In this new approach, the new annotation attribute |Annotation attribute datatype (attribute)|  could be used to annotate the annotation attribute and specify specific datatype of annotation. All annotations can be stored in the component annotation refset because they are annotations to attributes. 

Component annotation reference set example

Given main purpose of annotations is to provide human readable text informations. It may not be necessary to specify the above refinement of datatypes. 

In order to simplify implementations, type indicator symbols should be used in annotations

• Numeric values should be prefixed by a hash (#) symbol;

• Text values should be surrounded with double-quote characters (") only when the language code is present. Any double quote characters that appear within strings should be escaped by a backslash (\) symbol;

• The rest subtypes of 900000000000465000 |String (foundation metadata concept)| do not need to surrounded with double-quote characters.

  • OWL 2 language syntax (foundation metadata concept)

  • SNOMED CT parsable string (foundation metadata concept)

    • SNOMED CT compositional grammar (foundation metadata concept)

    • SNOMED CT expression constraint language (foundation metadata concept)

    • SNOMED CT expression template language (foundation metadata concept)