Allow persistent Compositions to include event context.

The two choices are, I think,

Simply to remove the invariant, but I guess this may cause some backwards compatibility issues since a number of mandatory /context attributes then come into play.

The alternative is to add a new episode_persistent category which indicates that the commit strategy is persistent i.e continual updates of the same composition instance, but without the invariant. That might be simpler and potentially less disruptive.

My concern with a new code is then deciding which composition archetypes are persistent or episode_persistent, take care plan for example.
If the invariant is removed/changed to 0..1, then we can use the rm_version to determine if we should be enforcing 0..0 or allowing 0..1. We are opening the constraint which should be more acceptable than closing the constraint, it only affect new systems sending to old systems. We shouldn't be holding back progress.

I hadn't thought of changing invariant rule to make event_context 0..1 - I think that solves the problem very neatly.
+1 from me.

Is this only related to the tooling?
If not: Where can I find the definition that tells that a Composition of type persistent should not have event_context?
I find a textual description here: http://www.openehr.org/releases/RM/latest/docs/ehr/ehr.html#_overview_5
This states that event_context is not suitable for i.e. persistent compositions.

http://www.openehr.org/releases/RM/latest/docs/ehr/ehr.html#_overview_5

Invariant:

Is_persistent_validity: is_persistent implies context = Void