Allow persistent Compositions to include event context.

Description

See and
Consider whether other categories of Composition are needed.

Activity

Show:
Ian McNicoll
March 17, 2016, 7:40 AM

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.

Heath Frankel
March 17, 2016, 7:53 AM

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.

Ian McNicoll
March 17, 2016, 7:57 AM

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.

Bjørn Næss
March 17, 2016, 11:54 AM

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.

Ian McNicoll
March 17, 2016, 12:18 PM

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

Invariant:

Is_persistent_validity: is_persistent implies context = Void

Reporter

Thomas Beale

Raised By

Thomas Beale

Components

Affects versions

Configure