International Edition vs Country Extensions

Since the International Edition of SNOMED CT is inherited by all extensions, it must necessarily be more cautious when introducing changes that would have unknown consequences to downstream implementations.   However, country extensions may be in a better position to contact organisations which use their extension, and gauge their reaction to introducing special characters.   Country extensions may be able to advance the use of special characters more quickly than the International Edition. 

Use super/subscript characters in the Preferred Term

This is the most straightforward solution which doesn't require any added complexity around extensions or additional language reference sets.   It is the solution most likely to result in pushback from the community and unforeseen consequences, and it would require robust Editorial Guidance to be in place before the introduction of such descriptions.

Specify as acceptable synonym and allow countries to specify own preferences

This is perhaps the gentlest option that allows us to move forward with more advanced notation.   In this solution the description containing the super/subscript symbols would be a normal acceptable synonym and therefore less likely to cause a problem for downstream implementations as they would likely display the Preferred Term in the first instance.    Country extensions could then choose to specify the super/subscript description as their Preferred Term - if they were confident that this would not cause a problem for users of their extension.

Phased Approach

A compromise might be to start softly and just start introducing special characters in acceptable synonyms with no other complexity.   If this were to propagate for a year or two, then it would give implementers a chance to start adapting to the situation and perhaps enhance their existing display capabilities, before any further changes were made such as using these characters in a preferred term.

Language Reference Set to indicate preferred term in capable system.

This approach extends the previous solution of using these characters in acceptable synonyms, by identifying them in a new "Symbol Friendly" language reference set. This language reference set could then be used by implementers who were capable of displaying symbols, by using this language reference set first, and then falling back to the standard language reference sets if a "symbol" description was not present for that concept.

This is a complex solution, unlikely to be popular, but it does have the advantage that we would then have an easy way to identify these "special" descriptions in any system.   

Community Extension to add more capable terms and override language reference set entries.

A community content extension could be set up, which would add descriptions featuring super/subscript characters (and potentially other symbols), and override existing language reference set preferences so that the symbol friendly terms become the preferred terms.   This would be a costly solution for SNOMED International to implement and requires the completion of the "pick'n'mix" SNOMED Edition Packaging solution.  However, it does keep the symbol variant descriptions away from systems that would not be able to consume them and ensures that only systems that want  to see these symbols would have them.

Additional Description Type

It has been discussed that a new Description Type could be created to ensure that descriptions containing special characters are kept very distinct.   This increase in complexity and the fact that it would force implementers to make code changes for relatively minor benefit seems likely to be an unpopular approach.

National Extension Override

Use the correct characters in the Preferred Term and invite extensions to replace them with the alternatives of their choice.

Searching

It is important that searching works both ways, so for example that searching for H2O would match with H₂O and visa versa.  We will need to ensure either  that terms are created that also contain those characters in a 'normal' style, or that character folding techniques are used in back end storage systems so that these two characters are considered to be equivalent when searching.   

Validation

Similar to the question of searching, we would need to address whether a term submitted for validation eg in the FHIR $validate-code operation, should be considered a match where there is a normal vs sub/superscript versions of a character. 

Drug Safety / 

Pharmacovigilance

Specific to substances and medicinal products, there is a strong push from the pharmaceutical community to avoid using super/subscript characters as they are harder to read, may be confused or misinterpreted and could lead to identification or dosing mistakes.

Identification

We have a problem in identifying which descriptions might benefit from super/subscript characters where some ASCII workaround like ^ or >N< has not been employed .   For example the existing acceptable synonym H2O; we all know that it might be written H₂O, but what about less well known cases, and how could we programatically detect these?  This might be a good task for AI, to look through SNOMED CT descriptions and point out the terms where they would more commonly be written using super or subscript characters.

Multiple characters 

Unicode is a very broad church and there many symbols that look similar that could be used inappropriately.   Fortunately there only appears to be a single instance of super and subscript 2 and 3, but we could have a problem setting the rules for the prime / apostrophe / single quote character.