Re: Question about paths to C_SINGLE_ATTRIBUTE alternatives

2016-11-23 Thread Thomas Beale 


So far we have a Problem Report 
<https://openehr.atlassian.net/projects/SPECPR/issues/SPECPR-210> which 
I think needs to be discussed by the Specifictions Editorial Committee 
in the normal way to decide if it becomes a CR, what release it would go 
in and so on.


- thomas


On 07/11/2016 11:39, pablo pazos wrote:
Hi Thomas, do you recall if we have any change request to make dvs 
inherit from locatable?


--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

*From:* openEHR-technical 
<openehr-technical-boun...@lists.openehr.org> on behalf of Thomas 
Beale <thomas.be...@openehr.org>

*Sent:* Thursday, November 3, 2016 8:02:41 AM
*To:* openehr-technical@lists.openehr.org
*Subject:* Re: Question about paths to C_SINGLE_ATTRIBUTE alternatives


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

Re: Question about paths to C_SINGLE_ATTRIBUTE alternatives

2016-11-07 Thread pablo pazos 
Hi Thomas, do you recall if we have any change request to make dvs inherit from 
locatable?

--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on behalf 
of Thomas Beale <thomas.be...@openehr.org>
Sent: Thursday, November 3, 2016 8:02:41 AM
To: openehr-technical@lists.openehr.org
Subject: Re: Question about paths to C_SINGLE_ATTRIBUTE alternatives



Hi Pieter,

On 01/11/2016 10:22, Pieter Bos wrote:

I fully agree that they should be mandatory. Things like this make writing 
software based on OpenEHR more complex than it could be.

I also never understood that the DV_-types do not have an archetype node id in 
the reference model.

this is because they don't inherit from LOCATABLE, which is a modelling 
decision from a long time ago. I'm not aware that it has caused major problems 
(at least not reported ones) but I can imagine that it might seem better today 
to make DATA_VALUE inherit from LOCATABLE, or at least to have the 
archetype_node_id field in it. I'm not that clear on how much it matters in 
anyone's implementation.


This adds complexity, because the paths in an archetype do not always match the 
paths in a reference model object. Sometimes you just need paths based on an 
archetype that need to work in reference model objects. For example when 
displaying information, rendering forms, evaluating rules or score 
calculations, or rendering a UI to edit stored reference model objects. Of 
course, you can write something that converts these paths from the AOM to the 
RM, but I don't see why that should be necessary.

well the RM objects, down to the ELEMENT nodes, should have archetype paths 
that match the archetypes that create them, with the added complexity that real 
data may contain multiple instances that match a given archetype path, as 
described 
here<http://www.openehr.org/releases/BASE/latest/docs/architecture_overview/architecture_overview.html#_data_paths_and_uniqueness>.

Can you provide more detail on what 'conversion' you are referring to here?

thanks

- thomas

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

Re: Question about paths to C_SINGLE_ATTRIBUTE alternatives

2016-11-03 Thread Thomas Beale 


Hi Pieter,


On 01/11/2016 10:22, Pieter Bos wrote:

I fully agree that they should be mandatory. Things like this make writing 
software based on OpenEHR more complex than it could be.

I also never understood that the DV_-types do not have an archetype node id in 
the reference model.


this is because they don't inherit from LOCATABLE, which is a modelling 
decision from a long time ago. I'm not aware that it has caused major 
problems (at least not reported ones) but I can imagine that it might 
seem better today to make DATA_VALUE inherit from LOCATABLE, or at least 
to have the archetype_node_id field in it. I'm not that clear on how 
much it matters in anyone's implementation.



This adds complexity, because the paths in an archetype do not always match the 
paths in a reference model object. Sometimes you just need paths based on an 
archetype that need to work in reference model objects. For example when 
displaying information, rendering forms, evaluating rules or score 
calculations, or rendering a UI to edit stored reference model objects. Of 
course, you can write something that converts these paths from the AOM to the 
RM, but I don’t see why that should be necessary.


well the RM objects, down to the ELEMENT nodes, should have archetype 
paths that match the archetypes that create them, with the added 
complexity that real data may contain multiple instances that match a 
given archetype path, as described here 
.


Can you provide more detail on what 'conversion' you are referring to here?

thanks

- thomas

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

Re: Question about paths to C_SINGLE_ATTRIBUTE alternatives

2016-11-02 Thread pablo pazos 
@Thomas thanks for the pointer.

We were talking with Diego about the need of storing the nodeId in the IM for 
datatypes to allow querying over specific DV alternatives of an ELEMENT.value, 
because for path-based queries having nodeId for DV is easier to implement than 
trying to derive the DV from it's attributes in the path.

I think this goes in the lines of what Pieter commented on his email.

@All is there any change request to the IM for adding a nodeId field for 
DATAVALUE, or maybe make it extend LOCATABLE?
Is there any constraint for making DATAVALUE extend LOCATABLE?

--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com<http://cabolabs.com/es/home><http://twitter.com/ppazos>

From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on behalf 
of Pieter Bos <pieter@nedap.com>
Sent: Tuesday, November 1, 2016 7:22:48 AM
To: openeh technical; openehr clinical
Subject: Re: Question about paths to C_SINGLE_ATTRIBUTE alternatives

I fully agree that they should be mandatory. Things like this make writing 
software based on OpenEHR more complex than it could be.

