The proposal is to tighten up the wording of the File Naming Conventions to dis-allow dialect codes in the spec, which currently allows for a dialect code in that position, but doesn’t specify dependencies such as the contents of the language refset file.
-
This would be implemented here:
-
It would be applied to the “ContentSubType” element of the naming conventions.
-
It would apply to all SNOMED CT products (including Managed Service products), and would have to be applied consistently going forward to any product being published by SNOMED CT
-
It would not be applied retro-actively
-
However, Managed Service customers could, in theory, add a dialect element in after receiving the package from SNOMED CT
-
It would not have an impact on the International Edition, as there are currently no dialects specified in the package.
-
The questions then, would be:
- a) is there any known impact to applying this to all products?
- b) would this cause problems for any managed service customers?
- c) would this cause problems for any end users?
- d) should we allow managed service customers to specialise it post-release?
- e) if so, do we have to make this an Optional Element in the Release File Spec?
- f) or, should we be removing it completely from the Release File Spec docs?
- g) can we apply it to ALL file types, or just say Descriptions/TextDefinitions, but still ALLOW it for LanguageRefset files?