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 <http://cabolabs.com/es/home>
------------------------------------------------------------------------
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
<mailto: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 <mailto:i...@freshehr.com>
twitter: @ianmcnicoll
Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
<mailto: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
<mailto: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 <mailto: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
<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:
erik.sundv...@regionostergotland.se
<mailto:erik.sundv...@regionostergotland.se>
(previously lio.se <http://lio.se>)
http://www.regionostergotland.se/cmit/
Linköping University:erik.sundv...@liu.se
<mailto:erik.sundv...@liu.se>,
http://www.imt.liu.se/~erisu/
<http://www.imt.liu.se/%7Eerisu/>
On Thu, Jun 11, 2015 at 10:30 AM, Sebastian Iancu
<sebast...@code24.nl <mailto: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
<mailto: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
<mailto: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
<mailto:openEHR-technical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Sebastian Iancu
mob: +31625588176 | email: sebast...@code24.nl
<mailto:sebast...@code24.nl> | skype: sebastian_iancu
Code24 B.V.
Comeniusstraat 5, 1817MS Alkmaar, The Netherlands
www.code24.nl <http://www.code24.nl>
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
<mailto: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
<mailto: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
<mailto:openEHR-technical@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
--
Sebastian Iancu
mob:+31625588176 | email:sebast...@code24.nl
<mailto:sebast...@code24.nl> | skype: sebastian_iancu
Code24 B.V.
Comeniusstraat 5, 1817MS Alkmaar, The Netherlands
www.code24.nl <http://www.code24.nl>
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
<mailto: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
<mailto: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
