Re: Strange behavior in Template designer 2.8.94 Beta

[Thomas Beale]

It's AOM2.x inside, but deals with ADL 1.4 and .oet files externally. 
It's now more or less BMM-driven I think. But also they made some 
compromises to make sure all the ADL 1.4 and .oet stuff works the way it 
did.


Archie is completely ADL/AOM2 of course. It may be that in the future 
they could use the Archie core, which I suspect is cleaner code, for the 
core of ADL-designer, but for now the main priority for that tool is to 
be a good replacement for the Archetype Editor + Template Designer, not 
to be mainly an ADL2 tool.


- thomas


On 20/08/2018 13:48, Pieter Bos wrote:

Has that been changed? Last time I checked and asked Marand it was ADL 1.4 
only. Or is it AOM 2.x but ADL 1.4?

Regards,

Pieter Bos

From: openEHR-technical  on behalf of 
Thomas Beale 
Reply-To: For openEHR technical discussions 

Date: Monday, 20 August 2018 at 13:04
To: "openehr-technical@lists.openehr.org" 
Subject: Re: Strange behavior in Template designer 2.8.94 Beta


The new tool is AOM 2.x inside, but I have to admit I have not investigated how 
this particular problem is resolved in it.

- thomas

On 20/08/2018 11:42, Peter Gummer wrote:
Hi Hildi,


On 20 Aug 2018, at 19:13, Hildegard McNicoll 
mailto:hi...@freshehr.com>> wrote:

Incidentally, the new web based ADL Designer tool developed by Marand doesn't 
have this problem anymore. As far as I know it is very close to being released 
now.


I’m curious — from a purely academic perspective, now, since unfortunately I’ve 
not been able to participate in the openEHR revolution for the last couple of 
years — how this new tool is able to do that. Does this require migrating to 
ADL 2.0? As I recall (and it could be my memory at fault here) this was a 
limitation of ADL 1.4, rather than of the Ocean Template Designer itself.

Peter


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


--
Thomas Beale
Principal, Ars Semantica <http://www.arssemantica.com>
Consultant, ABD Project, Intermountain Healthcare 
<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation 
<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society 
<http://www.bcs.org/category/6044>
Health IT blog <http://wolandscat.net/> | Culture blog 
<http://wolandsothercat.net/> | The Objective Stance 
<https://theobjectivestance.net/>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Strange behavior in Template designer 2.8.94 Beta

[Pieter Bos]

Has that been changed? Last time I checked and asked Marand it was ADL 1.4 
only. Or is it AOM 2.x but ADL 1.4?

Regards,

Pieter Bos

From: openEHR-technical  on behalf 
of Thomas Beale 
Reply-To: For openEHR technical discussions 

Date: Monday, 20 August 2018 at 13:04
To: "openehr-technical@lists.openehr.org" 
Subject: Re: Strange behavior in Template designer 2.8.94 Beta


The new tool is AOM 2.x inside, but I have to admit I have not investigated how 
this particular problem is resolved in it.

- thomas

On 20/08/2018 11:42, Peter Gummer wrote:
Hi Hildi,


On 20 Aug 2018, at 19:13, Hildegard McNicoll 
mailto:hi...@freshehr.com>> wrote:

Incidentally, the new web based ADL Designer tool developed by Marand doesn't 
have this problem anymore. As far as I know it is very close to being released 
now.


I’m curious — from a purely academic perspective, now, since unfortunately I’ve 
not been able to participate in the openEHR revolution for the last couple of 
years — how this new tool is able to do that. Does this require migrating to 
ADL 2.0? As I recall (and it could be my memory at fault here) this was a 
limitation of ADL 1.4, rather than of the Ocean Template Designer itself.

Peter


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Strange behavior in Template designer 2.8.94 Beta

[Peter Gummer]

Okay, interesting! It would have made things easier for us 5 or 10 years ago to 
have had a looser interpretation of the ‘unique path rule’. Perhaps it was a 
case of erring on the side of caution, since it's always easier to relax a rule 
that turns out to have been too strict rather than retrospectively tighten a 
rule that was too lax.

This would have implications for operational templates, as well as for existing 
downstream software that consumes the OPTs. Would OPTs generated by the new ADL 
Designer tool fail validation by existing software?

I’m looking forward to a more detailed explanation, if someone knows.

Thanks Hildi,
Peter


