Stream: terminology
Topic: Translate FHIR CodeSystems
Alexander Henket (Feb 14 2019 at 13:04):
@Grahame Grieve Suppose I want to contribute language translations for FHIR CodeSystems: where do I start? I know/knew what to do for V2/V3, but the FHIR CodeSystems do not appear to live in the GitHub source.
Grahame Grieve (Feb 15 2019 at 10:05):
they do live in the source
Grahame Grieve (Feb 15 2019 at 10:05):
there's 2 kinds of sources for the code systems - literal code system resources, and special ones in spreadsheets. What is a code system you want to provide translations for?
Alexander Henket (Feb 16 2019 at 15:03):
To start with the most common ones like AdministrativeGender, and the ones that have a required binding in resources we use
Alexander Henket (Feb 16 2019 at 15:05):
I'm trying to counter vendors that claim the don't have access to translations and so they cannot offer them to their users but all in all it's just more convenient for implementers to have them distributed in the core with Dutch rather than have every vendor do it themselves.
Grahame Grieve (Feb 17 2019 at 13:25):
that code system is defined in bindings.xml, which is a spreadsheet. There's a syntax for defining language translations in the syntax, but I think it's time that we started using the FHIR machinery there
Grahame Grieve (Feb 17 2019 at 13:27):
if you add a code system supplement named administrative-gender-[lang].xml (or .json) to the /terminologies directory with a canonical URL and id matching that file name, I'll update the tool to pick up the supplement
Grahame Grieve (Feb 17 2019 at 13:29):
really, I should decompose all of the contained value sets / code systems out of bindings.ini
Alexander Henket (Feb 18 2019 at 19:00):
I've added GF#20401. Working on testing the supplement right now
Alexander Henket (Feb 18 2019 at 20:37):
So far I cannot get it build into anything in the publish folder. No error either. My expectation would be a link from the CodeSystem it supplements. Could a tooling issue be at play, @Grahame Grieve ?
Alexander Henket (Feb 18 2019 at 20:59):
Should you want to try: I've attached the supplement the way I thought it would have worked to GF#20401.
Grahame Grieve (Feb 19 2019 at 01:09):
ok. Tooling doesn't support it at the moment - I'll have to do some work to pick it up and publish it
Alexander Henket (Feb 19 2019 at 19:43):
For the shorter term, we could have a look at my interpretation of what a supplement is supposed to look like. I've made a few assumptions after reading the spec that might not hold. Example:
I've translated every single thing about the concepts. display, definition, extension comment. I've done this by just adding the translation in the same elements as the original codesystem, but added CodeSystem.language = 'nl-NL' to indicate that the whole supplement is "Dutch as used in The Netherlands"
Christof Gessner (Feb 19 2019 at 20:05):
Any explanation why you didn't use CodeSystem/concept/designation here? Even if this might just be just a transfer file, to be integrated later in the "source of truth".
Christof Gessner (Feb 19 2019 at 20:14):
My suggestion would be to separate translation of concept/designation from translating codeSystem metadata like definition here. Different peopel working on it, different workflow, different use case . One might also want to add metadata in a specific language without providing language-specific designations. Designations could also be audio files, images, videos... Metadata probably not.
Christof Gessner (Feb 19 2019 at 20:17):
BTW: can a "formal definition" even be translated into another language? This is debatable, at least, unless we use formal logic languages for the definitions. Keep it simple.
Christof Gessner (Feb 19 2019 at 20:21):
One way out of this would be to "qualify" translated formal definitions away from the "real definitions" in a similar fashion like display is different from designation. display always uses the original display value from the codeSystem origin.
Alexander Henket (Feb 21 2019 at 09:07):
Well as this was my very first experience with a CodeSystem supplement I'm on a learning curve. I'm open to using designations for display if that is what should have been done. It was unclear to me from the specification.
As for the separation of concern: the nature of a supplement is that it is an artifact under its own governance. It may be merged into the CodeSystem it supplements, but until that day it acts as separate entity. It would very much like the Dutch supplements to be part of the core CodeSystems, because it is my expectation that no one will find them or know how to handle them otherwise. The outcome is currently unspecified.
One might also want to add metadata in a specific language without providing language-specific designations.
Yes, that is what a supplement aims to do too and there is actually a fine example in the core spec to that end. I would have appreciated a translation example too so I was less in the dark there. Maybe my efforts for Dutch could lead to a proper example if anything.
BTW: can a "formal definition" even be translated into another language?
In SNOMED CT the formal definition is the hierarchy and the FSN. You can translate those too right, so why not? With CodeSystems and supplements it is always clear that the source-of-truth definitions are in the CodeSystem. Supplements should not override any semantics from the CodeSystem it supplements, but if they do it is clear which one is leading. Same is true in SNOMED CT extensions I'd say
Lloyd McKenzie (Feb 21 2019 at 15:51):
It's always preferable to incorporate translations, properties, etc. in the source code system - but there's lots of reasons why the maintainer of a code system may not want to take that on. Supplements provide a work-around when the author of the code system doesn't want to/can't maintain the extra stuff. The meaning always comes solely from the CodeSystem.
Michael Lawley (Feb 27 2019 at 22:38):
In SNOMED CT the formal definition is the hierarchy and the FSN.
That's an interesting call. Technically (i.e., as per the spec) the "meaning" of a SNOMED CT concept comes from its FSN. The associated modelling (hierarchy and properties defined via the Description Logic axioms) are "only" approximations; they may be incomplete or even just wrong. In fact for some sub-hierarchies (qualifier value) the meanings are deliberately context (usage)-specific.
From a purist sense then, it would be incorrect to have a translated FSN. From a pragmatic perspective, however, SNOMED does support translated FSNs.
Alexander Henket (Mar 04 2019 at 23:28):
+1 for pragmatism then :-)
Alexander Henket (Mar 04 2019 at 23:31):
@Lloyd McKenzie when a supplement contains translations: this will be the first thing someone that cares about the translation looks at and consider it truth. The same way that translations of EULAs work: the master language/CodeSystem is the ultimate truth in case of doubt.
It probably doesn't even matter whether or not the translation is in the CodeSystem itself or in a supplement. The Dutch/Japanese/Russian/... reader will consider the translation before the original language.
Christof Gessner (Mar 05 2019 at 00:14):
well, I encountered some doctors who wanted to look at the verbatim narrative of their colleagues first, regardless of their original language. But that might be an exception.
Alexander Henket (Mar 11 2019 at 21:26):
Depends a number of variables probably. Background knowledge of the doctor, how much time he has on his hands, the seriousness of the patient condition, ... When I look at the Dutch Apache license: I'm glad a I got through that and really don't want to reread in English. If I'm diagnosed with cancer in Spain: I'll get a dictionary and go through my Spanish doctors scribblings word for word regardless of a SNOMED CT codified Dutch translations right next to it.
Michael Lawley (May 06 2019 at 20:15):
@Alexander Henket did you end up building any example CodeSystem supplements with translations? (that you can share)
Alexander Henket (May 06 2019 at 20:19):
I added it to the ticket GF#20401 I believe
Michael Lawley (May 06 2019 at 20:58):
Note there's a small error in the attachment: the content field should be supplement not complete (I'd comment on the ticket but I can't log in just at the moment)
Jose Costa Teixeira (Feb 18 2022 at 18:18):
how can we contribute a pt-BR translation of this codesystem? https://terminology.hl7.org/3.0.0/CodeSystem-v2-0131.html
Jose Costa Teixeira (Feb 18 2022 at 18:18):
@Carlos Augusto Lima de Campos
Jose Costa Teixeira (Feb 19 2022 at 20:23):
@Ted Klein ?
Rob Hausam (Feb 19 2022 at 20:30):
@Jose Costa Teixeira @Carlos Augusto Lima de Campos I think you should submit a UTG proposal and request adding the Brazilian Portuguese descriptions. I don't know if we have any policy about which and how many languages should be included, and how that will work with the publication, but submitting and working through the approval and application of the UTG proposal I assume may generate some discussion on that.
Ted Klein (Feb 19 2022 at 21:43):
We have several German translations of some concepts, as they have been published in the v2 standards for many years. We had a long discussion on the topic of such non-english language translations strings at a face to face WGM several years ago; a policy was not arrived at during that discussion. The best way at the current time is as Rob H says: put in a UTG ticket to add them.
Jose Costa Teixeira (Feb 20 2022 at 07:59):
I was expecting UTG to have its own Jira project but I can't find it in the dropdown.. Is this a FHIR ticket as usual (in which case I don't see UTG in the artifacts)?
Grahame Grieve (Feb 20 2022 at 11:15):
I would think that we should do these with supplements (unlike the german ones which aren't due to grand-fathering issues)
Alexander Zautke (Feb 20 2022 at 12:31):
Happy to move these German translations to supplements. This has been an outstanding task for HL7 Germany for a long time. It would be great if there was some documentation about what would be expected and where / how to submit content.
Jose Costa Teixeira (Feb 20 2022 at 15:26):
We can try to initiate a supplement (for PT translation). Where do we submit these supplements?
- To the core spec? We still need a Jira - against which part of the spec?
- To UTC? Where is that residing?
Jean Duteau (Feb 20 2022 at 18:33):
https://jira.hl7.org/projects/UP/issues/
NOTE: That it's not as simple as just raising an issue. You need to raise the change request and then provide the actual files to make the change: https://confluence.hl7.org/display/VMAH/Vocabulary+Maintenance+at+HL7
Rob Hausam (Feb 21 2022 at 15:17):
I think using supplements for this makes sense - in FHIR. But this is a V2 code system. The UTG process and THO publication should be able to handle adding these descriptions as a supplement, because it uses the FHIR IG machinery. But if there is expectation of using this in V2, then I'm thinking this isn't going to work - at least not yet, until V2 implementations are using FHIR terminology services to meet their terminology needs.
Grahame Grieve (Feb 21 2022 at 23:09):
what is the adoption process for v2 implementations of UTG?
Grahame Grieve (Feb 21 2022 at 23:09):
is there a process to generate the v2 database from UTG?
Last updated: Apr 12 2022 at 19:14 UTC
