Hi Erik, That's seems a pretty good solution to me.
Ian On Thu, 9 Jul 2015 at 12:53, Erik Sundvall <[email protected]> wrote: > 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
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
