Hi Eric, good story, but one remark, I understand from your story that
you favor branching above locking. Because when you do locking while a
composition is in edit mode, you don´ t need branching, and the merging
becomes much easier. In fact, there is no merging when there is no branching
When you do locking of a composition in edit mode, every one wanting to
edit a composition always works on the latest version.
Locking of a data-set when taking it into edit mode, is not something
very exotic to do. In fact, it is common practice all over the world. I
never heard of an information system supporting branching, and for good
reason.
Branching is used in source-code files, but even there, it is avoided as
much as possible. All programmers can imagine the trouble that comes to
them when at the end of a working day, the version control system
refuses to store a change in a file because it was edited simultaneously
by someone else who posted it before.
You say, care providers should solve the branching/merging by calling
the one who edited a composition simultaneously to find an agree about
what to do with the merge.
And what if that other care-provider has gone home, maybe for a long
period, after a week of night shifts, what should one do? Keep the
composition in edit-mode? And causing more trouble and more branches and
more merges and more agreements to find, because others need to edit the
composition too? And what happens with the people wanting to read the
composition, what do they read, the latest posted version (so all the
edit-states are not accessible?)
I think this is a undesired solution. I think the locking system, in the
end, is more safe also for the patient.
Bert
On 23-08-17 10:03, Erik Sundvall wrote:
Hi!
Shared care-plans, medication lists and allergy lists often need to be
updated by several care providers that have different EHR-systms
separated by both legal and practical/technical barirers; for example
regional vs municipal care in Sweden or private vs public care providers.
Today in (usually non-openEHR contexts) that is often done by either:
1. using a separate shared system just for shared care plans etc
(which means a degree of double data entry and manual transfer/reentry
of things from/to different EHR systems that the patient has records
in at different care providers)
or
2. forcing everybody to use the EHR system of the "biggest" care
provider in the (or that systems shared care planning module). Pretty
convenient for the big actor but a mess for the other smaller ones,
especially those that have a patient mix from several different "big"
providers using the "use my system" attitude...
So yes the multi-provider shared records with branch/merge
capabilities are certainly needed if we want to avoid #1 and #2 above.
And yes merge will be a headache for users when it occurs, but likely
less of a headache in total than #1 and #2 above. I believe enough of
the subgroup of clinicians dealing often with shared care will become
proficient enough to handle merging.
The "lock" approach (only allowing one party to change at a time)
would only work if things were entered and synced fast and at once
after the care event had happened. In reality a doctor may read
version 12 of the medication list when seeing the patient on Friday
and audio-record an update (that should become version 13), that gets
transcribed and recorded in the EHR after the weekend. During the
weekend the patient needs to go to another care provider (e.g.
emergency) that also looks at version 12 (since that is the latest
recorded one) and immediately after the consultation records a version
13. See the merge conflict? In this case it might need to be resolved
by the care takers contacting each other to agree on possibly
conflicting persciptions. What happens today without openEHRs ability
to at least detect a merge conflict is not always good for patient
safety.
Many openEHR implementations today are single-care provider systems
and then you don't handle/detect the conflicts using the system, but
hopefully some other way.
I agree that a distributed versioning could be specified as optional
in some openEHR conformance profile for single-care provider systems,
but it should certainly not be taken away from the openEHR
specifications! This also means that the version identifiers used in
the specs (e.g.
8849182c-82ad-4088-a07f-48ead4180515::ehr.examplecareprovider
.org::12) should still contain the system id (e.g.
ehr.examplecareprovider .org) even in single-care provider systems so
that they can later be upgraded (or their possibly signed data can be
moved) to a system capable of full distributed versioning.
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 Mon, Aug 21, 2017 at 10:58 PM, Pablo Pazos
<pablo.pa...@cabolabs.com <mailto:pablo.pa...@cabolabs.com>> wrote:
I agree. The singleton is not one persistent compo, but the
instance associated with an OPT of a persistent compo. When
talking about singleton instances we should define what is
considered the "class" :) My mistake.
In the case of care plans, different care plans will be defined by
different OPTs, same for medication lists if needed and modeled
that way (some systems might only need one medication list, one
problem list, etc. by EHR).
But again, these are all clinical modeling decisions. A bad model
might represent different care plans with the same OPT, and of
course this breaks the singleton concept, but we are talking about
subjectiveness here, so there are no hard rules (call it
probabilistic singleton).
Best,
Pablo.
On Mon, Aug 21, 2017 at 5:40 PM, Bert Verhees
<bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>> wrote:
Pablo, one small remark, a persistent composition is not
really a singleton. Not conceptually. A patient can have more
care - plans, for example, at different care - institutions or
multiple care - takers at a single institution, or have
multiple medication-lists.
Bert
On ma 21 aug. 2017 19:24 Pablo Pazos <pablo.pa...@cabolabs.com
<mailto:pablo.pa...@cabolabs.com>> wrote:
Hi Bert, excellent questions!
On Aug 21, 2017 5:55 AM, "Thomas Beale"
<thomas.be...@openehr.org
<mailto:thomas.be...@openehr.org>> wrote:
On 21/08/2017 09:09, Bert Verhees wrote:
On 21-08-17 02 <tel:21-08-17%2002>:51, Pablo Pazos
wrote:
@Bert Persistent records are a well know
pattern in ehrs and it's usefulness should not
be under question. Of course systems that
focus on primary care might not implement
them. But for hospital or even regional /
national records need a wider view of the
patient, persistent shows their value.
Hi Pablo, two questions
Which problem do you solve with persistent records
which cannot be solved in another way? Do you
agree that persistent records are the only reason
to have branching/merging necessary?
well they are likely to be the most common element of
an EHR to which branches and merging would be applied.
However they are ubiquitous and are also likely to be
extended to things like care plans and so on. But in
principle, branch and merge could happen to anything
in the record, e.g. for reasons like adding competing
translations of clinical notes etc.
- thomas
Adding to Thomas, we can view this from three points of
view: technical implementation, clinical modeling, and
spec. My previous comments about persistent records are
spec related. As Thomas said, _how_ things are done using
the spec will depend on modelers, and also implementers.
From the spec, I see persistent records as a framework to
record everything that is conceptually a Singleton (one
instance across the whole patient EHR). Then if that can
or can't be modeled as an event record, is a discussion
for clinical modelers, but I think that doesn't diminish
the need of such a concept on the specs.
Versioning and branching is an ortogonal concept to
event/persistent records and can be used in any case. The
_how_ versioning/branching is used has a lot to do with
implementers and that is related to my initial question,
and the hunch that maybe other devs like me found
branching/merging an friction point (related to
complexity) for the most frequent & simple implementations
of openEHR, but knowing there are less frequent
implementations that make extensive use of branching and
merging.
From the current answers to this thread, I see the need of
a simplified or relaxed versioning model, that maybe is
just a constraint over the current version control,
allowing only certain versioning patterns, like lineal
versioning, and some control mechanisms like versioning
lock/release, access to read-only records, etc. These are
not changes to the current spec, but additions as specs or
as guidelines.
What do others think?
_______________________________________________
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
<mailto:openEHR-implementers@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
<http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org>
_______________________________________________
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
<mailto:openEHR-implementers@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
<http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org>
_______________________________________________
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
<mailto:openEHR-implementers@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
<http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org>
--
Ing. Pablo Pazos Gutiérrez
Cel:(00598) 99 043 145 <tel:+598%2099%20043%20145>
Skype: cabolabs
<http://cabolabs.com/>
http://www.cabolabs.com <http://www.cabolabs.com/>
pablo.pa...@cabolabs.com <mailto:pablo.pa...@cabolabs.com>
Subscribe to our newsletter <http://eepurl.com/b_w_tj>
_______________________________________________
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
<mailto:openEHR-implementers@lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
<http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org>
_______________________________________________
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
_______________________________________________
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
