Annotations for concepts or descriptions

Description

There are requirements for additional annotations (in the context of OWL) to SNOMED CT concepts or new description types for different use cases. It is desirable that we consider the problem fully, including the impact on implementers rather than jumping into a solution for providing additional descriptions. It is also important for attempting to align with existing standards before we increase the complexity of SNOMED CT.  There is an early draft page on the more general questions of SNOMED CT Annotations (to be updated). There is a concern that we might open flood gates and create a number of new description types that are not entirely warranted that will have a downstream cost and impact on content authoring and implementation.

Concrete Use Cases

1. The Editorial Advisory Group have discussion on supporting near synonyms, hypernyms and hyponyms. @Jim Case any references available for the desirability of hypernyms and hyponyms?  See item #3 in 2020-04-29 Editorial Advisory Group Conference call.

2. The content team require ability to record additional information, such as reason for inactivation, references, editing notes etc. The additional information will require the support for different data types as values, component IDs, hyperlink URIs, Strings (languages), length of term (over 255 char for vaccine names)

3. Index terms for searching concepts, but not necessarily used directly in medical records, which is a legal document, to avoid potential clinical safety concerns where the meaning is not clear and unambiguous.

4. Patient friendly terms, realm or specialty specific terms proposed as Dialect Aliases raised by @Former user (Deleted)  from the work of SNOMED languages project group (SLPG) meeting

Possible Solutions to utilise the existing RF2 formalism (...because you can't stop a developer solutionizing)

1. Add new annotations as description type concepts under 900000000000446008|Description type (core metadata concept)|. Currently, FSN, Preferred term and definition are three description types. 

   1. The list of new description types needs to be agreed, e.g. alias, near synonym, hypernym, hyponym, index term, patient friendly term, renal term, cardiology term, etc.

   2. Rename the existing Text Definition file to "Additional Descriptions". The values of these new description types will be stored in this file. It already allows for longer terms, languages, and case sensitivities. However, how do we support other potential value types?

2. Add a new "Annotation property" under 246061005|Attribute (attribute)|. The new proposed type of descriptions will be added as a subattributes of "Annotation property".
         For concept annotations:

   1. Each annotation property will have a new Annotation file in similar structure to Text definition file but 'term' field will be changed to 'annotation'.

   2. Each annotation can only have values specified by the range of MRCM for the annotation property.

   3. Potentially to have additional column to indicate if the value of annotation to indicate if annotation is releasable or not. if releasable = 0, this annotation would be used only as internal terminology information. They will not be released.
      
      Similarly, annotations can be assign for descriptions. The similar structure for text definition file can be used, but 'conceptId' field will be changed to 'descriptionId' and 'term' will be changed to 'annotation'.
      
      

3. Create new 'annotation refset' for each new annotations. Fore example, concept 900000000000508004 |Great Britain English language reference set (foundation metadata concept)|

             referencedComponentId = 900000000000508004
             annotation = "en-GB"

4. Add the alias as a synonym of the language refset concept, and use a Simple type reference set to indicate which synonym is the alias to be used for each language refset. For example:   900000000000508004 |Great Britain English language reference set (foundation metadata concept)| with a new synonym: en-GB

          referencedComponentId = <descriptionId of 'en-GB'>
   
   

Other considerations

• Use case of using near-synonymous terms during searching to assist with returning results, but not necessarily displayed in the selected concepts.

• Degree of synonym could be specific to particular contexts eg given Language Refsets.

• Business process for approval of new annotations for concept/description. 

• Impact to content maintenance, tooling, education, diagram standards, implementers (including FHIR)

• Policy, guidances for content maintenance for annotations 

• Tooling and release files to support new annotations

• Implementation guidance

• Alignment with other standard terminology in OWL as an annotation

• Separation of languages/dialects from annotation types