There is use for COMPOSITION archetypes where the “category” attribute is not set in the archetype, but rather something that can be set in a template instead. For example an archetype that, depending on context, would be reusable both in an “Episodic” template and also in another template where category “Presistent” or “Event” would be set instead.
Thus an unconstrained alteranative would be good to have in adition to the three radio-button alternatives in the lower right corner of the following screenshot.
Hi Erik,
I share this requirement, I think it’s just a feature request for AD, right?.
I would also like to consider an editorial policy of not constraining the category in archetypes and only setting it in templates. Especially the episodic vs persistent can be arbitrary. @heather.leslie and @siljelb what are your thoughts?
Archie seems to think it’s valid adl2 to only set a category in the template btw:
I am only interested that the specs/tooling support use cases, so neutral in principle to the request.
However, I am curious about the use case for COMPOSITIONs that need to be non-specific. All use cases I’ve come across seem to be either event-based or persistent. If there are ‘grey-zones’ or ambiguous situations, I wonder about whether the semantics are clear enough?
Yes event vs persistent is usually clear. There are/were some problems where persistent ckm archetypes have an event category due to a (now solved) limitation of using event context archetyping.
The ambiguity for me is mostly in episodic vs persistent. E.g problem list can be considered persistent and episodic depending on the context of the deployment.
2 Likes
@joostholslag, I assume you ment “only setting it in templates”.
P.S.
I believe it would also be theoretically possible to specify multipe (e.g. two) specific categories as valid. For example constraining an archetype to a choice between “episodic” and “persistent” if needed.
Whoops, yes, just edited my mistake, thanks.
What would the ADL look like for specifying two choices?
And could you please share your usecase for unconstraint category?
Our use case was similar to yours, that “E.g problem list can be considered persistent and episodic depending on the context”.
1 Like
The constraint is based on specification: COMPOSITION.class
category is a mandatory attribute and values/codes are defined from openEHR terminology group ‘category’.
According to specification you could define a Composition archetype (ADL) with a list of possible values for a category and later either constrain it in the template or actually define it per composition (record). In theory.
However setting Event / Persistent might have some implementation constraints - which is why values are not left arbitrary open.
1 Like
Coming late to this - could we make the default, for a new archetype to constrain in all 3 options, soon to be 4 codes, tot be further constrained in the archetype if appropriate but also allow further constraint in templates
This would not disrupt existing archetypes and get around the mandation issue. We can then constrain appropriately in templates. There are definitely some blurred categories e.g some problem lists are episodic and not longitudinal
2 Likes