> On 20 Aug 2018, at 20:49, Hildegard McNicoll  wrote:
> 
> Hi Peter
> 
> It's probably best to defer the exact answer to others, but my understanding 
> is that the 'unique path rule' was interpreted too tightly in Template 
> Designer, rather than this being a strict limitation in ADL 1.4. Certainly 
> there is no need to migrate to ADL 2.0 with ADL Designer, it handles ADL 1.4 
> perfectly well.
> 
> But as I said - other people may want to pitch in and provide a more detailed 
> explanation.
> 
> Kind regards
> 
> Hildi
> 
> Hildegard McNicoll
> Chief Operations Officer
> 
> 
> 
> mobile:  +44 (0)7932 502655
> landline:  +44 (0)1536 414994
> skype: hild5559
> twitter: @hildegardfranke
> LinkedIn 
> 
> On Mon, 20 Aug 2018 at 11:42, Peter Gummer  > wrote:
> Hi Hildi,
> 
>> On 20 Aug 2018, at 19:13, Hildegard McNicoll > > wrote:
>> 
>> Incidentally, the new web based ADL Designer tool developed by Marand 
>> doesn't have this problem anymore. As far as I know it is very close to 
>> being released now.
> 
> 
> I’m curious — from a purely academic perspective, now, since unfortunately 
> I’ve not been able to participate in the openEHR revolution for the last 
> couple of years — how this new tool is able to do that. Does this require 
> migrating to ADL 2.0? As I recall (and it could be my memory at fault here) 
> this was a limitation of ADL 1.4, rather than of the Ocean Template Designer 
> itself.
> 
> Peter

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Strange behavior in Template designer 2.8.94 Beta

[Thomas Beale]

The new tool is AOM 2.x inside, but I have to admit I have not 
investigated how this particular problem is resolved in it.


- thomas


On 20/08/2018 11:42, Peter Gummer wrote:

Hi Hildi,

On 20 Aug 2018, at 19:13, Hildegard McNicoll > wrote:


Incidentally, the new web based ADL Designer tool developed by Marand 
doesn't have this problem anymore. As far as I know it is very close 
to being released now.



I’m curious — from a purely academic perspective, now, since 
unfortunately I’ve not been able to participate in the openEHR 
revolution for the last couple of years — how this new tool is able to 
do that. Does this require migrating to ADL 2.0? As I recall (and it 
could be my memory at fault here) this was a limitation of ADL 1.4, 
rather than of the Ocean Template Designer itself.


Peter


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Strange behavior in Template designer 2.8.94 Beta

[Hildegard McNicoll]

Hi Peter

It's probably best to defer the exact answer to others, but my
understanding is that the 'unique path rule' was interpreted too tightly in
Template Designer, rather than this being a strict limitation in ADL 1.4.
Certainly there is no need to migrate to ADL 2.0 with ADL Designer, it
handles ADL 1.4 perfectly well.

But as I said - other people may want to pitch in and provide a more
detailed explanation.

Kind regards

Hildi

Hildegard McNicoll
Chief Operations Officer


mobile:  +44 (0)7932 502655
landline:  +44 (0)1536 414994
skype: hild5559
twitter: @hildegardfranke
LinkedIn 


On Mon, 20 Aug 2018 at 11:42, Peter Gummer  wrote:

> Hi Hildi,
>
> On 20 Aug 2018, at 19:13, Hildegard McNicoll  wrote:
>
> Incidentally, the new web based ADL Designer tool developed by Marand
> doesn't have this problem anymore. As far as I know it is very close to
> being released now.
>
>
>
> I’m curious — from a purely academic perspective, now, since unfortunately
> I’ve not been able to participate in the openEHR revolution for the last
> couple of years — how this new tool is able to do that. Does this require
> migrating to ADL 2.0? As I recall (and it could be my memory at fault here)
> this was a limitation of ADL 1.4, rather than of the Ocean Template
> Designer itself.
>
> Peter
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Strange behavior in Template designer 2.8.94 Beta

[Peter Gummer]

Hi Hildi,

> On 20 Aug 2018, at 19:13, Hildegard McNicoll  wrote:
> 
> Incidentally, the new web based ADL Designer tool developed by Marand doesn't 
> have this problem anymore. As far as I know it is very close to being 
> released now.


I’m curious — from a purely academic perspective, now, since unfortunately I’ve 
not been able to participate in the openEHR revolution for the last couple of 
years — how this new tool is able to do that. Does this require migrating to 
ADL 2.0? As I recall (and it could be my memory at fault here) this was a 
limitation of ADL 1.4, rather than of the Ocean Template Designer itself.

