As per Multilingual templates and templated value sets - Specifications - openEHR, it is actually possible to support multilingual value sets in the OPT format. This is an important functionality to us, and very likely also for others operating in a multilingual environment. Currently AD only supports monolingual templated value sets, as opposed to archetyped value sets which can be translated. Could this feature be enabled also for templated value sets?
Hi Silje,
It’s a bit of a grey zone, but it could be supported in .opt as follows;
<component_ontologies archetype_id="openEHR-EHR-OBSERVATION.atest.v0">
<term_definitions language="sl">
<items code="at0001">
<items id="text">History</items>
<items id="description">@ internal @</items>
</items>
<items code="at0002">
<items id="text">Any event</items>
<items id="description">@ internal @</items>
</items>
<items code="at0003">
<items id="text">Tree</items>
<items id="description">@ internal @</items>
</items>
<items code="at0004">
<items id="text">*DV_CODED_Internal (en)</items>
<items id="description"></items>
</items>
<items code="at0005">
<items id="text">Ena</items>
<items id="description"></items>
</items>
<items code="at0006">
<items id="text">Dve</items>
<items id="description"></items>
</items>
<items code="at0007">
<items id="text">Tri</items>
<items id="description"></items>
</items>
<items code="at0008">
<items id="text">*DV_CODED_Templated (en)</items>
<items id="description"></items>
</items>
<items code="at0000">
<items id="text">*aTest (en)</items>
<items id="description">*aTest (en)</items>
</items>
<items code="local_terms::1">
<items id="text">localterm_one</items>
</items>
<items code="local_terms::2">
<items id="text">localterm_two</items>
</items>
<items code="local_terms::3">
<items id="text">localterm_three</items>
</items>
</term_definitions>
</component_ontologies>
How does it sound to put local term(s) into term definition for each language? It looks good to me
Yep, it could be whatever is in this box, right?
So for this example, it’d be something like
<attributes xsi:type="C_SINGLE_ATTRIBUTE">
...
<children xsi:type="C_CODE_PHRASE">
...
<terminology_id>
<value>SNOMED-CT</value>
</terminology_id>
<code_list>182678001</code_list>
</children>
</attributes>
<term_definitions language="en">
...
<items code="182678001">
<items id="text">Hyposensitivation to allergens</items>
</items>
</term_definitions>
<term_definitions language="nb">
...
<items code="182678001">
<items id="text">Hyposensitivering for allergener</items>
</items>
</term_definitions>
(because do we really need the terminology_id::code
syntax in <items>
when the applicable terminology_id
for the relevant element is defined further up?)
Correct.
...
<items code="SNOMED-CT::182678001">
<items id="text">Hyposensitivering for allergener</items>
</items>
...
… and yes, we need the terminology_id::code_syntax.
It makes every item quite unique
I can live with that.
But what do you think about this?
<items code="SNOMED-CT::182678001">
<items id="text">Hyposensitivation to allergens</items>
<items id="description">A procedure involving exposing the individual to an allergen in a controlled environment, to reduce the body's sensitivity to the allergen.</items>
</items>
Adding description? Easy
@ian.mcnicoll you’re good with proposed solution for multi-language support in .opt for valuesets?
Looks good to me. I approve prepending the terminologyId. @sebastian.garde might have some thoughts here as well
I think at some time a few years ago we ended up adding brackets to the codes (e.g. [SNOMED-CT::182678001]) in order to be able to distinguish them from URI ones (e.g. http://snomed.info/id/182678001)
Second ones were needed for supporting ECL valuesets (e.g. http://snomed.info/ecl/<404684003:<<47429007=<<79654002 ) but I would assume it will also help when dealing with FHIR terminology service links (e.g. http://snomed.info/sct?fhir_vs=ecl/<<19829001 minus <<301867009 )