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]
<mailto:[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]
<mailto:[email protected]> (previously lio.se
<http://lio.se>) http://www.regionostergotland.se/cmit/
Linköping University:[email protected]
<mailto:[email protected]>, http://www.imt.liu.se/~erisu/
<http://www.imt.liu.se/%7Eerisu/>
On Thu, Jun 11, 2015 at 10:30 AM, Sebastian Iancu
<[email protected] <mailto:[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] <mailto:[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]
<mailto:[email protected]>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
[email protected]
<mailto:[email protected]>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Sebastian Iancu
mob: +31625588176 <tel:%2B31625588176> | email:
[email protected] <mailto:[email protected]> | skype:
sebastian_iancu
Code24 B.V.
Comeniusstraat 5, 1817MS Alkmaar, The Netherlands
www.code24.nl <http://www.code24.nl>
_______________________________________________
openEHR-technical mailing list
[email protected]
<mailto:[email protected]>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
[email protected]
<mailto:[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
