Hi,
distributed versioning with branching was included to allow syncing of
data gathered about the same patient in different EHR repositories. For
most data, syncing the repos is trivial, since it's different data.
The classic cases of potential clashes is medication list, problem list,
basic clinical demographic data, etc. If a sync was started and two
medication lists are found that are forks of a single earlier one, a
manual merge will be required.
We are only just starting to see the implementation of systems where
syncing may be a question, so although there may be adjustments to make
to the branched versioning model, I would not be in favour of throwing
it out at this point.
We are however going to move it to the BASE component and make it a
standalone model.
- thomas
On 21/06/2017 09:19, Pablo Pazos wrote:
Hi Bert, see below
On Wed, Jun 21, 2017 at 4:21 AM, Bert Verhees <bert.verh...@rosa.nl
<mailto:bert.verh...@rosa.nl>> wrote:
Hi Pablo, I did it a few years ago, just dumped not-current
versions in a slow XML database, because, in normal cases they are
never queried, and when they need to be queried, there can always
be found a faster solution.
But of course, this was a linear version system. ExistDB supports
distributed versioning on XML out of the box. And you can also use
a normal, not OpenEHR, version system like Git or VCL.
But when looking at how OpenEHR works, is there ever need of
merging? Do people edit concurrently same datasets? I think they
are they always working on new versions of datasets, there is only
one exception, that is the persistent Composition, there could
occur merging problems.
The openEHR versioning mechanism is like Git. The problem I see with
this approach is that real users don't want to deal with that level of
complexity just to track changes in a distributed way. openEHR allows
branching, so if there is no merging, each user can be working on a
different branch, seeing just part of the data. Merging is complex,
but that is needed only if branching is allowed, so the problem is
really branching.
With branches, when a query is executed, it is getting data form the
latest version of the CURRENT branch, potentially missing data from
other branches. This might have patient safety issues also.
That is the main reason I ask this because it is not clear to me that
a good technical solution like distributed versioning, is the best for
EHRs. Moreover considering that most documents will have 1 or 2
versions at most (talking about event). Of course there will be more
versions for persistent compos.
*Thinking out loud, wouldn't be interesting to have an alternative
spec for versioning where only linear versions are allowed? (IMO that
would be easier to implement even though the current spec includes
that case).*
But I think, you don't need distributed versioning to handle this,
a locking system (like databases have) is, I think, good enough.
That is how classic EHR builders handle concurrency.
Bert
On 21-06-17 03:04, Pablo Pazos wrote:
Hi all,
I had this questions in mind for a long time: did someone
implemented the distributed versioning of openEHR?
The specs define a great distributed versioning mechanism but it
is a little trickier to implement. Also there is no clear who
will do the work of managing that, and how that structure will be
queried. It is very difficult to me to think of an amendment sent
to an EHR and that not being available for all the parties
looking at the EHR of the patient.
In the case of the EHRServer I built, only linear versioning is
possible, there is only one latest version for each compo, and
queries only get data from latest versions.
Just wondering, what do others did for versioning and what
policies do you have if you implemented the distributed approach
in terms of branching, merging and querying.
Thanks!
--
Ing. Pablo Pazos Gutiérrez
Cel:(00598) 99 043 145 <tel:099%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
<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 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
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
-- Thomas Beale Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Team, Intermountain Healthcare
<https://intermountainhealthcare.org/> Management Board, Specifications
Program Lead, openEHR Foundation <http://www.openehr.org> Chartered IT
Professional Fellow, BCS, British Computer Society
<http://www.bcs.org/category/6044> Health IT blog
<http://wolandscat.net/> | Culture blog <http://wolandsothercat.net/>
_______________________________________________
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
