Re: Versioning implementations

[Bert Verhees]

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.


The original enterprise sends a message containing the care-plan, and 
the receiving starts integrating it in their own care-plan.


This happens a lot. A person was in a hospital, they wrote a care-plan 
for when at home again, to do some things. (take medication, for 
example). The care-provider at home (the GP, or nurse) already has a 
care-plan, and adds the information of the hospital. Everything cool.


Sometime later, the patient has to go back to the hospital, here was an 
unforeseen complication. The GP/nurse from the home situation, sends 
their care-plan to the hospital (in a message), so the specialist can 
see what has been done at home. Everything cool again, no branching 
needed. The message is stored, and some information of the message may 
be added to the care-plan of the hospital where the patient has to stay 
some time.


That is how the things go, in my country. But even there, to handle this 
simple information-transfer is hard enough. Even too hard. Hospitals, 
for example, still do not synchronize medication-information with the 
national health network.


I leave the discussion now. I think, branching and merging might be good 
in a perfect world, but in common practice, even sharing information in 
common messages, and coded with a good terminology is not yet reality. 
In Germany, for example, they do not use SNOMED-CT.


Best regards and thanks for your opinions.
Bert



On 23-08-17 21:41, Thomas Beale wrote:


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 Medication List originating from some provider enterprise, and being 
copied to another location and modified there, while still being 
modified in the original location. In a perfect world this would not 
happen, because such resources would be true singletons, sitting 
behind a single-point-of-truth service API that all applications 
talked to. Well, since the NHS realised they wanted that 10 years ago, 
they are no closer to it today. I've never seen anything like it in 
the US either; it might exist inside Kaiser somewhat, and maybe Beth 
Israel (due to Halamka) but otherwise, no. But forking and 
modification of resources does happen easily.


All the branching model ensures is that the mods made by people at 
different 'systems' end up on branches specific to those systems, so 
that if the data are ever copied back to an original location, a safe 
machine merge can in fact happen, because the branches won't clash - 
this ensures no data are lost. A true content merge is still 
potentially required, which will most likely be manual.


- thomas


On 23/08/2017 20:27, Bert Verhees wrote:
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


When you do locking of a composition in edit mode, every one wanting 
to edit a composition always works on the latest version.


Locking of a data-set when taking it into edit mode, is not something 
very exotic to do. In fact, it is common practice all over the world. 
I never heard of an information system supporting branching, and for 
good reason.
Branching is used in source-code files, but even there, it is avoided 
as much as possible. All programmers can imagine the trouble that 
comes to them when at the end of a working day, the version control 
system refuses to store a change in a file because it was edited 
simultaneously by someone else who posted it before.


You say, care providers should solve the branching/merging by calling 
the one who edited a composition simultaneously to find an agree 
about what to do with the merge.


And what if that other care-provider has gone home, maybe for a long 
period, after a week of night shifts, what should one do? Keep the 
composition in edit-mode? And causing more trouble and more branches 
and more merges and more agreements to find, because others need to 
edit the composition too? And what happens with the people wanting to 
read the composition, what do they read, the latest posted version 
(so all the edit-states are not accessible?)


I think this is a undesired solution. I think the locking system, in 
the end, is more safe also for the patient.


Bert




On 23-08-17 10:03, Erik Sundvall wrote:

Hi!

Shared care-plans, medication lists and allergy 

Re: Versioning implementations

[Thomas Beale]

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 
Medication List originating from some provider enterprise, and being 
copied to another location and modified there, while still being 
modified in the original location. In a perfect world this would not 
happen, because such resources would be true singletons, sitting behind 
a single-point-of-truth service API that all applications talked to. 
Well, since the NHS realised they wanted that 10 years ago, they are no 
closer to it today. I've never seen anything like it in the US either; 
it might exist inside Kaiser somewhat, and maybe Beth Israel (due to 
Halamka) but otherwise, no. But forking and modification of resources 
does happen easily.


All the branching model ensures is that the mods made by people at 
different 'systems' end up on branches specific to those systems, so 
that if the data are ever copied back to an original location, a safe 
machine merge can in fact happen, because the branches won't clash - 
this ensures no data are lost. A true content merge is still potentially 
required, which will most likely be manual.


- thomas


On 23/08/2017 20:27, Bert Verhees wrote:
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


When you do locking of a composition in edit mode, every one wanting 
to edit a composition always works on the latest version.


