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 administration or use of a medicine, other therapeutic good or other intervention that is given on a scheduled basis." And it's intended use is "with medication orders and other instructions where timing is complex and needs to be computable." This archetype does also include a parsable element named "parsable syntax". So the key question is: To be able to exchange structured information about timing - would it be better to use openEHR-EHR-CLUSTER.timing.v1 or should we use the mandatory parsable timing attribute on ACTIVITY class? I can see pros and cons: Use the attribute on ACTIVITY class: ? To use an attribute that is always present (in EHR Information Model). ? To reduce clinical modeling effort - since you don't have to include structure about timing in every ACTIVITY. (I guess clinical modeling should be done with specialization some way to define an Action Archetype with timing information). Use the openEHR-EHR-CLUSTER.timing.v1 (or another defined structure) ? to be able to share timing information as Archetype defined structure between openEHR enabled systems . ? to be able to let the Clinical Modeling people define the complexity of timing in HealthCare I can also see some challenges with the optional attribute WF_DEFINITION on the INSTRUCTION class and the mandatory attribute timing on the ACTIVITY class. I think there will be some correlation between these attributes in a given use-case. With regards, Bj?rn N?ss Product owner Telephone +47 75 59 24 55 Mobile +47 93 43 29 10 www.dips.com<http://www.dips.com/> [cid:image001.png at 01CE9670.54B7FA90] This message is for the designated recipient only and may contain confidential or private information. If you have received it in error, please notify the sender immediately and delete the original. Fra: openEHR-technical [mailto:openehr-technical-bounces at lists.openehr.org] P? vegne av pablo pazos Sendt: 10. august 2013 14:21 Til: openeh technical Emne: RE: ACTIVITY and timing Hi Bj?rn, I don't use timing yet, but only because the healthcare domains I'm working on doesn't require complex timing management. Said that, I have investigated how to use timing for more complex scenarios, like hospitalization medication management. One option is to use cron expressions. That's great because is a de facto standard for developers, and linux support that at the OS level. So it's something that you can write/parse but also execute to trigger events. Another option would be to use ISO 8601 duration notation, standard and easy to create/parse. I'm sure there are more options out there, but I would recommend those two. In my opinion the current specs lack information about how to use timing, and that makes things more complex to us (developers). http://en.wikipedia.org/wiki/Cron http://en.wikipedia.org/wiki/ISO_8601 -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com<http://cabolabs.com/es/home> ________________________________ From: bna at dips.no<mailto:b...@dips.no> To: openehr-technical at lists.openehr.org<mailto: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 for the given ACTIVITY. I am curious if anyone have experiences with implementing timing for Activity and which strategy you are using? Will detailed timing information in a CLUSTER make timing information on Activity obsolete? Or will detailed timing information on Activity remove the need for a timing CLUSTER? Bj?rn N?ss Product Owner DIPS ASA Mobil +47 93 43 29 10 _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org<mailto:openEHR-technical at lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130811/60b91d63/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4149 bytes Desc: image001.png URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130811/60b91d63/attachment-0001.png>
