From Thomas comments, it is clear that we have such last two use
cases, internal versioning and cross-system versioning / sync /
consolidation.
Consider people here is talking about their own experience with the
specs under the use case they implemented. We can argue that internal
versioning is needed in 100% of the implementations while cross-system
is a much less implemented case. This doesn't mean that the current
specs are not usable and useful in abstract, but we should
contextualize the discussion by use case and by the frequency each is
implemented.
For internal versioning it is clear that distributed versioning spec
generate some friction at implementation time. IMO we need to address
both use cases trying to minimize friction for new developers. That
can improve the quality of the specs without print anything out.
Also, I would like to hear more about implementations of both use
cases and the challenges implementers had to really validate the idea
of addressing both use cases explicitly in the specs.
Cheers,
Pablo.
On Aug 18, 2017 5:39 AM, "Seref Arikan"
<serefari...@kurumsalteknoloji.com
<mailto:serefari...@kurumsalteknoloji.com>> wrote:
I did not realise that this discussion reached the point of
suggesting that distributed versioning is taken out from the
specs. I have been designing and implementing lots of openEHR data
syncing functionality which relies on the distributed versioning
specifications. I have heaps of work pending, which will also use
that part of the specs. I can tell you that the current specs have
worked just fine for me so far and they are up to the same high
quality as the rest of the specifications, so they are absolutely
usable and useful.
The challenges of distributed versioning does not eliminate the
need for them, so I cannot agree with the suggestion to remove
them. Sure, move them around in the specs all you want, but
please keep them.
All the best
Seref
On Fri, Aug 18, 2017 at 9:15 AM, Thomas Beale
<thomas.be...@openehr.org <mailto:thomas.be...@openehr.org>> wrote:
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
<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>
-- 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
<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
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
