Hi Bert, see below On Wed, Jun 21, 2017 at 4:21 AM, Bert Verhees <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 <099%20043%20145> > Skype: cabolabs > <http://cabolabs.com/> > http://www.cabolabs.com > pablo.pa...@cabolabs.com > Subscribe to our newsletter <http://eepurl.com/b_w_tj> > > > _______________________________________________ > openEHR-implementers mailing > listopenEHR-implementers@lists.openehr.orghttp://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 > -- Ing. Pablo Pazos Gutiérrez Cel:(00598) 99 043 145 Skype: cabolabs <http://cabolabs.com/> http://www.cabolabs.com 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
