Hi Sebastian, You could control this in a shared environment by using a coded text item in Attestation/reason.
I think this might work better than a 'standard' gneric lifecycle state since it allows you to very specifically identify the exact policy/legislation involved. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: [email protected] twitter: @ianmcnicoll Co-Chair, openEHR Foundation [email protected] Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 9 July 2015 at 21:36, Sebastian Iancu <[email protected]> wrote: > Hi Erik, > > I see where are you pointing to - that 'attestations' can indeed be one > solution to the problem. However I see this more as an application-level > functionality/feature; it can be (or not) interpreted the same way by a 3rd > openEHR system that might get that data. I feel safer having (also) the > options of a 'final-like' state flag of the version. > > Best regards, > Sebastian > > > > On 7/9/2015 9:32 PM, Ian McNicoll wrote: > > 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 > [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 Netherlandswww.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
