FHIR Chat · Language for parameter "_text" · implementers

Stream: implementers

Topic: Language for parameter "_text"


view this post on Zulip André Sander (Apr 25 2020 at 18:17):

Hi, is there a way to specify the language in which the "_text" parameter for searching is given? This would be helpful, if one wants to search a for a code in a CodeSystem but only in a specific language. Also, it would be very helpful, if the search algorithm is not just a full text search but a more intelligent algorithm that is based on NLP things like stemming.
I don't want to use the "displayLanguage" parameter here because this should specify the output...
Thanks!

view this post on Zulip André Sander (Apr 25 2020 at 18:28):

For CodeSystem $find-matches could be used - this wouln't work for ValueSet, though

view this post on Zulip Lloyd McKenzie (Apr 25 2020 at 19:04):

If you were searching by language (e.g. French), what situations would you not want a match if the string you were searching by happened to declare itself to be English? It seems pretty unusual that you would find a string match in a different language and the meaning would not be what you were looking for? Is that situation common enough to justify adding the complexity of the new search feature?

The 'standard' search parameters are defined based on what we believe most systems currently do/can reasonably do. You're free to define custom search parameters that have different behavior - but you'd have to negotiate to get other clients or servers to support them. (In practice, not all servers even support the 'standard' search parameters...)

view this post on Zulip André Sander (Apr 26 2020 at 16:13):

In the operation "find-matches" you clearly might want to interpret an input string to find a matching code. This interpretation needs the language for different reasons: 1.) shortcut expansion (DM means something completely different in German, English, French and so on) 2.) tokenization/stemming 3.) disambiguation 4.) there are words in different languages that are spelled similiar but have a different meaning 5.) spelling correction (it would be nice if a German word would be corrected to a German one and not to an English one - it's even the case that a misspelled word in one language is a correct one in another - "bruch" is in German correct in English you might expect "brush") 6.) word completion (see 5) and last not least a full text search with patterns (a pattern like "ans*" would result in different expansions in different languages.
The documentation of FHIR even suggest to use implementations like Lucene/Solr for searching (http://hl7.org/fhir/search.html#text) which is a sample for a semantic search.

view this post on Zulip Grahame Grieve (Apr 26 2020 at 20:13):

I would think that the Accept-Language header would be the basis for the decision?

view this post on Zulip André Sander (Apr 27 2020 at 10:40):

Thanks - this is definitely a feasable solution!


Last updated: Apr 12 2022 at 19:14 UTC