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 just starting to see the implementation of systems where
 syncing may be a question, so although there may

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

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

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

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

Re: Versioning implementations

[Pablo Pazos]

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



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