There is a "nice" thing in HL7 (yes, that is possible! :), when they define state or categorization data, associated with an HL7 terminology set (values should be chosen from a given set, can't be defined by the implementer), they also offer a "modifier". In the modifier the implementer can set it's own term set / codes. If you have more than one status matching one code on the standard code set, use modifier to establish the difference. Is a nice way of extension and allows a great deal of flexibility. What do you think about having a "lifecyce_state_modifier" attribute for VERSION? (just thinking out loud)
-- Kind regards, Eng. Pablo Pazos Gutiérrez http://cabolabs.com From: heath.fran...@oceaninformatics.com To: openehr-technical@lists.openehr.org CC: openehr-technical@lists.openehr.org Subject: Re: VERSION.lifecycle_state options Date: Thu, 9 Jul 2015 22:53:10 +0000 EHR Access control setting might be the way to apply these kin do policies also, but I do understand you want something universally understood, not just local policy. I am hoping we might be able to get to something like this when we start looking at EHR access settings. Regards Heath On 10 Jul 2015, at 6:23 am, "Ian McNicoll" <i...@freshehr.com> wrote: 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: i...@freshehr.com twitter: @ianmcnicoll Co-Chair, openEHR Foundation ian.mcnic...@openehr.org Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 9 July 2015 at 21:36, Sebastian Iancu <sebast...@code24.nl> 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 <erik.sundv...@liu.se> 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 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: erik.sundv...@regionostergotland.se (previously lio.se) http://www.regionostergotland.se/cmit/ Linköping University: erik.sundv...@liu.se, http://www.imt.liu.se/~erisu/ On Thu, Jun 11, 2015 at 10:30 AM, Sebastian Iancu <sebast...@code24.nl> 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" <sebast...@code24.nl> 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 openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Sebastian Iancu mob: +31625588176 | email: sebast...@code24.nl | skype: sebastian_iancu Code24 B.V. Comeniusstraat 5, 1817MS Alkmaar, The Netherlands www.code24.nl _______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Sebastian Iancu mob: +31625588176 | email: sebast...@code24.nl | skype: sebastian_iancu Code24 B.V. Comeniusstraat 5, 1817MS Alkmaar, The Netherlands www.code24.nl _______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
