Bjorn, Pablo,
we originally put in the timing field in ACTIVITY as a DV_PARSEABLE precisely
because there seemed to be no accepted standard for representing this
information. I think there is still no single accepted standard, but I think
that possible standards are better understood.
One
; openeh technical
Subject: RE: SV: ACTIVITY and timing
Hi Thomas, thanks for the input, is great to understand the rationale behind
ACTIVITY.timing.
Right now I've more questions than proposals :)
...The RM says that ACTIVITY.timing should always be present, and i believe
Hi Thomas,
On 13/08/2013 16:23, pablo pazos wrote:
Hi Thomas, thanks for the input, is great to
understand the rationale behind ACTIVITY.timing.
Right now I've more questions than proposals :)
On 13/08/2013 16:23, pablo pazos wrote:
Hi Thomas, thanks for the input, is great to understand the rationale
behind ACTIVITY.timing.
Right now I've more questions than proposals :)
...The RM says that ACTIVITY.timing should always be present, and i
believe it should be, otherwise
On Wed, Aug 14, 2013 at 08:11:50AM +0100, Thomas Beale wrote:
There is no assumption in ACTIVITY.time that the activity is
repeated. In the GTS syntax, you can just as easily express a one-off
event at a certain time as you can a repeated event. If you use cron
syntax, I think you just put a
On 14/08/2013 11:18, Karsten Hilbert wrote:
On Wed, Aug 14, 2013 at 08:11:50AM +0100, Thomas Beale wrote:
There is no assumption in ACTIVITY.time that the activity is
repeated. In the GTS syntax, you can just as easily express a one-off
event at a certain time as you can a repeated event. If
On Wed, Aug 14, 2013 at 11:41:58AM +0100, Thomas Beale wrote:
the problem isn't to do with not knowing which formalism is being
used - the DV_PARSABLE type takes care of recording that. I am just
saying that having too many alternative ways for implementers to
support is not necessarily a
Hi Bjorn, Pablo,
we originally put in the timing field in ACTIVITY as a DV_PARSEABLE
precisely because there seemed to be no accepted standard for
representing this information. I think there is still no single accepted
standard, but I think that possible standards are better understood.
One
Please
Tale me off this distribution list
Norbert Lipszyc
Envoy? de mon iPad
Le 13 ao?t 2013 ? 13:04, Thomas Beale thomas.beale at oceaninformatics.com a
?crit :
Hi Bjorn, Pablo,
we originally put in the timing field in ACTIVITY as a DV_PARSEABLE precisely
because there seemed
this distribution list
Norbert Lipszyc
Envoy? de mon iPad
Le 13 ao?t 2013 ? 13:04, Thomas Beale thomas.beale at oceaninformatics.com a
?crit :
Hi Bjorn, Pablo,
we originally put in the timing field in ACTIVITY as a DV_PARSEABLE
precisely because there seemed to be no accepted standard for representing
Hi Pablo
Thanks for the quick response!
I guess you are right regarding Cron and ISO 8601 when it comes to implement
the DV_PARSABLE attribute timing on the ACTIVITY class.
The openEHR-EHR-CLUSTER.timing.v1 is developed to define structured
information about the timing (intended or actual
-technical at lists.openehr.org
Date: Sun, 11 Aug 2013 08:54:04 +0200
Subject: SV: ACTIVITY and timing
Hi Pablo Thanks for the quick response! I guess you are right regarding Cron
and ISO 8601 when it comes to implement the DV_PARSABLE attribute timing on the
ACTIVITY class. The openEHR-EHR
Hi
ACTIVITY has a field for timing. It's datatype is parsable.
Some archetypes use a CLUSTER archetype to define detailed timing information
for the given ACTIVITY.
I am curious if anyone have experiences with implementing timing for Activity
and which strategy you are using?
Will detailed
http://cabolabs.com
From: b...@dips.no
To: openehr-technical at lists.openehr.org
Date: Sat, 10 Aug 2013 10:24:14 +0200
Subject: ACTIVITY and timing
Hi ACTIVITY has a field for timing. It's datatype is parsable. Some archetypes
use a CLUSTER archetype to define detailed timing information
14 matches
Mail list logo
