Renaming a value in a specialization

Specifications ADL
1

So currently when redefining/specializing a value set, it is only allowed to limit a larger value set to a smaller one.

The constraint binding strength adds lot of possible things. However, it does not seem to handle the following situation:
a parent archetype, from the CKM, has correct concepts in the value set members. However the terms used do not correspond to the terms used by the intended target audience of this archetypes. Exact matching different terms are available
An example: Layman's translations - #16 by heather.leslie
but also Renaming in Templates with coded text constraint - #2 by ian.mcnicoll and Specialising value set items?

Now ADL 2 allows to specialize values, so in the parent:

ac1: 
  member at1: axilla

And in a template we would like to do:

ac1.1
  member at1.1: armpit

with the constraint being:

DV_CODED_TEXT[id25] matches {
    defining_code matches {[ac1]}
}

Now it is not allowed in c_value_conforms_to to specialize the id25 constraint into defining_code matches {[ac1.1]} , because the parent value set does not contain the code at1.1 - even though it does contain at1, which is a parent of at1.1. Link to relevant part of the specification:
https://specifications.openehr.org/releases/AM/latest/AOM2.html#_conformance_semantics_c_terminology_node
And in particular the line:
for_all v: this_vset | other_vset.has (v)
which does not take these specialised codes into account.

This cannot be fixed with the constraint status indicator, since it will often be required
in the parent.
Note that this also applies to templates, you cannot do this in a template.
Is this something that should be allowed?

1 Like
2

seems like if specialization is done right for the ac codes and only specialize things that are inside the parent subset this should be allowed. If new terms (non-specialized) are included in the ac code then Iā€™m not really sure that should be considered correct

3

Agreed. For adding new terms this construction is not suitable. But we do have a suitable way to do this with the required/extensible/preferred/example constraint status proposal.
This is just for renaming things, mainly in templates, which is not covered by that proposal at all, but which has real use cases.