Hi Sebastian, To your general question, yes we needed something to indicate a version was moved distinct from deleted. This ensured that we couldn't undelete the version. There was a PR for this which included a new change type also.
To your usecases, I agree these are necessary but have concern about the term final. It doesn't seem to have the level meaning necessary for you use case as it is overloaded with pathology result status where a final can be corrected. Perhaps immutable is more specific. Similarly with draft, seems too similar to incomplete. What about unapproved or similar? As with all out terminologies, having too many similar options makes it hard to select the correct one unless the usecases are very clearly specified. I think you have very distinct usecases, we just need to get the right term to ensure it best reflects the usecase. Regards Heath > On 11 Jun 2015, at 12:03 am, "Sebastian Iancu" <sebast...@code24.nl> wrote: > > Hello all, > > Does anybody (with an openEHR persistence system/solution) encountered the > need to record other states than 'incomplete', complete', 'deleted' for a > 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). > > Regards, > Sebastian > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
