Boolean Values

Background

At the January MAG meeting, @Ed Cheethamsuggested that we double check the use of String and Boolean values in the Concrete Domain specification.

Arguing against their inclusions in a "less-is-more and don't make anything more complicated than it needs to be" fashion, strings such as company trade names could be created as concepts, and we already have concepts (children of 106234000 |General adjectival modifier (qualifier value)|)  to represent boolean values in the form of 31874001 |True (qualifier value)| and 64100000 |False (qualifier value)|.     As a general principle, having multiple ways to represent content causes challenges for interoperability, so it is desirable to reduce the number of ways there are to describe the same thing.

That said, General adjectival modifiers are considered to be something of kitchen drawer solution, deliberately providing no context to inform an information model.  Their use in modeled content is somewhat problematic.

The use of boolean values does seem to be clearer in content (PWI personal opinion) and more humanly readable than an SCTID, which (as a concept) is quite a heavyweight object.   I don't know if the classifier or ontology tools would lend themselves better to working with these values directly (@Yongsheng Gao ?)   The use of booleans would also tie in with proposed changes to the SNOMED Family of Languages which (as they currently stand) will be able to work with booleans.    So working with actual boolean values would be consistent and avoid forcing implementers to hard code specific translation for 31874001 & 64100000.

The suggestion from SNOMED International is that we would not allow the use of strings or booleans at the international level, but that we would provide the option in the specifications to use this solution at the national level if NRCs decide this meets their local requirements better - particularly given that OWL itself provides this option. NRCs can always elect to not use this feature.

Use Cases for Strings and Booleans

• Strings were used to represent "Trade names" for drugs in Singapore. "Trade names" are literally a string of characters (ie a 'name'), so they considered this to be a literal. The same "trade name" is used in different countries to represent completely different drug products, and even within the same country to represent different products (i.e. same name in same country with different ingredients). There was also no direct relationship between trade name and manufacturer, or between trade name and distributor. By treating the "trade name" as a literal, they were able to make their trade products fully defined by combining the trade name with the set of active ingredients, without having to create concepts for those trade names with specific jurisdiction.

• Booleans - I think they used booleans to represent whether medications were registered as a vaccine or not. Note that in Singapore if one product was used both as a vaccine and also for another purpose, it would need to be registered twice with their drug regulatory body (HSA), with 2 different identifiers, following 2 different set of regulations ... so it was important to them to treat vaccines and non-vaccines separately with separate identifiers. I personally don't see any advantage of using the SNOMED concepts |True| or |False| for this purpose, rather than TRUE/FALSE concrete values (do you?).