PARTICIPATION is not LOCATABLE, so has no archetype_node_id, but occurs in archetyped structures
Description
Environment
PR is addressed in
Activity
Joost Holslag February 28, 2022 at 5:04 PM
Hmm, I need a bit more help to answer your question. I’d say for normal situations participations (specific people) are only recorded at run time, is that what you’re asking?
Another issue is I can’t locate the COMPOSITION.referral on ckm/apperta/google/github. So it’s hard for me to know what the modelling pattern was.
It can surely be useful to archetype something that could be participations: e.g. to mandate recording of a “supervising clinican” in a discharge summary template with PARTICIPATION.function set to ‘Supervising clinician’. The performer attribute probably should be set at run time, since you often can’t know that at design time.
Thomas Beale February 28, 2022 at 2:50 PM
Revisiting this… I can see that PARTICIPATION inheriting from LOCATABLE would be useful since it allows standard approach to archetyping where each alternative has a node id. I think I didn’t do this in the original modelling on the basis that participations would only be run-time specified. I assume this is not longer true (maybe it never was) - maybe and can verify this.
As says, doing tihs means each PARTICPATION now needs a name value, but I think we can assume this just gets automatically set to the text of the id-code, so doesn’t seem like a big deal.
The real problem is the fact that it is a breaking change. The impact on software would not be too great, but data created using the old version would now have PARTICIPATION objects missing their name fields. To address this, either on-the-fly or one-off data migration has to be performed.
The other strategy is to do something like add a new PARTICIPATION2 (say) class as a sibling of PARTICIPATION, which is LOCATABLE; a new abstract parent would be needed as well. Then systems could plug in either PARTICIPATION or PARTICIPATION2. This is a standard schema evolution trick, but it makes models dirty, and there is still software impact.
Pablo Pazos May 9, 2015 at 4:51 AM
IMO that is true only for archetypes that specify Participation and it is mandatory. In other cases the participation might not appear in data instances.
Heath Frankel May 9, 2015 at 4:43 AM
The downside of this is we now need to specify a name for each PARTICIPATION. The need to specify a name on every LOCATABLE object is a real overhead and adds no value in most cases.
Ian McNicoll May 8, 2015 at 8:56 AM
+1
See for example the archetype openEHR-EHR-COMPOSITION.referral.v1.adl, which includes a PARTICIPATION in context.participations, but does not include an at-code, because PARTICIPATION is not LOCATABLE. However, the ADL 1.4+ rules state that any member object of a multiply-valued attribute must have an at-code, in order to distinguish it from sibling objects (even if added later).
Possible solutions: it might initially appear that an object can have an at-code in an archetype even if not LOCATABLE in the reference model, however the data will not carry the at-code, and the object cannot therefore be properly matched to an archetype node later on.