Re: Versioning implementations

So, what happens is that (for example) one healthcare-enterprise has created a care-plan, which is to use by more care-providers on different computer-systems/network/database (another healthcare-enterprise). When on the same system/network/database there are things like locking to solve this.

Re: Versioning implementations

The branching model in the specs is actually not designed to deal with competing editors in the same computing environment (that's taken care of by the optmistic locking rule already in openEHR); it's designed to allow for the possibility of an original resource such as Care Plan or a

Re: Versioning implementations

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

Re: Versioning implementations

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

Re: Versioning implementations

Hi Bert, excellent questions! On Aug 21, 2017 5:55 AM, "Thomas Beale" wrote: On 21/08/2017 09:09, Bert Verhees wrote: > On 21-08-17 02:51, Pablo Pazos wrote: > >> @Bert Persistent records are a well know pattern in ehrs and it's >> usefulness should not be under

Re: Versioning implementations

On 21-08-17 12:18, Thomas Beale wrote: On 21/08/2017 10:45, Bert Verhees wrote: On 21-08-17 10:54, Thomas Beale wrote: 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

Re: Versioning implementations

On 21/08/2017 10:45, Bert Verhees wrote: On 21-08-17 10:54, Thomas Beale wrote: 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.

Re: Versioning implementations

On 21-08-17 10:54, Thomas Beale wrote: On 21/08/2017 09:09, Bert Verhees wrote: On 21-08-17 02: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

Re: Versioning implementations

On 21/08/2017 09:09, Bert Verhees wrote: On 21-08-17 02: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 /

Re: Versioning implementations

On 21-08-17 02: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

Re: Versioning implementations

Hi Danny, You can unsubscribe from the same page you've subscribed. http://www.openehr.org/community/mailinglists On Mon, Aug 21, 2017 at 1:11 AM, Danny Nguyen wrote: > Dear All, > > Please remove me from this listserv. > > Best, > > Danny > > On Sat, Aug 19, 2017 at 6:18

RE: Versioning implementations

penehr.org] *On Behalf Of *Bert Verhees *Sent:* lørdag 19. august 2017 15:17 *To:* For openEHR implementation discussions <openehr-implementers@lists. openehr.org> *Subject:* Re: Versioning implementations I agree that merging is (normally) only interesting for persistent composit

Re: Versioning implementations

Dear All, Please remove me from this listserv. Best, Danny On Sat, Aug 19, 2017 at 6:18 AM Bert Verhees wrote: > I agree that merging is (normally) only interesting for persistent > compositions, that are the only kind of compositions which are candidat for >

Re: Versioning implementations

I notice the versioning discussion. Is see three different topics; (non-)Persistent, versioning and synchronisation/consolidation. I see no use of non-persistant flags. I see two reasons for versioning. Synchronisation,consolidation is too complex for now. ERS systems document events. Each

RE: Versioning implementations

s-boun...@lists.openehr.org] On Behalf Of Bert Verhees Sent: lørdag 19. august 2017 15:17 To: For openEHR implementation discussions <openehr-implementers@lists.openehr.org> Subject: Re: Versioning implementations I agree that merging is (normally) only interesting for persistent

Re: Versioning implementations

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

Re: Versioning implementations

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

Re: Versioning implementations

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,

Re: Versioning implementations

Hi Bert, see below On Wed, Jun 21, 2017 at 4:21 AM, Bert Verhees 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

Re: Versioning implementations

We have the data structures set up in our database to handle branching and merging. But we do not yet support it for users and do not currently have plans to build it. The merge process looks like it could be complicated for users. Regards, Pieter Bos Op 21 jun. 2017 om 03:06 heeft Pablo