# Expanded Version lifecycle - implementers need to consider impact

**Category:** [RM](https://discourse.openehr.org/c/rm/42)
**Created:** 2022-08-13 21:09 UTC
**Views:** 444
**Replies:** 1
**URL:** https://discourse.openehr.org/t/expanded-version-lifecycle-implementers-need-to-consider-impact/2922

---

## Post #1 by @thomas.beale

All,
[SPECRM-107](https://openehr.atlassian.net/browse/SPECRM-107) is the one @joostholslag got us started on, which was to add some kind of obsolete or archived state to the Version state machine. The main scenario was something like a Care Plan or other episodic Composition that has become no longer pertinent to care. We eventually settled on the new state name `inactive`. 

Further analysis by the smart people at Nedap exposed the fact that just one extra state won't do what is needed, because you need a kind of 'inactive' for `incomplete`state Compositions.

The solution has been to add a further new state `abandoned`. [See here in the revised Common IM](https://specifications.openehr.org/releases/RM/latest/common.html#_version_lifecycle) for what the additions look like. 

This change might well have more impact that implementers initially expected, so I'd like all vendors / implementers to have a good look at this CR and the changes it entails.

Pinging the following just as a start: @Seref , @kjejor , @matijap , @birger.haarbrandt , @pablo , @sebastian.iancu , @Sidharth_Ramesh , @pieterbos , @rong.chen

---

## Post #2 by @sebastian.iancu

From our (Code24) point of view these changes are welcome, and the impact is reasonable / manageable.

---


**Canonical:** https://discourse.openehr.org/t/expanded-version-lifecycle-implementers-need-to-consider-impact/2922
**Original content:** https://discourse.openehr.org/t/expanded-version-lifecycle-implementers-need-to-consider-impact/2922