Require / extensible / preferred - redefinition rules in specialised archetypes

Specifications ADL
1

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.

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. 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.:

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.

["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?

2

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.

3

The logic is here. At the moment, the validation code would just be VSONCT, as per this section.

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.

4

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?

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.

5

Right - we need to add something to AOM2 for that.

yes that’s still the rule because that’s the golden rule (specialisation always narrows, not widens, any parent constraint).

6

Proposed implementation of this proposal done in 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 by expressing ‘this value set contains the other’.

7

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 .

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.

2 Likes