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
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
8 matches
Mail list logo
