Current modeling tools don’t allow to add constraints to the name field like we can add constraints to any other field on a LOCATABLE subclass. Names are special. Most of the time those just have an implicit constraint in the ontology part of the archetype, but in some cases names are constrained, and in those cases the only option is to set it as a DV_CODED_TEXT with one or more options.
- Note modeling tools don’t allow
alternativeconstraints for the name, that is: two sibling DV_TEXT/DV_CODED_TEXT constraints, and, - Tools don’t allow open constraints, like:
```adl
ELEMENT[at0007] occurrences matches {0..1} matches {
name matches {
DV_TEXT matches {*}
}
}
```
Though in other attributes of the RM we can do both things (alternatives).
The second one, the open constraint for the name, is specially useful if you want to formally model FOLDERs, since you need to allow FOLDERs to have any name, and with the current capabilities the only option is to set a DV_CODED_TEXT with all the possible options, which is not practical.
Another observation is that Archetype Designer and other modeling tools do not support archetypes for FOLDERs, tough I think LinkEhr does support it because it’s pretty generic, though I’m not sure if it supports the constraints I mentioned above (ping @damoca @yampeku).
If I would create a modeling tool tomorrow, I would allow both types of constraints in all the RM classes, EHR and DEMOGRAPHIC, but why isn’t that possible today? Is it a matter of self-imposed constraints from clinical modelers or we just assume that FOLDERs don’t need archetypes?