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 :)
"...The RM says that ACTIVITY.timing should always be
present, and i believe it should be, otherwise processing
software doesn't know what to do..."
Should all INSTRUCTION/ACTIVITIES be processed by a
processing software?
My guess is no, but maybe I'm wrong. It would be great to
hear arguments on that.
The need for timing seems to be required for medication
INSTRUCTIONs, or generalizing that: all INSTRUCTIONS that
involve some kind of event repetition/frequency.
But what about LAB/RAD requests? Those are one time events,
and their execution depends on scheduling, i.e. timing on
request could not be something formal and specific. In
practice, the only time specification I know for LAB/RAD
requests is the urgent flag, and the real time of execution
depends on the resource availability on each health center.
What do you think about timing specification of ACTIVITIES
that have no repetitions?
What values should we use for ACTIVITY.timing when
recording a RAD request?
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 full date / time from memory
(although that's pretty unusual usage of cron syntax).
I understand that timing can express just one date or a set of dates, what I
try to understand is more about semantics: what's the purpose / meaning of
having just one date on ACTIVITY.timing?
If the answer is to "specify the exact date/time that the ACTIVITY should be
executed", the RAD/LAB case can be taken as a counter example, because the
execution time depends on scheduling, and that is done after the recording the
ACTIVITY.
I don't know if I made that clear, please let me know if my question is not
clear or if my understanding of the timing attribute is incorrect.
One crucial thing is to ensure that these data remain interoperable.
To do that, we need to limit the syntaxes that could be used in
ACTIVITY.timing to a reasonably small number, and standardise their
use. I am not sure for example, if it will be a good idea to have 3
ways of expressing '3 times/day for 7 days' or other typical things.
Is not a problem to have several ways of expressing timing, as long as those
are specified publicly. Then we just need to define some terminilogy subset to
express each notation identifier e.g. as MIME-TYPE for email content. Then when
we parse the expression, knowing the term id, we can choose the right parser.
Obviously we need to write those, that's the easy part, but is easy only if all
the notation specs are available and the term subset is specified.
- thomas
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130815/6f6234ac/attachment.html>
