Dear All, Please remove me from this listserv.
Best, Danny On Sat, Aug 19, 2017 at 6:18 AM Bert Verhees <bert.verh...@rosa.nl> wrote: > I agree that merging is (normally) only interesting for persistent > compositions, that are the only kind of compositions which are candidat for > simultaneously editing (branching), and then afterwards merging of the > branches is needed. > > I think, getting rid of the persistent compositions would solve these > problems. I don't see objections against medication-lists in normal > compositions. Maybe the persistent composition idea was something from the > old days to have all medications handy together? > > If that is so, than we can consider that this way of preordening is not > anymore needed because modern systems can quickly find medication-entries, > and the extra advantage is that branching and merging is then also not > needed anymore. > > Best regards > Bert Verhees > > Op vr 18 aug. 2017 15:18 schreef Thomas Beale <thomas.be...@openehr.org>: > >> >> Naturally I am all for revising the specs (it's what we do ;) and >> throwing out dead stuff. But one thing I have realised over the years is >> that many of the scenarios (such as multi-system syncing) we thought of in >> the 1990s and early 200s are only just coming onto the radar now. Progress >> is much slower than many of us thought. >> >> Consequently, some types of implementation experience gained so far - >> particularly anything cross-enterprise or regional - is not going to be an >> indicator to the future. Of course, some kinds of experience, say with >> using the RM, or ADL 1.4, AQL etc, has been giving us all the feedback that >> we needed to make the updates we are currently making to the specifications. >> >> Probably what we should consider in this case is an update to the Change >> control spec that describes a variant or guideline for using the model to >> implement linear versioning, while allowing for later addition of branched >> versioning when/if needed. >> >> - thomas >> >> On 18/08/2017 12:49, Pablo Pazos wrote: >> >> 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> 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> >> 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> >>> 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 <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 >>> >>> -- 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 >> >> _______________________________________________ openEHR-implementers >> mailing list openEHR-implementers@lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org >> >> _______________________________________________ >> openEHR-implementers mailing >> listopenEHR-implementers@lists.openehr.orghttp://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 > > _______________________________________________ > 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
