@siljelb for context, a name: DV_TEXT attributes in the RM (which is an attribute of all LOCATABLE subclasses, from COMPOSITION to CLUSTER and ELEMENT, passing through OBSERVATION and EVENT, etc), by the specs is just a normal attribute that can be constrained.
By the AOM, for a DV_TEXT attribute you can:
- Define a single DV_TEXT constraint, which could use the C_STRING ( Archetype Object Model 1.4 (AOM1.4) ) constraint on the DV_TEXT.value, with all possible primitive constraints.
- Define a single DV_CODED_TEXT constraint, which can use the C_CODE_PHRASE constraint (from the archetype profile spec), which is a subclass of C_DOMAIN_TYPE from the AOM 1.4 spec ( Archetype Object Model 1.4 (AOM1.4) ).
- Have multiple alternative constraints (since name is a single attribute, it will be constrained by the C_SINGLE_ATTRIBUTE class from AOM (link above), then in its
children you can have two or more constraints for DV_TEXT (like in 1. but two siblings that are alternatives) or two, or more, DV_CODED_TEXT alternatives or a mix of DV_TEXT and DV_CODED_TEXT constraint alternatives.
In that list, what you are asking for is point 2. which is actually supported by the Archetype Designer, and IIRC by the Archetype Editor too, also @damoca mentioned that’s supported by LinkEHR. I have created this archetype yesterday in the AD to test queries in Atomik:
openEHR-EHR-OBSERVATION.alternative_name_constraints.v0.adl (3.1 KB)
Though I tested on the Archetype Designer, where 1. and 3. are not possible.
Point 1. is important because on some cases we might want to allow “any” name, which is in the case of the FOLDER, the problem is that FOLDERs are not normally constrained by archetypes, and formally they should, because: a. FOLDERs are LOCATABLES and LOCATABLES are archetyped, again, we have a normal RM class that has special treatment, b. technically we have syntactic validation and semantic validation (against ADL and/or OPTS), not having an archetype or template formally linked to a FOLDER, makes them to be a special case in terms of validation. There is a real issue about having all this “special” cases, it makes the RM/AOM not really generic, adding complexity to implementations that need to handle a lot of things as exceptional/special cases (a FOLDER shouldn’t be different than a COMPOSITION in modeling or data management).
Point 3. is important because that’s what the AOM allows modelers to do, and if modeling tools don’t support what could be done anywhere else in the RM, we are constraining what modelers can do. It’s not a matter of “this won’t be used” it’s a matter of “if the openEHR specs allow this, we should allow it”, and I think that was the approach on LinkEHR, sadly it’s not being used by most modelers today.
Having alternative constraints basically says, for instance, we allow this DV_TEXT with these constraints … and we also allow this DV_CODED_TEXT with these constraints …, and the actual name in the data should comply with one of those types and constraints to be valid.
Side note:
What I realized is that while our RM claims to be generic, the LOCATABLE.name is a very special attribute, for which adding DV_TEXT constraints might not be possible because of the ontology: all names are defined by the nodeID in archetypes and the entry in the ontology with text and description, for each supported language. The problem is that the translation is not considered a normal constraint in AOM, it was just designed outside the AOM framework. This is a very deep realization: first, the AOM is not expressive enough to allow adding linguistic constraints (translations), and, second, we have special cases in our RM which are managed outside the ‘normal’ framework. If we were able to constrain any DV_TEXT node in the same way, and supporting linguistic constraints, our models would be truly generic. Just a thought.
