Multilingual templates and templated value sets

Hi all!

When creating multilingual templates with templated value sets (ie value sets for text elements where the values are included in the template and not the archetype), it seems like there’s a limitation that prevents us from providing those value sets in more than one language. I seem to remember that this has been discussed before, but I can’t find the discussion. Is this a known limitation, and if so how can we fix or work around it?

I’m pretty sure it is a limitation of ADL1.4. I might be interesting to see if it is actually supported in AD native json which is heavily based on ADL2 (which should solve the issue, at least for local template-level text terms, which I think could just be handled as internal codes.

@joostholslag @pieterbos -can you comment on internal codes added a template level in ADL2?

On which note, it looks as if we are now getting real momentum amongst the various CDR and tooling implementers in getting the transition to ADL2 (or at least past 1.4) over the line.

2 Likes

In ADL 2 there is no such limitation - the terminologies for every part of a template can be defined n as many languages as desired, for all node names, value sets and values.

4 Likes

It’s great if this will be solved in ADL2+, and that transition isn’t too far off anymore. But can we work around this in the shorter term?

The only workaround I can think of is to use FHIR Valuesets, which can can carry translations. The real blocker is the ADL1.4 .opt format which simply does not have a way of carrying atcoded items introduced at template level.

This problem about multilingual templated value sets is again rearing its ugly head at us, and it’s likely we’ll get more and more of it in the coming months and years. I’m sure this is an issue also for others operating in a multilingual environment, such as Wales, Luxembourg, Catalonia or Switzerland? (@mar.perezcolman @vanessap @tarabonet @amanda.herbrand ?)

I’ve tested making multilingual templated value sets in ADL2 templates in Archetype Designer, and it doesn’t seem to work there either. For non-coded text value sets it seems to work exactly like in ADL1.4, and for coded text value sets I can’t even save the template. Error message when trying to save: (@borut.fabjan)

Error
Could not parse archetype local/openEHR-EHR-COMPOSITION.t_test_adl2.v1.adls.
Reason RuntimeException: com.nedap.archie.adlparser.ADLParseException:
Error: syntax error at 216:71: [@1481,7050:7050='}',<8>,216:71]. msg: mismatched input '}' expecting {'-', '+', '|', DATE_CONSTRAINT_PATTERN, TIME_CONSTRAINT_PATTERN, DATE_TIME_CONSTRAINT_PATTERN, DURATION_CONSTRAINT_PATTERN, '[', SYM_USE_NODE, SYM_USE_ARCHETYPE, SYM_ALLOW_ARCHETYPE, SYM_AFTER, SYM_BEFORE, ISO8601_DATE, ISO8601_TIME, ISO8601_DATE_TIME, ISO8601_DURATION, SYM_TRUE, SYM_FALSE, ALPHA_UC_ID, INTEGER, REAL, STRING}

In any case, we’re going to need a way to handle this problem relatively soon. Are the only possibilities either adopting a FHIR terminology server, or adding ADL2 template functionality to DIPS? Neither seem to be anywhere on the horizon from my point of view (maybe @bna or @kjejor can reassure me?)

We just did a test on this which worked very well. Both names and value sets are defined in the ontology for each language.

When we changed the terms in the OPT the translated values was present in our Form solution.

There should be tooling support for such translations. But with some handiwork it works pretty well.

Thanks to @siljelb for the cooperation on this.

2 Likes

Yep! The translation section looks like this in the OPT exported from Archetype Designer:

<term_definitions language="nn">
...
    <items code="654576457">
        <items id="text">Noko</items>
    </items>
    <items code="477968546">
        <items id="text">Noko anna</items>
    </items>
</term_definitions>

The only thing missing is actually being able to define the different translations in Archetype Designer. This structure should also support adding a <items id="description"> section for each value, so that should ideally also be an option in AD.

1 Like

Could the items element have a language attribute, i.e.,

<items language="zh-CN">

?

1 Like

The term definition is within a group of language specific items.
There will be one group for each exported language.

You can see this from @siljelb s example above. Where nn is one two official languages in Norway

1 Like

Thanks, @bna. Can such a group have a cardinality of 1…*? I mean for manual editing.

1 Like

Each definition group like

<items code="477968546">
        <items id="text">Noko anna</items>
</items>

or

<term_definitions code="at0044">
    <items id="text">Ytterligere detaljer</items>
    <items id="description">Strukturerte detaljer eller spørsmål om kartleggingen av diagnostiske undersøkelser.</items>
</term_definitions>

is tightly bound to a container, data element or value from a value set. So it doesn’t have its own occurrences setting.

But for each language in the template, there will be a separate
<term_definitions language="nn" />
group, containing all of the <items /> for that language.

2 Likes

Thanks, @siljelb.

Such normalization would help reduce the size of the group.