Hi Thomas!
A question regarding implementation of History paths in reference model:
from data_structures rev1.4, p26, one of the examples is
"event: | HISTORY.name | EVENT.name, e.g. |history|event_3".
But class EVENT has no attribute called name, it doesn't inherit LOCATABLE either. Does this imply that perhaps EVENT (or its super class EVENT_ITEM) should inherit LOCATABLE?
Thanks!
Rong
Rong
This is an important consideration - especially if we are to get the event right. We have recently been moving away from offset to a datetime stamp for the items in the history - as this is easier and more realistic for summary data over a long period.
With this change - you want to find and label the 1 minute, 5 minute and 10 minute Apgars - as the absolute time has no meaning.
The Editor allows you to constrain the run time name of the event.
Cheers, Sam
Rong Chen wrote:
Thanks, Sam! Please see my comments below.
Sam Heard wrote:
Rong
This is an important consideration - especially if we are to get the event right. We have recently been moving away from offset to a datetime stamp for the items in the history - as this is easier and more realistic for summary data over a long period.
Good to know that, I guess it will perhaps appear in the CR list soon.
With this change - you want to find and label the 1 minute, 5 minute and 10 minute Apgars - as the absolute time has no meaning.
The Editor allows you to constrain the run time name of the event.
My impression is that archetype can't constrain more than what reference information model can provide. In this case, there is no attribute "name" in the class EVENT, so it's not going to help very much even the archetype editor allows you to assign a name to EVENT. Maybe I got it wrong?
Cheers,
Rong
Rong Chen wrote:
Hi Thomas!
A question regarding implementation of History paths in reference model:
from data_structures rev1.4, p26, one of the examples is
"event: | HISTORY.name | EVENT.name, e.g. |history|event_3".But class EVENT has no attribute called name, it doesn't inherit LOCATABLE either. Does this imply that perhaps EVENT (or its super class EVENT_ITEM) should inherit LOCATABLE?
Hm. This appears to be an oversight in the model - EVENT should inherit from LOCATABLE. I'll look into this.
- thomas
Rong Chen wrote:
Thanks, Sam! Please see my comments below.
Sam Heard wrote:
Rong
This is an important consideration - especially if we are to get the event right. We have recently been moving away from offset to a datetime stamp for the items in the history - as this is easier and more realistic for summary data over a long period.
Good to know that, I guess it will perhaps appear in the CR list soon.
actually, the current model has an offset in each event, not the absolute time. This makes it easy to archetype, since you almost always want to archetype offsets like 1, 2, 5 mins in apgar, or 30 mins, 1h45mins in GTT. If we replace EVENT.offset: DV_DURATION with EVENT.time: DV_DATE_TIME, then archetyping it becomes harder - how do you constrain the date_time to be a certain offset from the origin? Actually, you can do it in ADL archetypes - and completely formally - using invariants - you have to write an invariant which mathematically relates the origin of the HISTORY (actuall, the EVENT_SERIES) object and the time of each event. But this makes it somewhat harder to define - less obvious, and also harder to implement - it means that invariant pasing and runtime processing have to be working.
With this change - you want to find and label the 1 minute, 5 minute and 10 minute Apgars - as the absolute time has no meaning.
The Editor allows you to constrain the run time name of the event.
My impression is that archetype can't constrain more than what reference information model can provide. In this case, there is no attribute "name" in the class EVENT, so it's not going to help very much even the archetype editor allows you to assign a name to EVENT. Maybe I got it wrong?
no you got it right. I have raised a CR in your name (= induction into openEHR hall of fame;-) to make EVENT inherit from LOCATABLE.
- thomas
Thomas Beale wrote:
Rong Chen wrote:
Thanks, Sam! Please see my comments below.
Sam Heard wrote:
Rong
This is an important consideration - especially if we are to get the event right. We have recently been moving away from offset to a datetime stamp for the items in the history - as this is easier and more realistic for summary data over a long period.
Good to know that, I guess it will perhaps appear in the CR list soon.
actually, the current model has an offset in each event, not the absolute time. This makes it easy to archetype, since you almost always want to archetype offsets like 1, 2, 5 mins in apgar, or 30 mins, 1h45mins in GTT. If we replace EVENT.offset: DV_DURATION with EVENT.time: DV_DATE_TIME, then archetyping it becomes harder - how do you constrain the date_time to be a certain offset from the origin? Actually, you can do it in ADL archetypes - and completely formally - using invariants - you have to write an invariant which mathematically relates the origin of the HISTORY (actuall, the EVENT_SERIES) object and the time of each event. But this makes it somewhat harder to define - less obvious, and also harder to implement - it means that invariant pasing and runtime processing have to be working.
With this change - you want to find and label the 1 minute, 5 minute and 10 minute Apgars - as the absolute time has no meaning.
The Editor allows you to constrain the run time name of the event.
My impression is that archetype can't constrain more than what reference information model can provide. In this case, there is no attribute "name" in the class EVENT, so it's not going to help very much even the archetype editor allows you to assign a name to EVENT. Maybe I got it wrong?
no you got it right. I have raised a CR in your name (= induction into openEHR hall of fame;-) to make EVENT inherit from LOCATABLE.
- thomas
Cool. Where is the CR by the way, I would like to follow it. I saw some openehr activities on jira.codehaus.org recently, can we start to use it to raise CRs?
Rong
Rong Chen wrote:
no you got it right. I have raised a CR in your name (= induction into openEHR hall of fame;-) to make EVENT inherit from LOCATABLE.
- thomas
Cool. Where is the CR by the way, I would like to follow it. I saw some openehr activities on jira.codehaus.org recently, can we start to use it to raise CRs?
not just yet - we are still determining whether it can do the job. Whichever system we go with, we will of course announce it. The intention is that people in a development group can raise a CR; anyone can raise a PR (problem report). This keeps the number of CRs down and ensures they are only written by people actually involved in a given project - i.e. people who would have some idea of what the change actually should be, rather than just identifying the problem.
- thomas