# Require / extensible / preferred - redefinition rules in specialised archetypes
**URL:** https://discourse.openehr.org/t/require-extensible-preferred-redefinition-rules-in-specialised-archetypes/1018
**Category:** ADL
**Created:** [7 October 2020 12:17 UTC](https://discourse.openehr.org/t/require-extensible-preferred-redefinition-rules-in-specialised-archetypes/1018 "2020-10-07T12:17:39Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [7 October 2020 12:17 UTC](https://discourse.openehr.org/t/require-extensible-preferred-redefinition-rules-in-specialised-archetypes/1018/1 "2020-10-07T12:17:39Z")
The final part of this change I have not yet specified, is the rules of specialisation of a terminology constraint node in a child archetype.
The default is ‘required’, and the rules are already described [here in the ADL2 spec](https://specifications.openehr.org/releases/AM/latest/ADL2.html#_terminology_constraint_redefinition).
For the other 3 settings in a parent archetype, we need to determine what is allowed in a child archetype. @pieterbos posted an [example parent archetype here](https://github.com/openEHR/archie/blob/eeadc726d0befb1d4e3fdd65bbf49d01a559bf07/tools/src/test/resources/com/nedap/archie/archetypevalidator/primitives/openEHR-EHR-CLUSTER.constraint_strength_parent.v1.0.0.adls). What is allowed in the child?
NOTE: here we are talking about creating child archetypes that still try to control the coding. Don’t forget, if the archetype says `extensible` or `preferred` or `example`, you can just put what you like in the data (it is if there is no constraint). But what if you want to create a specialised archetype that does want to state some further constraint on such a node?
For the `extensible` case, i.e.:
```auto
value matches {
DV_CODED_TEXT[id5] matches {
defining_code matches {extensible [ac1]}
}
}
```
You can use codes not in `ac1` if no code in `ac1` expresses what you need. To achieve that in a child archetype means creating some new `ac0.1` (or `ac0.22` or whatever the numbering is) that contains all the members of `ac1` (since they are still allowed), plus whatever new codes you want, which also have to be defined in the child archetype (or in any parent). You cannot use a redefined `ac1.1` to achieve this, since the latter is only allowed to narrow what is in `ac1`.
To obtain the effect of `ac0.1` including all of the members of `ac1`, we would need to change ADL2 / AOM2 to allow `ac` members of `ac` value sets, e.g.
```auto
["ac0.1"] = <
id = <"ac0.1">
members = <"ac1", "at0.3", "at0.4">
>
```
The above logic is the same for the other two settings, `preferred` and `example`.
Do we all agree on this?
---
### Author:  [@pieterbos](https://discourse.openehr.org/u/pieterbos)
#### Post date: [7 October 2020 12:41 UTC](https://discourse.openehr.org/t/require-extensible-preferred-redefinition-rules-in-specialised-archetypes/1018/2 "2020-10-07T12:41:04Z")
Is there an actual validation rule checking if ac1.1 contains only codes from ac1? I have not implemented that check in Archie, unless ac1.1 is actually used in a terminology code constraint specialising another. I assumed that check to depend on the constraint status/binding strength. Meaning that this required/preferred/etc keyword could influence the validation rule.
So: Is the rule needed that ac1.1 is always a subset of ac1, or can it also contain new codes in child archetypes, when used with a non-required binding strength?
Your second change:
If we allow for acx to be contained in a value set, I’m guessing we may want to change the OPT2 rules, saying that it replaces all “acx” members of value sets with its actual values. that means we could do this change without changing the applications using archetypes in OPT form.
It’s possible to not add this new option, by just manually adding the code. That means less changes in the AOM, modelling tools and applications - also slightly less functionality in case the parent archetype changes. I assumed without.
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [7 October 2020 13:03 UTC](https://discourse.openehr.org/t/require-extensible-preferred-redefinition-rules-in-specialised-archetypes/1018/3 "2020-10-07T13:03:36Z")
> [@pieterbos](#):
>
> Is there an actual validation rule checking if ac1.1 contains only codes from ac1?
The logic is [here](https://specifications.openehr.org/releases/AM/latest/AOM2.html#_conformance_semantics_c_terminology_node). At the moment, the validation code would just be VSONCT, as per [this section](https://specifications.openehr.org/releases/AM/latest/AOM2.html#_validate_specialised_definition).
> [@pieterbos](#):
>
> It’s possible to not add this new option, by just manually adding the code. That means less changes in the AOM, modelling tools and applications - also slightly less functionality in case the parent archetype changes. I assumed without.
Indeed, but the downside is that you are into copy/fork semantics, and if the archetype is in development, the automatic inclusion of the `ac1` value set into `ac0.1` won’t happen as intended.
---
### Author:  [@pieterbos](https://discourse.openehr.org/u/pieterbos)
#### Post date: [7 October 2020 13:19 UTC](https://discourse.openehr.org/t/require-extensible-preferred-redefinition-rules-in-specialised-archetypes/1018/4 "2020-10-07T13:19:33Z")
> [@thomas.beale](#):
>
> The logic is [here](https://specifications.openehr.org/releases/AM/latest/AOM2.html#_conformance_semantics_c_terminology_node). At the moment, the validation code would just be VSONCT, as per [this section](https://specifications.openehr.org/releases/AM/latest/AOM2.html#_validate_specialised_definition).
Yes, it is. But that is not actually checking the value set itself. That checks the value set as used in the context of a terminology code, in C\_TERMINOLOGY\_CODE:: c\_conforms\_to. It is currently very possible to create a value set ac1.1, adding new terms. Even using it in a C\_TERMINOLOGY\_CODE is possible, as long as it is not used in a specialised C\_TERMINOLOGY\_CODE that is constrained to ac1 in the parent archetype. So your statement:
> You cannot use a redefined `ac1.1` to achieve this, since the latter is only allowed to narrow what is in `ac1` .
Is only currently validated in the context of a specific C\_TERMINOLOGY\_CODE. And that specific validation is exactly what needs to be changed to make this feature possible. So, my question remains:
Is the rule needed that ac1.1 is always a subset of ac1, or can it also contain new codes in child archetypes, when used with a non-required binding strength?
> [@thomas.beale](#):
>
> Indeed, but the downside is that you are into copy/fork semantics, and if the archetype is in development, the automatic inclusion of the `ac1` value set into `ac0.1` won’t happen as intended.
True. I agree that it is clearly better in that aspect. I’m not sure how hard it is to do this change - we can prevent application changes by specifying the OPT2 generation, but all the modeling tools do need to be updated.
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [7 October 2020 14:57 UTC](https://discourse.openehr.org/t/require-extensible-preferred-redefinition-rules-in-specialised-archetypes/1018/5 "2020-10-07T14:57:08Z")
> [@pieterbos](#):
>
> Yes, it is. But that is not actually checking the value set itself. That checks the value set as used in the context of a terminology code,
Right - we need to add something to AOM2 for that.
> [@pieterbos](#):
>
> Is the rule needed that ac1.1 is always a subset of ac1,
yes that’s still the rule because that’s the golden rule (specialisation always narrows, not widens, any parent constraint).
---
### Author:  [@pieterbos](https://discourse.openehr.org/u/pieterbos)
#### Post date: [27 October 2020 16:10 UTC](https://discourse.openehr.org/t/require-extensible-preferred-redefinition-rules-in-specialised-archetypes/1018/6 "2020-10-27T16:10:40Z")
Proposed implementation of this proposal done in [https://github.com/openEHR/archie/pull/221](https://github.com/openEHR/archie/pull/221) . I can build the vscode-extension with this support if anyone wants to try what is possible, including what it does in validation and OPT creation. Just ask here if you want to try.
The addition also seems to solve [https://openehr.atlassian.net/browse/SPECPR-364](https://openehr.atlassian.net/browse/SPECPR-364) by expressing ‘this value set contains the other’.
---
### Author:  [@pieterbos](https://discourse.openehr.org/u/pieterbos)
#### Post date: [29 October 2020 12:55 UTC](https://discourse.openehr.org/t/require-extensible-preferred-redefinition-rules-in-specialised-archetypes/1018/7 "2020-10-29T12:55:36Z")
If anyone wants to try creating archetypes with the constraint strength, the proposed value set redefinition validation and the proposal for including value sets in other value sets, download visual studio code, open the command palette, press install from vsix and install the preview release .vsix file from [https://github.com/nedap/archetype-languageserver/releases/tag/v0.3.0-preview](https://github.com/nedap/archetype-languageserver/releases/tag/v0.3.0-preview) .
It will run the validation automatically, you can generate OPT with right click -\> source actions -\> generate OPT2. XML support currently broken, will be fixed soon.