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
'fi
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
ists.openehr.org
CC: openehr-technical@lists.openehr.org
Subject: 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 ju
I agree with Colin proposal.
2015-07-10 2:52 GMT+02:00 Colin Sutton :
> 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 who
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 someo
te_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 opti
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 J
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
mob
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 (al
Hi Erik,
That's seems a pretty good solution to me.
Ian
On Thu, 9 Jul 2015 at 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 th
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 apply
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 (whi
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
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 (spec
:) 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 (special administrative rights, timeframe, owner, etc.).
But I was looking more for a 'flag' to signal that a specific version
cannot be cha
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
16 matches
Mail list logo