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). 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. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130814/b69a1618/attachment.html>
