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



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 

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

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 

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



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