Locking of a data-set when taking it into edit mode, is not something 
very exotic to do. In fact, it is common practice all over the world. 
I never heard of an information system supporting branching, and for 
good reason.
Branching is used in source-code files, but even there, it is avoided 
as much as possible. All programmers can imagine the trouble that 
comes to them when at the end of a working day, the version control 
system refuses to store a change in a file because it was edited 
simultaneously by someone else who posted it before.


You say, care providers should solve the branching/merging by calling 
the one who edited a composition simultaneously to find an agree about 
what to do with the merge.


And what if that other care-provider has gone home, maybe for a long 
period, after a week of night shifts, what should one do? Keep the 
composition in edit-mode? And causing more trouble and more branches 
and more merges and more agreements to find, because others need to 
edit the composition too? And what happens with the people wanting to 
read the composition, what do they read, the latest posted version (so 
all the edit-states are not accessible?)


I think this is a undesired solution. I think the locking system, in 
the end, is more safe also for the patient.


Bert




On 23-08-17 10:03, Erik Sundvall wrote:

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 (usually non-openEHR contexts) that is often done by either:
1. using a separate shared system just for shared care plans etc 
(which means a degree of double data entry and manual 
transfer/reentry of things from/to different EHR systems that the 
patient has records in at different care providers)

or
2. forcing everybody to use the EHR system of the "biggest" care 
provider in the (or that systems shared care planning module). Pretty 
convenient for the big actor but a mess for the other smaller ones, 
especially those that have a patient mix from several different "big" 
providers using the "use my system" attitude...


So yes the multi-provider shared records with branch/merge 
capabilities are certainly needed if we want to avoid #1 and #2 above.


And yes merge will be a headache for users when it occurs, but likely 
less of a headache in total than #1 and #2 above. I believe enough of 
the subgroup of clinicians dealing often with shared care will become 
proficient enough to handle merging.


The "lock" approach (only allowing one party to change at a time) 
would only work if things were entered and synced fast and at once 
after the care event had happened. In reality a doctor may read 
version 12 of the medication list when seeing the patient on Friday 
and audio-record an update (that should become version 13), that gets 
transcribed and recorded in the EHR after the weekend.  During the 
weekend the patient needs to go to another care provider (e.g. 
emergency) that also looks at 

Re: Versioning implementations

[Bert Verhees]

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


When you do locking of a composition in edit mode, every one wanting to 
edit a composition always works on the latest version.


Locking of a data-set when taking it into edit mode, is not something 
very exotic to do. In fact, it is common practice all over the world. I 
never heard of an information system supporting branching, and for good 
reason.
Branching is used in source-code files, but even there, it is avoided as 
much as possible. All programmers can imagine the trouble that comes to 
them when at the end of a working day, the version control system 
refuses to store a change in a file because it was edited simultaneously 
by someone else who posted it before.


You say, care providers should solve the branching/merging by calling 
the one who edited a composition simultaneously to find an agree about 
what to do with the merge.


And what if that other care-provider has gone home, maybe for a long 
period, after a week of night shifts, what should one do? Keep the 
composition in edit-mode? And causing more trouble and more branches and 
more merges and more agreements to find, because others need to edit the 
composition too? And what happens with the people wanting to read the 
composition, what do they read, the latest posted version (so all the 
edit-states are not accessible?)


I think this is a undesired solution. I think the locking system, in the 
end, is more safe also for the patient.


Bert




On 23-08-17 10:03, Erik Sundvall wrote:

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 (usually non-openEHR contexts) that is often done by either:
1. using a separate shared system just for shared care plans etc 
(which means a degree of double data entry and manual transfer/reentry 
of things from/to different EHR systems that the patient has records 
in at different care providers)

or
2. forcing everybody to use the EHR system of the "biggest" care 
provider in the (or that systems shared care planning module). Pretty 
convenient for the big actor but a mess for the other smaller ones, 
especially those that have a patient mix from several different "big" 
providers using the "use my system" attitude...


So yes the multi-provider shared records with branch/merge 
capabilities are certainly needed if we want to avoid #1 and #2 above.


And yes merge will be a headache for users when it occurs, but likely 
less of a headache in total than #1 and #2 above. I believe enough of 
the subgroup of clinicians dealing often with shared care will become 
proficient enough to handle merging.


