Description

There are a couple of use cases that would benefit from the ability to use ITEF Language Tags (like en-US or es-MX) and have a system be able to link that to the appropriate language reference set in a computable way.

Use Cases

1. Adding term searches to ECL

For example
* {{ term = "flavor", dialect = en-us (prefer) }}
< 404684003 | Clinical finding (finding) | {{ term = "renal", dialect = en-nhs-clinical }}
< 71388002 | Procedure (procedure) | {{ term = "herz", dialect = de-cardiology }}

2. FHIR API

The SNOMED on FHIR working group has proposed a couple of solutions to allow a language reference set identifier to be specified directly by a client application, which in turn is used to select particular terms to be included in responses. The client can either specify the designation as an HTTP GET parameter eg ( designation=http://snomed.info/sct|900000000000509007 see MAINT-1167 ) or use the HTTP ACCEPT-LANGUAGE headers which can already accept a dialect like en-GB or can take a reference set SCTID in the form <language>-x-<refsetId> eg en-x-900000000000508004.

The current implementation of Snowstorm has the link between a dialect code and the refset id soft coded in a configuration file (see application.properties), and this is an unsatisfying solution. It would be better if a dialect code could be specified directly, and the mapping to the appropriate language reference set could be done in a way that was consistent for all implementations.

Proposed Solution

Create a 'Dialect alias reference set' that assigns an alias to a specific language reference set - e.g.
- referencedComponentId = 999001261000000100
- annotation = "en-nhs-clinical" or "en-gb"

Considerations

When specifying desired dialects - or more properly "communities of use" (eg en-nhs-cardiology) it is likely that implementations will need to allow for a "fall back" option. So the client application might say "Give me the New Zealand patient friendly term, and if that's not available, I'll take the GB English term instead. So in that case rules will need to be established for how that precidence should be calculated. In the Snowstorm FHIR for example, the order of Language Headers or GET request "designation" parameters is taken to be important. The first one listed will be used as the overall display term for the concept - if found, and if not the 2nd and so on.
There is an existing standard (BCP-47) which has already been used above to allow RefsetIds to be specified directly in an HTTP language header of using -x- to indicate an extension is being made to an existing tag. If we were going to allow something like en-nhs-clinical would it align to existing standards to instead call that en-x-nhs-clinical? Reading that standard such a format is called a 'private use subtag', which is perhaps not desirable for an international standard! @Former user (Deleted)wrote this on that question:

1. We could include 2 separate attributes for each Language RefSet - (1) alias (2) dialect. Because we need an alias to be unique, and 2 Language Reference Sets can use the same official dialect for different clinical contexts, scopes or audiences (e.g. cardiology, drugs, patient-terms), we may need more than just the ISO 639-1 dialect in the alias name
2. Define an official format for each alias - e.g. <ISO 639-1 2-alpha language code> [ - <ISO 3166-1 2-alpha locale code>/"any" [ - <clinical context> ] ]. For example, "fr", "en-gb", "en-gb-nhsClinical", "en-nz-patientTerms", "de-any-emergency"