Peter___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Strange behavior in Template designer 2.8.94 Beta

[Hildegard McNicoll]

Hi Dileep

In your particular example I would leave the archetype unchanged, but
instead rename the Issue name to say 'complaint description'. That way you
can keep the multiple recurrence of the archetype, but have your preferred
name in the data as the left hand side of the name/value pair. You may want
to do the same with the Symptom/sign cluster too to allow multiple
occurrences for that - unless you want to deliberately constrain it to a
single occurrence.

I quite often use sections as a workaround, but that only works if the
archetype you want to rename is an entry archetype - it wouldn't work so
well for clusters (unless you can safely rename the 'container' archetype
e.g. Story/History or Physical examination finding).

So if I need multiple 'named' problems I add an 'Adhoc' section archetype
for each, rename the 'Adhoc' with the appropriate problem name and leave
the Problem/diagnosis archetype name as it is. It does mean that the
section carries a degree of semantic meaning (which it isn't really
supposed to do), but it does help with - as Peter quite rightly says - very
annoying problem.

Incidentally, the new web based ADL Designer tool developed by Marand
doesn't have this problem anymore. As far as I know it is very close to
being released now.

Kind regards

Hildi

Hildegard McNicoll
Chief Operations Officer


mobile:  +44 (0)7932 502655
landline:  +44 (0)1536 414994
skype: hild5559
twitter: @hildegardfranke
LinkedIn 


On Mon, 20 Aug 2018 at 07:10, Dileep V S  wrote:

