Hi,
I can rephrase my question: "How can I indicate that a version should
not be changed under any circumstances? How have other openEHR
implementations handling this issue (if ever occurred)?"
The use case I have is in mental-care in NL is that care providers are
setting up a care plan (which consists of many type of documents,
anamnesis, goals, planned schedule for evaluations, planned
interventions, actions, etc). During the initial phase of documenting
and planning most of these are in draft-mode (they are complete, but
perhaps need approvals, reviews or some are sometimes just considered as
proposals), but at some point in time some of them they need to be
fixated, any later change should be forbidden. It is like a contractual
relation between care providers and/or patient, it requires some sealed
papers.
Whats the best way to handle this? I'm not convinced this is a
modeling/archetype/template issue, I rather think is something that is
part of application layer, business logic, etc. but requires a 'flag' on
the backend data; hence my question/hint about VERSION.lifecycle_state.
If I would have the option to set it to 'final', I would of course only
use it for those object that is applicable (when I can guaranty that no
change is necessary/allowed); most of the time I would probably still
rely on 'complete'. Other openEHR implementations may not need to use
this 'final' feature if they allow in their versions may always be altered.
I'm ok to give (if necessary) a different name than 'final', as long it
reflects the use case I described above. I'm also ok to make a
compromise and use 'incomplete' where I actually need 'draft' (although
I see it as two different meanings). Alternatively I could also use
'complete' instead of 'draft' as long as I have and 'final' that pairs it.
@Heath: thanks for your examples and thoughts.
Regards,
Sebastian
On 6/11/2015 1:22 AM, Heath Frankel wrote:
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" <[email protected]> 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
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Sebastian Iancu
mob: +31625588176 | email: [email protected] | skype: sebastian_iancu
Code24 B.V.
Comeniusstraat 5, 1817MS Alkmaar, The Netherlands
www.code24.nl
_______________________________________________
openEHR-technical mailing list
[email protected]
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
