Arguments For & Against explicit Language Refset Not Acceptable values

Arguments For

• Not immediately obvious that the lack of a value means "Not Acceptable".   On first encounter, one would expect there to be a third alternative value to "Acceptable", "Preferred" ...

• Unusual semantics - the absence of a value actually means something definite rather than "don't know"  (DK: This is just closed world semantics, not uncommon)

• We can't currently tell the difference between a missing row, and a deliberate absence.

• Value of "Not Acceptable" is explicitly stated by an author in the authoring platform but is treated as a derived or inferred value in the RF2 files (JS)

Arguments Against

• Reduces file size

• Avoids needing validation to deal with missing row.   

• This could not work with "context of use" style language refsets eg Patient Friendly Terms.   We'd end up having to create "Not Acceptable" 99.5% of current description.

• Would need special rules eg "Do create a 'not acceptable' row in a refset that is of the same language, but not in every other languages refsets"

• Huge upheaval to change this now - consultation etc - for little business or clinical benefit.

Alternatives for Consideration (JS)

1. Create a formal concept for "Not acceptable" and provide a script, similar to the transitive closure script, for users to regenerate the language refset file with explicitly stated "Not acceptable" values.

   1. Note: If I script is unable to be created that reliable recreates the language refset file, this would be another argument for providing the value in the language refset that is generated for distribution.