VERSION.lifecycle_state options

2015-06-10 Thread Sebastian Iancu
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

Re: VERSION.lifecycle_state options

2015-06-10 Thread Thomas Beale
I suspect that the idea of 'final' requires something more like a 'locked for modification' flag. But nothing is guaranteed to be immutable - what if the consent was given, and the committed information was considered clinically 'final' but then a simple typo error (e.g. patient name, or the

Re: openEHR @ StackExchange - getting close

2015-06-10 Thread Thomas Beale
We are getting closer http://area51.stackexchange.com/proposals/87508/openehrto the next step. We have 76 followers. We still need 17 questions with 10 votes. We have the requisite number of questions, it's just a case of people using their votes on them (don't worry if they don't really

Re: VERSION.lifecycle_state options

2015-06-10 Thread Heath Frankel
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

Re: VERSION.lifecycle_state options

2015-06-10 Thread Thomas Beale
I think we need a clear definition of the difference between 'complete' and 'final'... On 10/06/2015 15:59, Sebastian Iancu wrote: :) final is final! Even though consent was given on wrong data... I guess if needed on application level it can be overruled under some special conditions