Home › Forums › LOINC FHIR Terminology Server › Language/translations
- This topic has 11 replies, 8 voices, and was last updated 4 months ago by
Marc de Graauw.
-
AuthorPosts
-
2019-01-18 at 17:42 #24156
Denise Fernandez
ParticipantHi! 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.
For example:
* https://search.loinc.org/searchLOINC/search.zul?query=1975-2 (if I “Set Language” to Spanish/Argentina, then I get translated values in the search results)
* GET https://fhir.loinc.org/CodeSystem/$lookup?system=http://loinc.org&code=1975-2
(I’m using the same user for basic auth for rest api, and for log in at search.loinc.org)I tried:
– Adding displayLanguage=es-AR as a query param (as per https://www.hl7.org/fhir/operation-codesystem-lookup.html)
– Adding a header to the request Accept-Language=es-AR (as per https://hl7.org/fhir/2018May/languages.html##http)Thanks!
Denise.
-
This topic was modified 3 years, 7 months ago by
Denise Fernandez.
2019-10-29 at 07:24 #429482Simone Heckmann
ParticipantAny 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!
2019-10-29 at 08:49 #429483Tim Briscoe
KeymasterThis 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.
2020-04-14 at 15:04 #435660Alejandro Bologna
ParticipantHi
Are there any updates on multi-language support for the fhir-loinc api?
Thanks!
2020-05-18 at 04:13 #435914Marc de Graauw
ParticipantIt’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.
2020-11-25 at 10:06 #448538Marcelo Cabello
ParticipantIs there any updates? It’s interesting for me also. I tried to define local designations in supplements, but poor outcomes.
Thanks
Marc
2020-11-25 at 12:04 #448546Tim Briscoe
KeymasterHello Marc,
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.
2022-04-13 at 14:34 #474140Pam Banning
ModeratorHello!
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,
Pam
2022-04-14 at 00:38 #474141Jozef Aerts
ParticipantHi Pam,
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.2022-04-14 at 09:55 #474142Pam Banning
ModeratorHello Jozef!
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,
2022-04-15 at 01:00 #474146Jozef Aerts
ParticipantHi Pam!
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.
Best regards,
Jozef2022-04-19 at 03:34 #474152Marc de Graauw
ParticipantIn 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
-
This topic was modified 3 years, 7 months ago by
-
AuthorPosts
- You must be logged in to reply to this topic.