Hi! I was just testing your fhir terminology server with some code system queries.
I was wondering if there’s any way (as there is in https://search.loinc.org) to set the language, so I can get translated values in valueCoding.display for all properties.
Any news about this? Being able to expand ValueSets with display values in other languages is a very important requirement for the usage of LOINC in FHIR implementations in Germany as well.
We’d love to know if this feature is somewhere on the roadmap!
This is something we will be exploring as we realize its importance for the community. We do not have a timetable for a potential release. It would probably be March 2020 at the earliest.
Are there any updates on multi-language support for the fhir-loinc api?
It’s a feature the Netherlands would really appreciate as well - to the point that using the LOINC FHIR API does not make much sense for us without it. And the API looks great, I’d love to incorporate it.
Is there any updates? It’s interesting for me also. I tried to define local designations in supplements, but poor outcomes.
This is still very much on our to-do list. As with many things, COVID destroyed our earlier timeline estimate. We are very much concentrated now on our upcoming LOINC release in December. I can only provide a very rough estimate of May 2021 for this language feature.
We will be adding the ability to retrieve specific LOINC version CodeSystem and ValueSet resources with our December release. (Initially, we will only make available the previous two releases.) We will be certain to share more information on this new feature at that time.
What is the status of a german translation of UCUM? I somehow found https://ucum.org/trac/ticket/200 that was updated 15 months ago, inviting a file update, but am unable to find further results?
Thanks in advance,
Why do you need a German translation? I presume you mean a translation of the specification…
I teach UCUM to my students at the university in Austria each year, and we just use the English specification.
I think it also a bit dangerous to have translations of specifications, as it may lead to different interpretations.
Great to hear from you. The client has asked for the units of measure to be in German; not the specification. I’m curious to get in touch with the owners of issue https://ucum.org/trac/ticket/200 to determine if they decided not to create a German UOM translation.
Looking forward to the interaction,
The units can not be “in German”. Units are units …
What they might mean that they want a notation for German namings of some units like “Zoll” (inches). Or do they want it as a “synonym” or “display-value” in the ucum-essence.xml?
If however UCUM starts adding such, that would open the door for thousands (or millions?) of new symbols, which would kill interoperability.
The other thing I can think of is that they want to standardize on UCUM “annotations”. As these are based on consensus within a community (e.g. I am trying to convince CDISC to do so for clinical research), this should then not be done by UCUM itself, but by that organization.
You or your client can always reach me by e-mail for more in-depth discussions.
In the Netherlands we maintain a translation of UCUM for some common measurement outcomes: https://labterminologie.nl/art-decor/lab-units. This is not maintained by UCUM, but by our own national standards organization (Nictiz).
Like Jozef notes, these are not translations of the units, but of the unit names or the composed descriptions such as found in UCUM’s TableOfExampleUcumCodesForElectronicMessaging.xlsx