> thanks
>
> regards
>
> Dileep V S
> *Founder*
> HealtheLife Ventures LLP
> m: +91 9632888113
> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
> w: healthelife.in  e: dil...@healthelife.in
>
> On Mon, Aug 20, 2018 at 11:15 AM, Peter Gummer 
> wrote:
>
>> Hi Dileep,
>>
>> Right-click the node and select the Clone option. Then rename the
>> duplicate of the node.
>>
>> Regards,
>> Peter
>>
>>
>> On 20 Aug 2018, at 15:03, Dileep V S  wrote:
>>
>> Dear Peter,
>>
>> Thanks for your reply. However I am not sure I fully understand the logic
>> of this.
>>
>> OpenEHR has a way to represent multi occurrence nodes (by appending 0, 1
>> etc to the path) such that the paths will remain unique. This should work
>> even when the mode is constrained with a name as well. May be I am missing
>> something here.
>>
>> I am not sure what you mean by cloning the node? Can this be done in
>> Template designer? if yes how
>>
>> regards
>>
>>
>>
>> Dileep V S
>> *Founder*
>> HealtheLife Ventures LLP
>> m: +91 9632888113
>> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
>> w: healthelife.in  e: dil...@healthelife.in
>>
>> On Sun, Aug 19, 2018 at 5:46 PM, Peter Gummer 
>> wrote:
>>
>>> Hi Dileep,
>>>
>>> Yes, this is expected. The behaviour was first noticed about 10 years
>>> ago, and initially it was reported as a bug. After some thought we realised
>>> that it’s the correct behaviour. I found it incredibly annoying too!
>>>
>>> My memory of the exact reasoning is poor, after all of these years; but
>>> I think it’s something like this:
>>>
>>>
>>>1. Initially, the name of the archetype node is unconstrained. As a
>>>consequence, any name would be valid for this node. Therefore, there’s an
>>>unlimited number of unique paths to the data that could be stored at this
>>>node’s path: for example, at1234[name = “a”], at1234[name =
>>>“b”], at1234[name = “c”], etc.
>>>2. In the template, when you constrain the archetype node to a
>>>single specific name, there is only one possible path to the the node: 
>>> for
>>>example, at1234[name=“whatever name you’ve constrained it to”]. There’s
>>>only one possible unique path to this. Therefore, the maximum
>>> occurrences possible is 1.
>>>
>>>
>>> Essentially, this arises because there has to be one unique path to each
>>> node in the data. This is important so that each data node can be
>>> identified unambiguously within the EHR.
>>>
>>> There is a workaround, however. (But again, my memory may be inaccurate,
>>> so please forgive me if this isn’t quite right or complete.) To allow
>>> multiple occurrences, you need to clone the node. Then you can rename the
>>> clone. Although the renamed clone will be single-occurrence, this will
>>> retain the original node as multiple occurrences. Or at least I think this
>>> is how it works — it’s been quite a few years!
>>>
>>> I have an even vaguer recollection that ADL 2.0 may have resolved this
>>> in a more satisfactory way. Perhaps Thomas or someone can elucidate.
>>>
>>> Hope this helps,
>>> Peter
>>>
>>>
>>> On 19 Aug 2018, at 20:24, Dileep V S  wrote:
>>>
>>> Hi,
>>>
>>> I am observing a strange behavior in the template designer and whated to
>>> check if this is the expected behavior and if not how to manage it.
>>>
>>> In any template, when ever I rename any archetypes, their occurrence
>>> gets set to [0..1] automatically (single 

Re: Strange behavior in Template designer 2.8.94 Beta

[Peter Gummer]

Hi Dileep,

Right-click the node and select the Clone option. Then rename the duplicate of 
the node. 

Regards,
Peter 


> On 20 Aug 2018, at 15:03, Dileep V S  wrote:
> 
> Dear Peter,
> 
> Thanks for your reply. However I am not sure I fully understand the logic of 
> this. 
> 
> OpenEHR has a way to represent multi occurrence nodes (by appending 0, 1 etc 
> to the path) such that the paths will remain unique. This should work even 
> when the mode is constrained with a name as well. May be I am missing 
> something here.
> 
> I am not sure what you mean by cloning the node? Can this be done in Template 
> designer? if yes how
> 
> regards
> 
> 
> 
> 
> Dileep V S
> Founder
> HealtheLife Ventures LLP
> m:+91 9632888113
> a:106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
> w:healthelife.in  e: dil...@healthelife.in
> 
>> On Sun, Aug 19, 2018 at 5:46 PM, Peter Gummer  wrote:
>> Hi Dileep,
>> 
>> Yes, this is expected. The behaviour was first noticed about 10 years ago, 
>> and initially it was reported as a bug. After some thought we realised that 
>> it’s the correct behaviour. I found it incredibly annoying too!
>> 
>> My memory of the exact reasoning is poor, after all of these years; but I 
>> think it’s something like this:
>> 
>> Initially, the name of the archetype node is unconstrained. As a 
>> consequence, any name would be valid for this node. Therefore, there’s an 
>> unlimited number of unique paths to the data that could be stored at this 
>> node’s path: for example, at1234[name = “a”], at1234[name = “b”], 
>> at1234[name = “c”], etc.
>> In the template, when you constrain the archetype node to a single specific 
>> name, there is only one possible path to the the node: for example, 
>> at1234[name=“whatever name you’ve constrained it to”]. There’s only one 
>> possible unique path to this. Therefore, the maximum  occurrences possible 
>> is 1.
>> 
>> Essentially, this arises because there has to be one unique path to each 
>> node in the data. This is important so that each data node can be identified 
>> unambiguously within the EHR.
>> 
>> There is a workaround, however. (But again, my memory may be inaccurate, so 
>> please forgive me if this isn’t quite right or complete.) To allow multiple 
>> occurrences, you need to clone the node. Then you can rename the clone. 
>> Although the renamed clone will be single-occurrence, this will retain the 
>> original node as multiple occurrences. Or at least I think this is how it 
>> works — it’s been quite a few years!
>> 
>> I have an even vaguer recollection that ADL 2.0 may have resolved this in a 
>> more satisfactory way. Perhaps Thomas or someone can elucidate.
>> 
>> Hope this helps,
>> Peter
>> 
>> 
>>> On 19 Aug 2018, at 20:24, Dileep V S  wrote:
>>> 
>>> Hi,
>>> 
>>> I am observing a strange behavior in the template designer and whated to 
>>> check if this is the expected behavior and if not how to manage it.
>>> 
>>> In any template, when ever I rename any archetypes, their occurrence gets 
>>> set to [0..1] automatically (single occurrence). The options for selecting 
>>> multiple occurrences is no more available.
>>> 
>>> Have anybody else noticed this problem? Is there any way to work around 
>>> this as some of these archetypes need to be multiple occurrences
>>> 
>>> Please see screenshots attached for reference
>>> 
>>> regards
>> 
>> 
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Strange behavior in Template designer 2.8.94 Beta

[Dileep V S]

Dear Peter,

Thanks for your reply. However I am not sure I fully understand the logic
of this.

OpenEHR has a way to represent multi occurrence nodes (by appending 0, 1
etc to the path) such that the paths will remain unique. This should work
even when the mode is constrained with a name as well. May be I am missing
something here.

I am not sure what you mean by cloning the node? Can this be done in
Template designer? if yes how

regards



Dileep V S
*Founder*
HealtheLife Ventures LLP
m: +91 9632888113
a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
w: healthelife.in  e: dil...@healthelife.in

On Sun, Aug 19, 2018 at 5:46 PM, Peter Gummer 
wrote:

> Hi Dileep,
>
> Yes, this is expected. The behaviour was first noticed about 10 years ago,
> and initially it was reported as a bug. After some thought we realised that
> it’s the correct behaviour. I found it incredibly annoying too!
>
> My memory of the exact reasoning is poor, after all of these years; but I
> think it’s something like this:
>
>
>1. Initially, the name of the archetype node is unconstrained. As a
>consequence, any name would be valid for this node. Therefore, there’s an
>unlimited number of unique paths to the data that could be stored at this
>node’s path: for example, at1234[name = “a”], at1234[name =
>“b”], at1234[name = “c”], etc.
>2. In the template, when you constrain the archetype node to a single
>specific name, there is only one possible path to the the node: for
>example, at1234[name=“whatever name you’ve constrained it to”]. There’s
>only one possible unique path to this. Therefore, the maximum
> occurrences possible is 1.
>
>
> Essentially, this arises because there has to be one unique path to each
> node in the data. This is important so that each data node can be
> identified unambiguously within the EHR.
>
> There is a workaround, however. (But again, my memory may be inaccurate,
> so please forgive me if this isn’t quite right or complete.) To allow
> multiple occurrences, you need to clone the node. Then you can rename the
> clone. Although the renamed clone will be single-occurrence, this will
> retain the original node as multiple occurrences. Or at least I think this
> is how it works — it’s been quite a few years!
>
> I have an even vaguer recollection that ADL 2.0 may have resolved this in
> a more satisfactory way. Perhaps Thomas or someone can elucidate.
>
> Hope this helps,
> Peter
>
>
> On 19 Aug 2018, at 20:24, Dileep V S  wrote:
>
> Hi,
>
> I am observing a strange behavior in the template designer and whated to
> check if this is the expected behavior and if not how to manage it.
>
> In any template, when ever I rename any archetypes, their occurrence gets
> set to [0..1] automatically (single occurrence). The options for selecting
> multiple occurrences is no more available.
>
> Have anybody else noticed this problem? Is there any way to work around
> this as some of these archetypes need to be multiple occurrences
>
> Please see screenshots attached for reference
>
> regards
>
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Strange behavior in Template designer 2.8.94 Beta

[Peter Gummer]

Hi Dileep,

Yes, this is expected. The behaviour was first noticed about 10 years ago, and 
initially it was reported as a bug. After some thought we realised that it’s 
the correct behaviour. I found it incredibly annoying too!

My memory of the exact reasoning is poor, after all of these years; but I think 
it’s something like this:

Initially, the name of the archetype node is unconstrained. As a consequence, 
any name would be valid for this node. Therefore, there’s an unlimited number 
of unique paths to the data that could be stored at this node’s path: for 
example, at1234[name = “a”], at1234[name = “b”], at1234[name = “c”], etc.
In the template, when you constrain the archetype node to a single specific 
name, there is only one possible path to the the node: for example, 
at1234[name=“whatever name you’ve constrained it to”]. There’s only one 
possible unique path to this. Therefore, the maximum  occurrences possible is 1.

Essentially, this arises because there has to be one unique path to each node 
in the data. This is important so that each data node can be identified 
unambiguously within the EHR.

There is a workaround, however. (But again, my memory may be inaccurate, so 
please forgive me if this isn’t quite right or complete.) To allow multiple 
occurrences, you need to clone the node. Then you can rename the clone. 
Although the renamed clone will be single-occurrence, this will retain the 
original node as multiple occurrences. Or at least I think this is how it works 
— it’s been quite a few years!

I have an even vaguer recollection that ADL 2.0 may have resolved this in a 
more satisfactory way. Perhaps Thomas or someone can elucidate.

Hope this helps,
Peter


> On 19 Aug 2018, at 20:24, Dileep V S  wrote:
> 
> Hi,
> 
> I am observing a strange behavior in the template designer and whated to 
> check if this is the expected behavior and if not how to manage it.
> 
> In any template, when ever I rename any archetypes, their occurrence gets set 
> to [0..1] automatically (single occurrence). The options for selecting 
> multiple occurrences is no more available.
> 
> Have anybody else noticed this problem? Is there any way to work around this 
> as some of these archetypes need to be multiple occurrences
> 
> Please see screenshots attached for reference
> 
> regards

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org