We use the HL7 V2 TQ data type representation since it has been used in
healthcare systems for 30 years and supports many of the weird and familiar
timing scenarios such as BID etc.
Regards
Heath
On 13/08/2013, at 8:34 PM, Thomas Beale thomas.beale at oceaninformatics.com
wrote:
Hi
; 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 to be no
Hi
You need to unsubscribe yourself via the link at the bottom of the list
email.
Ian
Dr Ian McNicoll
Clinical modelling consultant Ocean Informatics
Mobile +44 (0) 775 209 7859
Skype imcnicoll
On 13 Aug 2013, at 12:46, Lipszyc Norbert irl at club-internet.fr wrote:
Please
Tale me off this
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) of
-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
12 matches
Mail list logo