The "lock" approach (only allowing one party to change at a time) 
would only work if things were entered and synced fast and at once 
after the care event had happened. In reality a doctor may read 
version 12 of the medication list when seeing the patient on Friday 
and audio-record an update (that should become version 13), that gets 
transcribed and recorded in the EHR after the weekend.  During the 
weekend the patient needs to go to another care provider (e.g. 
emergency) that also looks at version 12 (since that is the latest 
recorded one) and immediately after the consultation records a version 
13. See the merge conflict? In this case it might need to be resolved 
by the care takers contacting each other to agree on possibly 
conflicting persciptions. What happens today without openEHRs ability 
to at least detect a merge conflict is not always good for patient 
safety.


Many openEHR implementations today are single-care provider systems 
and then you don't handle/detect the conflicts using the system, but 
hopefully some other way.


I agree that a distributed versioning could be specified as optional 
in some openEHR conformance profile for single-care provider systems, 
but it should certainly not be taken away from the openEHR 
specifications! This also means that the version identifiers used in 
the specs (e.g. 
8849182c-82ad-4088-a07f-48ead4180515::ehr.examplecareprovider 
.org::12) should still contain the system id (e.g. 
ehr.examplecareprovider .org) even in single-care provider systems so 
that they can later be upgraded (or their possibly signed data can be 
moved) to a system capable of full distributed versioning.


Best regards,
Erik Sundvall
Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 
55 (or 010-1036252 in Sweden)
Region Östergötland: erik.sundv...@regionostergotland.se 
 

Re: Versioning implementations

[Erik Sundvall]

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 (usually non-openEHR contexts) that is often done by either:
1. using a separate shared system just for shared care plans etc (which
means a degree of double data entry and manual transfer/reentry of things
from/to different EHR systems that the patient has records in at different
care providers)
or
2. forcing everybody to use the EHR system of the "biggest" care provider
in the (or that systems shared care planning module). Pretty convenient for
the big actor but a mess for the other smaller ones, especially those that
have a patient mix from several different "big" providers using the "use my
system" attitude...

So yes the multi-provider shared records with branch/merge capabilities are
certainly needed if we want to avoid #1 and #2 above.

And yes merge will be a headache for users when it occurs, but likely less
of a headache in total than #1 and #2 above. I believe enough of the
subgroup of clinicians dealing often with shared care will become
proficient enough to handle merging.

The "lock" approach (only allowing one party to change at a time) would
only work if things were entered and synced fast and at once after the care
event had happened. In reality a doctor may read version 12 of the
medication list when seeing the patient on Friday and audio-record an
update (that should become version 13), that gets transcribed and recorded
in the EHR after the weekend.  During the weekend the patient needs to go
to another care provider (e.g. emergency) that also looks at version 12
(since that is the latest recorded one) and immediately after the
consultation records a version 13. See the merge conflict? In this case it
might need to be resolved by the care takers contacting each other to agree
on possibly conflicting persciptions. What happens today without openEHRs
ability to at least detect a merge conflict is not always good for patient
safety.

Many openEHR implementations today are single-care provider systems and
then you don't handle/detect the conflicts using the system, but hopefully
some other way.

I agree that a distributed versioning could be specified as optional in
some openEHR conformance profile for single-care provider systems, but it
should certainly not be taken away from the openEHR specifications! This
also means that the version identifiers used in the specs (e.g.
8849182c-82ad-4088-a07f-48ead4180515::ehr.examplecareprovider .org::12)
should still contain the system id (e.g. ehr.examplecareprovider .org) even
in single-care provider systems so that they can later be upgraded (or
their possibly signed data can be moved) to a system capable of full
distributed versioning.

Best regards,
Erik Sundvall
Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or
010-1036252 in Sweden)
Region Östergötland: erik.sundv...@regionostergotland.se (previously lio.se)
http://www.regionostergotland.se/cmit/
Linköping University: erik.sundv...@liu.se, http://www.imt.liu.se/~erisu/

On Mon, Aug 21, 2017 at 10:58 PM, Pablo Pazos 
wrote:

