Add ‘inactive’ status to lifecycle_state options
Description
PR is addressed in
Activity
Sebastian Iancu December 13, 2022 at 10:02 PM
in Terminology Release 2.4.0 added following concepts:<concept id="800" rubric="inactive"/>
<concept id="801" rubric="abandoned"/>

Joost Holslag March 20, 2022 at 9:21 AMEdited
After the comments by I’m listing alternative solutions:
Assume the latest ‘complete’ version of a composition is active. Downside: Often the content is technically complete but inactive until there is approval by a senior clinician.
Use event_context to record the clinical lifecycle status. Downside: 1. “Event”context name is semantically problematic for non event status meta data. 2. making a version active now requires a change to the content requiring a new version to be committed, that feels ugly.
Add an attribute to VERSION <(COMPOSITION)> for “(‘CLINICAL’_)STATUS”. Downside: 1. how do we make sure this is not inconsistent with the highly related LIFECYCLE_STATE 2. Feels like to big a change and thus require more thought on other related status info (see thread linked at 2.1)

Joost Holslag December 4, 2021 at 7:42 PM
It may make sense to add immutability for archived. The assumption will be valid in our usecase. And we will probably not support editing of archived compositions. But I’m not sure it’s best done in the lifecycle state, since it will require implementation work in the CDR, and I’m not sure it’s worth the effort. Since other strategies to implement the behaviour may be more efficient e.g. in frontend client app.
And I’m not 100% sure archived versions of compositions should be immutable. This will also prevent eg adding comments to the version as to why it’s been archived. While that may be useful. And I think if we specify expected behaviour, implementers should be able to rely on the assumption that’s always true. For interoperability reasons. Or what is the openehr policy regarding expected behaviours like this?
We could go with recommending immutability, but that feels like the worst of two worlds.
So I’m ok if it’s decided immutability is specified as expected behaviour for archived versions. But I’m leaning towards the position there’s too little value to make it worth the effort and risk.
Ian McNicoll December 4, 2021 at 6:49 PM
Do we need to add some behaviour change, as well as the flag. Ie archived means read-only. That makes sense to me from what I understand.
Then we have
Incomplete. Not normally queryable and no validation of mandatory fields. I think this covers at least one flavour of draft
Complete. Active and normally queryable
Archived. Queryable but read-only. I understand the value in care planning g episodes. We gave an example where a patient leaves the locality. Need to keep the record and possibly still visible but locked.
Deleted. Not queryabkr and read only

Joost Holslag December 4, 2021 at 5:22 PM
Similar PR: https://openehr.atlassian.net/browse/SPECPR-125
Details
Details
Reporter

We have a need to indicate a version of a stored episodic care plan composition is no longer ‘active’. So we request addition of a 4th status to openEHR vocabulary version lifecycle state: ‘archived’.
Relevant spec:
https://specifications.openehr.org/releases/RM/latest/common.html#_version_class
More info:
https://discourse.openehr.org/t/archived-status-for-care-plan-composition-archetype/1927