Page History

HL7 Vocab Item: https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=15806

ML: Supplement would hopefully only add additional descriptions that are not described in the base content.

Precedence (fallback) for multiple language reference sets only really discussed in Languages Group for ECL - other use cases not yet brought to light.

Update 28 Aug 2018: Keen to see an implementation using Supplements to see how it would actually work. Option to explore this at Baltimore Connectathon?

Update 11 September 2018: Do we need a parameter for the expand operation for this - Reuben looking into this currently.

Update 11 Dec 2018: HTTP Headers RFC 5646 (Tags for identifying languages). Suggestion that where dialects are to be referenced which do no have a standard code, one could be constructed, either using new letters or the language reference set id directly eg en-nz-x-12345601 Note also that requested language/dialect could be an ordered list for gradual fallback where descriptions may or may not be available.

Can also be passed in the language parameter passed to an expansion operation.

Language reference set could be an implicit code system supplement.

Update 8 Jan 2019: Note that SNOMED CT Language Reference sets do not indicate if they relate to a dialect, language or context of use. GG suggested FHIR could address that more directly than using a reference set SCTID to supply that desired context. Include someone in a non-English speaking country!

Update 5 March 2019: Reuben suggesting plan of action to ensure we have a solid proposal to take to the Montreal Connectathon (4-5 May 2019). Languages working group code for "consumer friendly terms" - Rob says that a harmonization proposal is in the pipeline

Update 8 October 2019:  Do we need a way to pass a refset id to designation use in an expansion operation?   The expansion operation says it will accept "A token that specifies a system+code that is either a use or a language"    Suggestion that we could then return the SCTID for the particular language refset in ValueSet.compose.include.concept.designation.use     This extended use of that field doesn't give us the ability to say Acceptable or Preferred, but perhaps it's sufficient.   We could potentially use ordering of same-refset items to put the preferred terms first.    Note that this is very SNOMED specific and doesn't offer a solution for patient friendly terms eg for LOINC.

DK "Acceptability" sounds like an extension that this group could propose.

Update Nov 12 Recommended option for specifying a language refset:

https://terminz.azurewebsites.net/fhir/ValueSet/$expand?identifier=http://snomed.info/sct?fhir_vs&filter=hysterectomy&includeDesignations=true&designation=http://snomed.info/sct|281000210109

This is based on the definition of the designation parameter: "A token that specifies a system+code that is either a use or a language. Designations that match by language or use are included in the expansion. If no designation is specified, it is at the server discretion which designations to return" A token is specified as <system> | <code>

In terms of the designations returned from, say, lookup, the group felt that it was reasonable to suggest that any given designation could have more than one use, and we would like to say something about its language reference set entry as part of some additional "use" element.

Example of current implementation:

{name: "designation",
part: [ {name: "language", valueCode: "en"},
{name: "use", valueCoding: {
  system: "http://snomed.info/sct",
  code: "900000000000013009",
  display: "Synonym"}},
{name: "value", valueString: "Obstetric umbilical artery Doppler" }] }

Question outstanding: if an acceptable designation is not available in the specified language reference set, would we want to return the fall back (default) language refset instead? In that case we would absolutely need to be able to indicate in which language reference set the term is acceptable/preferred.

Also, can we specify in the request that we are only interested in preferred terms, rather than - current implementation - both acceptable and preferred.

Also, the filter currently works at the level of the concept and the specified language. Could we filter in a way that was specific to the designation use?

valueCoding: {

  system: "http://snomed.info/scg",
  code: "900000000000013009+900000000000508004+900000000000548007",
  display: "Synonym+GB Language+Preferred"}