> I agree. The singleton is not one persistent compo, but the instance
> associated with an OPT of a persistent compo. When talking about singleton
> instances we should define what is considered the "class" :) My mistake.
>
> In the case of care plans, different care plans will be defined by
> different OPTs, same for medication lists if needed and modeled that way
> (some systems might only need one medication list, one problem list, etc.
> by EHR).
>
> But again, these are all clinical modeling decisions. A bad model might
> represent different care plans with the same OPT, and of course this breaks
> the singleton concept, but we are talking about subjectiveness here, so
> there are no hard rules (call it probabilistic singleton).
>
>
> Best,
> Pablo.
>
>
> On Mon, Aug 21, 2017 at 5:40 PM, Bert Verhees 
> wrote:
>
>> Pablo, one small remark, a persistent composition is not really a
>> singleton. Not conceptually. A patient can have more care - plans, for
>> example, at different care - institutions or multiple care - takers at a
>> single institution, or have multiple medication-lists.
>>
>> Bert
>>
>> On ma 21 aug. 2017 19:24 Pablo Pazos  wrote:
>>
>>> 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 question. Of course systems that focus on
> primary care might not implement them. But for hospital 

Re: Versioning implementations

[Pablo Pazos]

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 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 patient, persistent shows their
>> value.
>>
> Hi Pablo, two questions
>
> Which problem do you solve with persistent records which cannot be solved
> in another way? Do you agree that persistent records are the only reason to
> have branching/merging necessary?
>

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. But in
principle, branch and merge could happen to anything in the record, e.g.
for reasons like adding competing translations of clinical notes etc.

- thomas





Adding to Thomas, we can view this from three points of view: technical
implementation, clinical modeling, and spec. My previous comments about
persistent records are spec related. As Thomas said, _how_ things are done
using the spec will depend on modelers, and also implementers.

>From the spec, I see persistent records as a framework to record everything
that is conceptually a Singleton (one instance across the whole patient
EHR). Then if that can or can't be modeled as an event record, is a
discussion for clinical modelers, but I think that doesn't diminish the
need of such a concept on the specs.

Versioning and branching is an ortogonal concept to event/persistent
records and can be used in any case. The _how_ versioning/branching is used
has a lot to do with implementers and that is related to my initial
question, and the hunch that maybe other devs like me found
branching/merging an friction point (related to complexity) for the most
frequent & simple implementations of openEHR, but knowing there are less
frequent implementations that make extensive use of branching and merging.

>From the current answers to this thread, I see the need of a simplified or
relaxed versioning model, that maybe is just a constraint over the current
version control, allowing only certain versioning patterns, like lineal
versioning, and some control mechanisms like versioning lock/release,
access to read-only records, etc. These are not changes to the current
spec, but additions as specs or as guidelines.

What do others think?




___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implemente
rs_lists.openehr.org
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Versioning implementations

[Bert Verhees]

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 extended to things like care 
plans and so on. But in principle, branch and merge could happen to 
anything in the record, e.g. for reasons like adding competing 
translations of clinical notes etc.


It is true that care-plans for a single patient for a single case can 
be written by more care-takers simultaneously, but one could argue if 
they, in that case, belong in the same composition?
Wouldn't it be better to have more care-takers for one patient on a 
single case have their own compositions, and are grouped by folders 
outside the compositions?


well how a care plan is designed is up to clinical designers. The 
usual idea is to have an updatable, evolving plan (potentially for 
each major problem), shared across care providers.


On second thoughts, I agree that to facilitate a care-plan is a good 
reason to have persistent compositions.


In case if more than one care-taker is able to edit a single care-plan 
in a single composition simultaneously, then branching/merging will 
become necessary.
However, in that case, I think it is better in that case to lock that 
particular composition for updates and have it refreshed on the screen 
like should always be done on database-based applications after locking.

In that case, only versioning without merging would be necessary.

But like you mentioned before, merging (without branching) can become 
necessary on importing data from another OpenEHR-based EHR, in that 
case, persistent compositions can have reasons to be merged.


Thanks very much for the explanation. I understand that this is a 
delicate subject which complexity is easily underestimated.


Bert

___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Versioning implementations

[Thomas Beale]

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. But in principle, branch and merge could happen to anything in 
the record, e.g. for reasons like adding competing translations of 
clinical notes etc.


It is true that care-plans for a single patient for a single case can 
be written by more care-takers simultaneously, but one could argue if 
they, in that case, belong in the same composition?
Wouldn't it be better to have more care-takers for one patient on a 
single case have their own compositions, and are grouped by folders 
outside the compositions?


well how a care plan is designed is up to clinical designers. The usual 
idea is to have an updatable, evolving plan (potentially for each major 
problem), shared across care providers.


- thomas


___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Versioning implementations

[Bert Verhees]

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 them. But for hospital or 
even regional / national records need a wider view of the patient, 
persistent shows their value.

Hi Pablo, two questions

