Hi! Is a new type of VERSION.lifecycle_state the best to solve the described use-case? Won't the "correcting a typo change" or "we forgot a thing" use-cases etc still always be there even for things written as binding contracts?
Is it perhaps enough to have the "final" plan fixed/fixated by applying digital signatures on the VERSION using the ATTESTATION <http://www.openehr.org/releases/trunk/UML/#Architecture___18_1_83e026d_1433773264996_418417_8398> class, thus marking the "contractual agreement" with digital signatures so that nothing be changed without the system (and/or users) noticing it. The application can then, for the type of change-sensitive documents described by Sebastian, perform signature checks and show warnings or refuse to update info unless the change is signed by the same persons or organisations that signed the previously signed version. To me it seems natural that binding contracts and signatures belong together. Heath's use-case "something to indicate a version was moved distinct from deleted" won't be solved by signatures though, so https://openehr.atlassian.net/browse/SPECPR-83 is still valid. Best regards, Erik Sundvall Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or 010-1036252 in Sweden) Region Östergötland: [email protected] (previously lio.se) http://www.regionostergotland.se/cmit/ Linköping University: [email protected], http://www.imt.liu.se/~erisu/ On Thu, Jun 11, 2015 at 10:30 AM, Sebastian Iancu <[email protected]> wrote: > 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 >
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
