SV: ACTIVITY and timing
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
SV: ACTIVITY and timing
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 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. Adding a namespace (prepending cron://, GTS:// or some such) may help. Karsten -- GPG key ID E4071346 @ gpg-keyserver.de E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
SV: ACTIVITY and timing
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 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. Adding a namespace (prepending cron://, GTS:// or some such) may help. Karsten 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 good thing - thomas
SV: ACTIVITY and timing
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 good thing True enough. Karsten -- GPG key ID E4071346 @ gpg-keyserver.de E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
How to start
Erik, do you have content you want on that learning centre page? If so, let's put it up there. - tom On 08/08/2013 21:27, Erik Sundvall wrote: Hi! On Wed, Aug 7, 2013 at 3:21 AM, Lexis Nexis lexisnexis5490 at gmail.com wrote: Is there a tutorial book I can purchase or some examples? Step-by-step tutorial is best. Skim through the document http://www.openehr.org/releases/1.0.2/architecture/overview.pdf to get an overview then go back to that and other documents for more detail when needed. Also there are some videos at http://www.openehr.org/resources/learning_centre if you prefer watching over reading. If you don't mind using alpha-versions of work in progress, then feel free to do some openEHR hands-on experiments using https://github.com/LiU-IMT/EEE described in the paper http://www.biomedcentral.com/1472-6947/13/57 (Appendix B at http://www.biomedcentral.com/1472-6947/13/57#sec9 is a very compact openEHR intro, perhaps too compact.) I hope the instructions at https://github.com/LiU-IMT/EEE/wiki/install helps you get it up and running. Try running and modifying AQL queries on the provided example content for example. Best regards, Erik Sundvall Tel: +46-72-524 54 55 LiO: erik.sundvall at lio.se http://www.lio.se/Verksamheter/IT-centrum/ LiU: erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ P.s. to list readers: I Hope to see many of you openEHR people at Medinfo in Copenhagen soon! ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Ocean Informatics http://www.oceaninformatics.com/*Thomas Beale Chief Technology Officer* +44 7792 403 613Specification Program, /open/EHR http://www.openehr.org/ Honorary Research Fellow, UCL http://www.chime.ucl.ac.uk/ Chartered IT Professional Fellow, BCS http://www.bcs.org.uk/ Health IT blog http://wolandscat.net/category/health-informatics/ View Thomas Beale's profile on LinkedIn http://uk.linkedin.com/in/thomasbeale -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130814/080d9181/attachment-0001.html -- next part -- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 4085 bytes Desc: not available URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130814/080d9181/attachment-0001.jpg -- next part -- A non-text attachment was scrubbed... Name: btn_liprofile_blue_80x15.png Type: image/png Size: 511 bytes Desc: not available URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130814/080d9181/attachment-0001.png
