Stream: terminology
Topic: Languages value set
Grahame Grieve (Aug 04 2018 at 06:06):
I do not understand the value of GF#13732. We already have a max value set of all possible languages, and then we have a shorter list, a practical one - which is translated to other languages. I do not understand the value of adding a whole bunch of dialect variations for non-HL7 affiliates, when any language is allowed, and this is the common set. Why add uncommon variants?
Grahame Grieve (Aug 04 2018 at 06:07):
rather than just add a big long lit just because, I'd rather:
- ask affiliates if they believe that there's anything missing for their realms
- accept requests for this
Grahame Grieve (Aug 04 2018 at 06:08):
if the problem is that some terminology service wants a blown out list to use as a short cut for the max list, well, then, let's add that as it's own value set - and why not actually build it automatically so that it's comprehensive, instead of a list that's too long to be useful, and too short to be comprehensive?
Grahame Grieve (Aug 04 2018 at 06:09):
@Robert McClure this is your ask. @Josh Mandel this is your motion. @Brian Ahier you seconded (man, I've never heard of you being on a call)
Robert McClure (Aug 05 2018 at 16:28):
@Grahame Grieve As I understand it, the content of MAX would include all possible technically valid combinations, many (most?) of which are not known languages. Your shorter "practical" list is to my understanding a one-time guess at languages in play for HL7 affiliates. This list is to be used across all jurisdictions and the list I presented is known to be of use. Your suggested approach means that in implemented systems when a patient needs to document a needed language, they will not be able to because no system will ever support, nor expect a clinician to craft the correct representation for a missing language on the fly. This results in incomplete, perhaps dangerous, lack of data in the record. What makes you think that HL7 affiliates define the breadth of useful languages? Isn't it possible that it would be the rare languages that might be most problematic for patient care and demonstrate a need for capturing that information?
What is the problem with taking a known, vetted list and using that instead of your 'HL7 defines the sum of need' list?
Grahame Grieve (Aug 05 2018 at 21:23):
well, perhaps I'm at a disadvantage, because I have no sense of provenance of that list; nor any sense of how is being used. I just look at it and see a mis-hit - not comprehensive enough to be everything, but too comprehensive for real world usage
Richard Townley-O'Neill (Aug 06 2018 at 04:46):
In Australia there is a (still being developed) ValueSet for language common in Australia that will include local indigenous languages. We plan to bind to that in local specifications.
Grahame Grieve (Aug 06 2018 at 06:38):
do they even have valid codes?
Richard Townley-O'Neill (Aug 06 2018 at 23:03):
It's on the task list for the terminology to find some.
Michael Lawley (Aug 07 2018 at 22:28):
There is reference material: https://collection.aiatsis.gov.au/language/about - "AIATSIS assigns an alpha-numeric code to each language variety, with a community preferred name and spelling, to form a reference name"
Grahame Grieve (Aug 07 2018 at 22:28):
... which won't be valid in the language attribute...
Michael Lawley (Aug 07 2018 at 22:36):
there is also https://livingarchive.cdu.edu.au/language-codes-in-iso-639-3/ which appears to incorporate the work by AIATSIS up to certain limits
Liam Barnes (Aug 08 2018 at 00:26):
We have made efforts to extend http://hl7.org/fhir/ValueSet/languages, to include indigenous languages. We have a draft value set, https://healthterminologies.gov.au/fhir/ValueSet/common-languages-australia-1, including codes that we have submitted to the working group for BCP-47. We can't get a response from the working group.
Another issue is that the BCP-47 code system has no formal FHIR definition so any value set we create to extend the extensibly bound one in the spec will never expand nor can we validate (automatically) any code within it. If a FHIR code system definition becomes available and we still can’t get in touch with the working group to process our submission we may be able to author a complimentary but separate code system perhaps based on ABS but will look into your references also Michael. Adding a note that using codes outside of BCP-47 is obviously prohibited so this is just considering options.
Rob Hausam (Aug 08 2018 at 13:39):
@Liam Barnes I'm not sure which WG you are referring to in "can't get a response from the working group"? I note that PA recently resolved GF#16336 as Not Persuasive. I'm not seeing any open or not yet applied issues on this at the moment, but Vocab certainly would have an interest generally. If there's a particular tracker that I (or Vocab) have overlooked, let me know. I've run into the same issue with not being able to expand and validate these codes, and I would like to see that changed, too. Happy to work together with you to figure out the best way for that to happen.
Grahame Grieve (Aug 08 2018 at 20:02):
I thought Liam meant theW3C working group
Rob Hausam (Aug 08 2018 at 20:04):
yes, you're probably right - that makes sense but it didn't occur to me at the time
Liam Barnes (Aug 09 2018 at 05:12):
Sorry for the confusion. Yes I meant the group responsible for the language tag registry. Really what I mean is we've tried to contact IANA. I can't say we have a clear way forward. Firstly, if we can get our indigenous languages added to the registry we will at least have valid codes. As for the expansion/validation problem I don't fully understand the problem, other than there's no FHIR code system. Ideally, that would be available in the base spec but defining that code system could well be complicated by the various combinations of subtags possible.
Grahame Grieve (Aug 09 2018 at 06:16):
so there's no formal FHIR definition, but my server uses this as the source:
Grahame Grieve (Aug 09 2018 at 06:17):
https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
Liam Barnes (Aug 09 2018 at 06:44):
Does your server have any rules about the combination of different subtags in the registry?
Grahame Grieve (Aug 09 2018 at 07:14):
the grammar has to be followed. I don't any specific rules about combinations beyond that
Robert McClure (Aug 09 2018 at 20:48):
This is the best source I have found on how to construct language tags. It is very good. https://www.w3.org/International/articles/language-tags/index.en
Grahame Grieve (Aug 09 2018 at 21:01):
so where does this leave us? the reason I'm pushing back against this change is precisely because "The golden rule when creating language tags is to keep the tag as short as possible" - the proposed changes take a curated value set and blow that away with something that looks like a complete expansion but isn't. So it fails from both perspectives for me. And you (@Robert McClure) have still not provided any provenance information about that other value set
Last updated: Apr 12 2022 at 19:14 UTC