Which problem do you solve with persistent records which cannot be 
solved in another way? Do you agree that persistent records are the 
only reason to have branching/merging necessary?


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. 
But in principle, branch and merge could happen to anything in the 
record, e.g. for reasons like adding competing translations of 
clinical notes etc.


It is true that care-plans for a single patient for a single case can be 
written by more care-takers simultaneously, but one could argue if they, 
in that case, belong in the same composition?
Wouldn't it be better to have more care-takers for one patient on a 
single case have their own compositions, and are grouped by folders 
outside the compositions?


Bert

___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Versioning implementations

[Thomas Beale]

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 / national records need a wider view of the patient, 
persistent shows their value.

Hi Pablo, two questions

Which problem do you solve with persistent records which cannot be 
solved in another way? Do you agree that persistent records are the 
only reason to have branching/merging necessary?


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. But 
in principle, branch and merge could happen to anything in the record, 
e.g. for reasons like adding competing translations of clinical notes etc.


- thomas


___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Versioning implementations

[Bert Verhees]

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 patient, 
persistent shows their value.

Hi Pablo, two questions

Which problem do you solve with persistent records which cannot be 
solved in another way? Do you agree that persistent records are the only 
reason to have branching/merging necessary?


Thanks
Bert

___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Versioning implementations

[Seref Arikan]

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 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
>> 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 :
>>
>>>
>>> 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" >> 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 
>>> 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 

RE: Versioning implementations

[Pablo Pazos]

@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 patient, persistent shows their
value.

@Bjorn, what is the relationship between a scope and OPTs/folders? The
concepts you mentioned are likely to be modeled with OPTs and folders.
It is very interesting that you didn't need branch versioning yet.

On Aug 20, 2017 6:03 PM, "Bjørn Næss" <b...@dips.no> wrote:

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 <+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>:



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

Re: Versioning implementations

[Danny Nguyen]

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
> 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 :
>
>>
>> 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 
>> 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 

Re: Versioning implementations

[GF]

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 documented event is equally important to document.
What is important now is not later. And vice versa.
Always a subjective opinion is documented by the author.

Persistent
Depending on circumstances an event is important or not.
In this context I fail to grasp the need to label certain events as persistent 
and others not.
All documented events need to persist in EHR-systems.

Lists re-used data.
Some events warrant to be re-used in context dependent lists: Active 
medication, Problem list, Previous diagnosis, etc.
Each context, HcProvider will need different lists for different purposes.
These lists are the result of documented events and persist.
Creating lists is an example of re-using data, because list content  is derived 
from pre-existing events/data.
These lists are either changing are not-changing over time.

Versioning Lists
Lists can be updated as the result of new events in the patient system and 
therefor need to be versioned.
These are non-technical new versions. They are the result because of changes in 
the patient system

Versioning events
While documenting events and committing them to the data base sometimes event 
data needs to be changed, updated, corrected.
The same event gets a new technical version, because nothing in the patient 
system changed but the documentingHcProvider initiated the change.

Synchronisation, merging, syncing
This is a complex topic.
Is there an extensive list of examples and requirements?

Gerard


Gerard   Freriks
+31 620347088
  gf...@luna.nl

Kattensingel  20
2801 CA Gouda
the Netherlands

> On 18 Aug 2017, at 13: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.
> 

___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

RE: Versioning implementations

[Bjørn Næss]

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
S

Re: Versioning implementations

[Bert Verhees]

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 :

>
> 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" 
> 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 
> 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 
>> wrote:
>>
>>> Hi Pablo, I did it a few years ago, just dumped 

Re: Versioning implementations

[Thomas Beale]

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" 
> 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
> 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
> 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

Re: Versioning implementations

[Seref Arikan]

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 
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 
> 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
>> 

Re: Versioning implementations

[Pablo Pazos]

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 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://www.cabolabs.com
> pablo.pa...@cabolabs.com
> Subscribe to our newsletter 
>
>
> ___
> 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://www.cabolabs.com
pablo.pa...@cabolabs.com
Subscribe to our newsletter 
___
openEHR-implementers mailing list
openEHR-implementers@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org

Re: Versioning implementations

[Pieter Bos]

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 Pazos 
> het volgende 
geschreven:

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
Skype: cabolabs

[https://docs.google.com/uc?export=download=0B27lX-sxkymfdEdPLVI5UTZuZlU=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]
 
http://www.cabolabs.com
pablo.pa...@cabolabs.com
Subscribe to our newsletter

___
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