Stream: implementers
Topic: search by resource language
Rik Smithies (Mar 12 2021 at 14:41):
is this possible?
Lloyd McKenzie (Mar 12 2021 at 14:45):
If you could, I'd expect the search parameter to be defined here: https://build.fhir.org/resource#search
You can submit a change request to add it if you've got a use-case
Rik Smithies (Mar 12 2021 at 14:48):
yes thanks just wanted to confirm. In multi-language situations, such as product information leaflets for a supranational entity e.g. EU (or a country that has multiple languages, I assume), there is a need to search by language.
Lloyd McKenzie (Mar 12 2021 at 14:53):
Searching by Resource.language won't necessarily tell you whether the resource includes translations
Lloyd McKenzie (Mar 12 2021 at 14:53):
In general, we still haven't done a lot of work here
Rik Smithies (Mar 12 2021 at 14:54):
yes that is true. There can be translations, and you can also use xml:lang inside the text of a document, I believe.
Rik Smithies (Mar 12 2021 at 14:55):
The only one that could be easily searchable would be "_language"
Rik Smithies (Mar 12 2021 at 14:57):
For this use case a language specific resource is probably more acceptable to the users.
Rik Smithies (Mar 12 2021 at 14:57):
No one wants to be a "secondary" language
Morten Ernebjerg (Mar 12 2021 at 16:01):
@Rik Smithies I would second a the request for such a search parameter - I was also surprised that it does not exists. For us, one concrete use case is that we have Questionnaires in multiple languages, recognizable by the value in the language element. Then it definitely makes sense to asks for e.g. all Questionnaires in German. It is true that one can specify a preferred language using that Accept-Language HTTP header (see here in the spec). But I find it confusing to have to go outside the normal search language for a single parameter and the _format parameter already doubles smt. that can also be specified by headers.
Pash (Mar 12 2021 at 16:35):
As a workaround, I guess, you can use Meta.tag and duplicate language there. It is searchable.
Rik Smithies (Mar 12 2021 at 16:36):
thanks @Morten Ernebjerg . I have not noticed that page before. Strange that it is not linked from some of the places like http://hl7.org/fhir/narrative.html#lang
That indicates that not all text has to have a primary language, and a secondary translation.
I was also thinking that resource.language could benefit from being 0..*. There would then be not always be a "primary" language, but that is probably a good thing.
It would allow searching for any resource that has text in that language.
@Pash that is a good idea for the short term yes, better than an extension
Rik Smithies (Mar 12 2021 at 16:38):
I also wonder how many servers support the http Accept-Language header
Rik Smithies (Mar 12 2021 at 16:40):
Some documents do have multiple languages, though it would not be common for other resources to mix them
Morten Ernebjerg (Mar 12 2021 at 16:50):
@Rik Smithies Yes, I also think that page is easy to miss, which in a sense is an indication that (as Lloyd said) this is relatively untravelled territory.
Re. multiple languages. I see you point. In our specific use case where we provide the same resources in multiple languages, the language is always unique and serves to differentiate between different linguistic flavours of the same questionnaire (similar how Questionnaire.version differentiates between versions). But I suppose even then, one could have multiple languages. On ingredient lists on foods, Danish, Swedish, and Norweigan are often squashed into one entry because they are deemed "sufficiently interoperable" :smile:. Either way, being able to search it seems useful.
Rik Smithies (Mar 12 2021 at 17:02):
I have a drug leaflet here that is in Finnish and Swedish in one document. I will make a proposal.
René Spronk (Mar 13 2021 at 08:08):
@Rik Smithies I created a I18n presentation for our training courses, and I did ask the authors of the main public servers whether they supported Accept-Language, but it appears none of them support this out of the box.
René Spronk (Apr 12 2021 at 08:45):
Do you happen to have implementation experience with multi-lingual support ? That is, where it's of importance to search for, or persist, FHIR data in multiple languages? I'll be presenting on the topic of 'multi language support in FHIR' at the upcoming DevDays, and it would be nice to add some project based guidance / best practices to the presentation. Any hints or best practices ?
Morten Ernebjerg (Apr 12 2021 at 09:33):
@René Spronk Very worthy topic! We do a lot for work with questionnaires in multiple languages, running in web or native apps. To keep things simple for the apps, we create language-specific versions of the "definitional artifacts" (Questionnaires and associated ValueSets) so that the apps can simply grab them off the shelf to match the current language setting. An example of this is our IG to document the FHIR output of a COVID-19 questionnaire app that supports both English and German (also discussed this a bit in my community talk at the last DevDays). We went about it as follows (though I think it's too early to sell this as best practice :smile: ):
- Use very simplistic (custom) templating to generate language-specific Questionnaire instances from a single template
- Generate language-specific extensions of ValueSets from CodeSystems (or code system supplements) with translations in the
CodeSystem.concept.designationelement - Always fill the
languageelement in these resources (and the generated QuestionnaireResponses) - Where needed, serve the "definitional artifacts" using a custom service that allows asking for a resource in a particular language.
René Spronk (Apr 12 2021 at 12:20):
Re: language specific value sets: using the $expand displayLanguage parameter? What about HTTP Language support, should displayLanguage not be present ?
René Spronk (Apr 12 2021 at 12:21):
Re: definitional artifacts - need not be a 'custom' service in case of HTTP Language support (but I realize few systems actually support this right now)
René Spronk (Apr 12 2021 at 12:23):
Thanks for the comments - I didn't have anything on Questionnaires up to now. Could your 'custom templating' have been done using FHIR extensions to some sort of 'master questionnaire' as well? (I'm not saying that this would be asier to implement, just asking for the sake of clarification) @Morten Ernebjerg
Morten Ernebjerg (Apr 12 2021 at 14:15):
Our set-up is a little unusual because we have an end-to-end encrypted system, meaning that the data server is "blind" (holds only encrypted data it cannot read) and so the clients have to do the heavy lifting. Accordingly, we cannot use a normal powerful FHIR server with a REST-interface to run everything over - we tend to have smaller back-end services with quite targeted functionalities. I'm not an expert on the service for the definitional resources, but I don't think it used a FHIIR API since it was entirely internal and very focussed on very specific tasks (and needed to support language-based retrieval :smile: ) . ValueSets were pre-expanded when the underlying code system changed and then stored for serving. All in all, this is presumably quite different from the server-centric situation in most places, but like you indicate one could take some of the same approaches with a normal FHIR server.
I suppose one could embed translations in a single Questionnaire through extensions or designations, though I must admit I never though it through deeply. One important goal for us was to make the final resources as simple as possible for the clients to handle, so for us it made sense to move the heavy lifting to "compile time" (definitional resource update) and generate multiple single-language artifacts up front. I build the tooling in TypeScript during the early hectic COVID-19 days, so templating was also simply faster than full (or even partial) extension support.
Tilo Christ (Apr 12 2021 at 16:30):
You could do this here:
"text": "Check the box if the following statement is true. The average air speed velocity of a laden European swallow is greater than a laden African swallow.",
"_text" : {
"extension" : [
{
"extension" : [
{
"url" : "lang",
"valueCode" : "de"
},
{
"url" : "content",
"valueString" : "Bitte hier ankreuzen, wenn die folgende Aussage wahr ist: Die Höchstgeschwindigkeit der unbeladenen europäischen Schwalbe ist höher als die der unbeladenen afrikanischen Schwalbe."
}
],
"url" : "http://hl7.org/fhir/StructureDefinition/translation"
}
]
},
I have a feeling there must be more elegant ways than to attach 15 lines of extra JSON per language to each text element.
René Spronk (Apr 13 2021 at 06:51):
Feel free to use the "I^" based FHIR-syntax ;-)
Rik Smithies (Apr 29 2021 at 22:19):
I have added https://jira.hl7.org/browse/FHIR-32020 for searching on meta.language
Morten Ernebjerg (Apr 30 2021 at 06:10):
@Rik Smithies excellent :tada: (btw, language is a top level property in Resource it's not inside meta)
Jens Villadsen (Jul 27 2021 at 09:14):
Rik Smithies said:
I have a drug leaflet here that is in Finnish and Swedish in one document. I will make a proposal.
I believe @Craig Anderson and I are also very interested in this as we are looking into filtering package leaflets based on language
Jose Costa Teixeira (Jul 27 2021 at 09:26):
For questionnaires (and presumably for product leaflets), I wouldn't do many resources - rather one resource with translations. I agree with the need for "search for resources that declare this language"
but I expect the functionality to be
"get me this resource and display the content in this language"
Jens Villadsen (Jul 27 2021 at 09:29):
Wait a moment ... you can actually filter/search by language using HAPI:
image.png
- and it actually works as intended
Jens Villadsen (Jul 27 2021 at 09:29):
that does not make it standardized though
Jens Villadsen (Jul 27 2021 at 09:31):
@Jose Costa Teixeira I guess that depends on the use case. For me the translation MUST be authorized one, meaning that the translation should be mastered and preferrably not executed by the client but instead be provided by the backend
Jose Costa Teixeira (Jul 27 2021 at 09:31):
Right, same here
Jose Costa Teixeira (Jul 27 2021 at 09:32):
The translation is authorized, but i'd only have one resource. One resource with authorized translations, instead of N authorized translated resources
Jens Villadsen (Jul 27 2021 at 09:33):
In that case you don't need language as search parameter
Jens Villadsen (Jul 27 2021 at 09:34):
and you would have to update the entire resource whenever you would change the wording for just one of the languages
Jens Villadsen (Jul 27 2021 at 10:07):
@Jose Costa Teixeira or am I missing your point?
Jose Costa Teixeira (Jul 27 2021 at 10:10):
you are correct
Jose Costa Teixeira (Jul 27 2021 at 10:10):
(you'll have to update the published artifact with all the translations when you need to change an accent in one of the languages)
Jose Costa Teixeira (Jul 27 2021 at 10:11):
this discussion is the same we're having in #questionnaire which is a good candidate for requiring translations
Rik Smithies (Jul 27 2021 at 11:03):
The idea of multiple languages may work in some resources, but it's not so good for documents.
There the granularity reflects that of the source documents and the business process.
If they are authored in different places at different times it isn't practical to combine them into one resource. They want to stay as a single document in one language and not one document with alternating paragraphs. The document will be authored differently, could be dated, signed etc, so it may need to be a single document in one language.
Jose Costa Teixeira (Jul 27 2021 at 12:32):
Right, if we use documents that are themselves authored in different languages, I think that is valid.
If the document is issued from content that is itself multilingual, we can rely on the translation features (Sure, we could have a different construct, but it is what we have to express the same thing in different languages).
A discharge summary is a document that is authored in one language.
Jose Costa Teixeira (Jul 27 2021 at 12:33):
A questionnaire would be authored in one language and then can be translated string by string (as translators do).
Jose Costa Teixeira (Jul 27 2021 at 12:35):
I'll have to check around here (3 languages), but a product leaflet is a collection of information, much of it is hopefully coded, and I don't see why I wouldn't use the translation extension for the content - which doesn't invalidate that I could still have create a $document which contains only the selected language. But that document is no longer the master, I think.
Jose Costa Teixeira (Jul 27 2021 at 12:36):
(as opposed to the discharge summary, where the physician will only produce content in one language)
Rik Smithies (Jul 27 2021 at 13:37):
Product leaflets are moving towards coded, but for a long time at least there will be a document version that represents what the patient will read. And structured info but not directly in the same resource yet.
In theory all this could be in one clever resource, but the document resource is not really meant to be set of documents or parts capable of being partly rendered on demand.
An issue with a translation is that it seems it is always one primary language plus a translation. That is not always politically correct.
Jose Costa Teixeira (Jul 27 2021 at 15:15):
We visited those arguments against some time ago, which is why I mentioned my perspective.
Jose Costa Teixeira (Jul 27 2021 at 15:17):
In terms of main language, yes, especially when people want to find arguments. So far I've escaped this by making things in English and then translating to the official languaes
Craig Anderson (Sep 13 2021 at 15:07):
Jens Villadsen said:
Rik Smithies said:
I have a drug leaflet here that is in Finnish and Swedish in one document. I will make a proposal.
I believe Craig Anderson and I are also very interested in this as we are looking into filtering package leaflets based on language
Might have responded to the wrong thread so repeating here again. I believe each language should be a separate document. However, we’ll add this to our list of questions for EMA to confirm for us.
Craig Anderson (Sep 14 2021 at 16:51):
Jens Villadsen said:
Rik Smithies said:
I have a drug leaflet here that is in Finnish and Swedish in one document. I will make a proposal.
I believe Craig Anderson and I are also very interested in this as we are looking into filtering package leaflets based on language
Hey @Rik Smithies , confirmed with EMA this morning that all languages are separate documents. Then each document tracked within the List (Master List).
Rik Smithies (Sep 14 2021 at 18:10):
hi @Craig Anderson I am not sure we have completely ruled out multiple language documents at EMA. In general if there is a translation, then that becomes another FHIR document. But product documents originated in multiple languages do exit. We still need to search by language, whether it is one or multiple I guess.
Craig Anderson (Sep 14 2021 at 19:59):
@Rik Smithies, correct. Just mean that if you have a Greek, Norwegian and English PIL then that means three documents. You wouldn’t merge all three languages into one document. And yes, regardless user would probably want to search by language
John Moehrke (Sep 14 2021 at 20:03):
translations would result in a transform. This is the concept available in DocumentReference.relatesTo
Rik Smithies (Sep 14 2021 at 20:33):
@Craig Anderson indeed there is no merging.
@John Moehrke we don't plan to use DocumentReference.relatesTo. It implies one is the main one and the other secondary, which is not always the case. Unless both point at each other, which then means you have to change the original to add a translation. It doesn't work well for a set of documents in multiple languages (e.g. 10 languages). Also there are other relationships between documents that are just as important but aren't covered by relatesTo, so it would need different mechanisms. We settled on using List as an external index.
John Moehrke (Sep 14 2021 at 20:49):
would welcome comments to help improve DocumentReference
Last updated: Apr 12 2022 at 19:14 UTC
