We are using persistent compositions a lot in our system. These are 
compositions with content that lasts and might be updated several times. To 
make persistent compositions usable we have introduced “scope”. Examples of 
scopes is episode of care, period of care, ward stay, etc. A persistent 
compositions contains information where only the latest version holds the 
correct data.

So far we haven’t implemented (no need for) branching in versions. But I know 
that kind of requirements will come.

I think we should keep persistent compositions (and even extend them) and the 
versioning chapters in the specification. The conformance levels will tell what 
kind of functions that will be needed in the different profiles.

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10<tel:+47%2093%2043%2029%2010>

From: openEHR-implementers 
[mailto:openehr-implementers-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 
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<mailto: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<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

[https://docs.google.com/uc?export=download&id=0B27lX-sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]<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
_______________________________________________ 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
--
Ing. Pablo Pazos Gutiérrez Cel:(00598) 99 043 145<tel:099%20043%20145> Skype: 
cabolabs

[https://docs.google.com/uc?export=download&id=0B27lX-sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]<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
-- 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
_______________________________________________ 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

_______________________________________________

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
-- 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
_______________________________________________
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Reply via email to