I also never understood that the DV_-types do not have an archetype node id in 
the reference model. This adds complexity, because the paths in an archetype do 
not always match the paths in a reference model object. Sometimes you just need 
paths based on an archetype that need to work in reference model objects. For 
example when displaying information, rendering forms, evaluating rules or score 
calculations, or rendering a UI to edit stored reference model objects. Of 
course, you can write something that converts these paths from the AOM to the 
RM, but I don’t see why that should be necessary.

Perhaps someone can explain the reasoning behind these choices?

Regards,

Pieter Bos
Nedap Healthcare


From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on behalf 
of pablo pazos <pazospa...@hotmail.com>
Reply-To: openeh technical <openehr-technical@lists.openehr.org>
Date: Monday 31 October 2016 at 17:08
To: openehr clinical <openehr-clini...@lists.openehr.org>, openeh technical 
<openehr-technical@lists.openehr.org>
Subject: Question about paths to C_SINGLE_ATTRIBUTE alternatives


Hi,



I was chatting with Diego, about the need of nodeIds for ELEMENT.value and I 
detected some archetypes with alternatives but no nodeIds, I guess, created 
with the Archetype Editor.



Examples from openEHR-EHR-CLUSTER.timing_daily.v0



...
ELEMENT[at0004] occurrences matches {0..*} matches {-- Specific 
time
value matches {
DV_TIME matches {*}
DV_INTERVAL matches {
upper matches {
DV_TIME matches {*}
}
lower matches {
DV_TIME matches {*}
}
}
}
}
ELEMENT[at0026] occurrences matches {0..*} matches {-- Named 
time event
value matches {
DV_TEXT matches {*}
DV_CODED_TEXT matches {
defining_code matches {
[local::
at0031, -- immediately (stat)
at0032, -- in the morning
at0033, -- at night
at0034]-- in the morning and at night
}
}
}
}

...





How can software create paths to the specific ELEMENT.value constraint if the 
constraints don't have a nodeId?





This remembers me of an old discussion about if the nodeIds should or not be 
mandatory. Opinions?




--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com<http://cabolabs.com/es/home>
___
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: Question about paths to C_SINGLE_ATTRIBUTE alternatives

2016-11-01 Thread Pieter Bos 
I fully agree that they should be mandatory. Things like this make writing 
software based on OpenEHR more complex than it could be.

I also never understood that the DV_-types do not have an archetype node id in 
the reference model. This adds complexity, because the paths in an archetype do 
not always match the paths in a reference model object. Sometimes you just need 
paths based on an archetype that need to work in reference model objects. For 
example when displaying information, rendering forms, evaluating rules or score 
calculations, or rendering a UI to edit stored reference model objects. Of 
course, you can write something that converts these paths from the AOM to the 
RM, but I don’t see why that should be necessary.

Perhaps someone can explain the reasoning behind these choices?

Regards,

Pieter Bos
Nedap Healthcare


From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on behalf 
of pablo pazos <pazospa...@hotmail.com>
Reply-To: openeh technical <openehr-technical@lists.openehr.org>
Date: Monday 31 October 2016 at 17:08
To: openehr clinical <openehr-clini...@lists.openehr.org>, openeh technical 
<openehr-technical@lists.openehr.org>
Subject: Question about paths to C_SINGLE_ATTRIBUTE alternatives


Hi,



I was chatting with Diego, about the need of nodeIds for ELEMENT.value and I 
detected some archetypes with alternatives but no nodeIds, I guess, created 
with the Archetype Editor.



Examples from openEHR-EHR-CLUSTER.timing_daily.v0



...
ELEMENT[at0004] occurrences matches {0..*} matches {-- Specific 
time
value matches {
DV_TIME matches {*}
DV_INTERVAL matches {
upper matches {
DV_TIME matches {*}
}
lower matches {
DV_TIME matches {*}
}
}
}
}
ELEMENT[at0026] occurrences matches {0..*} matches {-- Named 
time event
value matches {
DV_TEXT matches {*}
DV_CODED_TEXT matches {
defining_code matches {
[local::
at0031, -- immediately (stat)
at0032, -- in the morning
at0033, -- at night
at0034]-- in the morning and at night
}
}
}
}

...





How can software create paths to the specific ELEMENT.value constraint if the 
constraints don't have a nodeId?





This remembers me of an old discussion about if the nodeIds should or not be 
mandatory. Opinions?




--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com<http://cabolabs.com/es/home>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Question about paths to C_SINGLE_ATTRIBUTE alternatives

2016-10-31 Thread pablo pazos 
Hi,


I was chatting with Diego, about the need of nodeIds for ELEMENT.value and I 
detected some archetypes with alternatives but no nodeIds, I guess, created 
with the Archetype Editor.


Examples from openEHR-EHR-CLUSTER.timing_daily.v0


...

ELEMENT[at0004] occurrences matches {0..*} matches {-- Specific 
time
value matches {
DV_TIME matches {*}
DV_INTERVAL matches {
upper matches {
DV_TIME matches {*}
}
lower matches {
DV_TIME matches {*}
}
}
}
}
ELEMENT[at0026] occurrences matches {0..*} matches {-- Named 
time event
value matches {
DV_TEXT matches {*}
DV_CODED_TEXT matches {
defining_code matches {
[local::
at0031, -- immediately (stat)
at0032, -- in the morning
at0033, -- at night
at0034]-- in the morning and at night
}
}
}
}

...



How can software create paths to the specific ELEMENT.value constraint if the 
constraints don't have a nodeId?



This remembers me of an old discussion about if the nodeIds should or not be 
mandatory. Opinions?



--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org