Can we add 'final' to VERSION.lifecycle_state?
The use case is that in some circumstances a version need to become immutable and any change should be forbidden. Imagine a care plan that was already 'inform-consented' - it should not be allowed to be changed in any way, neither logically deleted (unless perhaps some administrative reasons). In contrast, by current version of specifications, a 'complete' version can be still changed or logically-deleted (which is valid behavior also).
A similar use case we have with 'draft'. Current specification supports 'incomplete' but that has a slightly different meaning. A 'draft' document can be complete and is in an 'awaiting' for an event (attestation) from which point may become 'complete' or 'final'.
Implementing these change will require 2 new codes in terminology and some adjustments in common_im.pdf. Perhaps a new change_type is also required.
Discussion@ SEC meeting:
probably want 2 things:
'final' is a human statement of intent, but can still be overwritten by new versions; probably would be set when an attestation is added.
'locked' is a machine-recognised state that prevents further versions - but this may be to restrictive.
Bjorn: persistent Compositions - used 'in context' in their system. May want a 'locked' state for that.
Possible meaning of 'final' = signed off, perhaps semi-legal status?
don't implement final as new lifecycle state; don't include 'locked' for now.
no global agreement of 'final'
querying that currently looks for just 'completed' won't find 'final' Compositions.
Wait for more evidence to appear - we still have a potential need to be able to mark Compositions as 'reviewed', 'signed off' etc.
Discussion @SEC 2019:
'final' should be interpreted as a guidance for normal change operation on the composition
possible solution is to use TAGs - but down side is not part of VERSION
partial solution to the problem above is to use ATTESTATION
another approach is to introduce a state before complete
need to discuss more