If it’s about the name of the report, yes I would use the name attribute, though the underlying models should allow that.
- If there is no constraint in the COMPOSITION.name and the only thing you have is the text of the ontology, then no, setting a new name shouldn’t pass validation, so you can’t post a composition with a different name than that, and if you are using something that allows that, it’s not validating correctly.
- Recently I opened this discussion Allowing open name constraint to support formal FOLDER models, why not? noting that the AD tool doesn’t allow to add constraints on names besides setting a DV_CODED_TEXT, though an open DV_TEXT constraint is perfectly valid/compliant, and even possible to do in the LinkEHR editor. Something like this should be in place in the archetype so your users can set any name:
COMPOSITION …. {
name matches {
DV_TEXT matches {*}
}
- With that, a data validator that complies with openEHR should allow any name at the COMPOSITION level. Note that should be in the archetype, not in the template, because having that in the template and not in the archetype would break the implicit constraint name nodes have in archetypes, which are setting a fixed value from the ontology, depending on a language (terminologic/linguistic constraint).
I remember having a similar use case, when we modeled generic questionnaires using a generic COMPOSITION and a generic ADMIN_ENTRY archetype to model the questionnaire/question respectively, and the question could have any name (open constraint), and the actual template was generated from an external dictionary of questions, following the generic archetype structure. So having that open constraint for the names was a crucial part of this, and I think I did that manually because of the constraints of current modeling tools not supporting that.
Hope that helps!