On 09/07/2015 12:53, Erik Sundvall 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
Sebastian,
I think this is about right. I think 'immutable' in law and 'immutable'
in information systems have to be understood as different things. The
law is always local, so I think the best that could be done is a
standard kind of attestation whose reason for change was something like
: Re: VERSION.lifecycle_state options
Date: Thu, 9 Jul 2015 22:53:10 +
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
Nothing is ever ‘Complete’, improvements are always possible.
‘Final’ is not a good idea. I’ve seen different 'final’ versions of documents
and software more times than I would like.
How about “published {date; by whom; for what purpose; attestation}”. As with a
book, you can’t change what
I agree with Colin proposal.
2015-07-10 2:52 GMT+02:00 Colin Sutton colin.sut...@ctc.usyd.edu.au:
Nothing is ever ‘Complete’, improvements are always possible.
‘Final’ is not a good idea. I’ve seen different 'final’ versions of documents
and software more times than I would like.
How about
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
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
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
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
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
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 +
EHR
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
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
I suspect that the idea of 'final' requires something more like a
'locked for modification' flag. But nothing is guaranteed to be
immutable - what if the consent was given, and the committed information
was considered clinically 'final' but then a simple typo error (e.g.
patient name, or the
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
I think we need a clear definition of the difference between 'complete'
and 'final'...
On 10/06/2015 15:59, Sebastian Iancu wrote:
:) final is final! Even though consent was given on wrong data...
I guess if needed on application level it can be overruled under some
special conditions
16 matches
Mail list logo
