Add ‘inactive’ status to lifecycle_state options

Description

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

Activity

Show:

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 AM
Edited

After the comments by I’m listing alternative solutions:

  1. 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.

  2. 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.

  3. 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

Done

Details

Reporter

Components

Priority

Created December 4, 2021 at 5:20 PM
Updated April 26, 2023 at 10:35 AM
Resolved April 26, 2023 at 10:35 AM