Good morning! That archetype seems very new, my recommendation is to use it carefully. The purpose states: ...suitable for computation and display for human interpretation. The second part is not accomplished (directly) by ACTIVITY.timing (a clinician will not understand a cron expression :) In the other hand, ACTIVITY.timing is mandatory in the information model, but in my case I don't use it (let's say I use an empty constraint that allows any timing there, because I can't put there something like ASAP, because I'm dealing with emergency cases). A wild guess about the use of openEHR-EHR-CLUSTER.timing.v1 would be to give structure to timing specifications entered by users, e.g. when you create an event on google calendar and you can configure repetitions / frequency, etc. Then, with that info, you can create a cron expression or ISO6801 duration, and put that on ACTIVITY.timing, and use that expression to trigger events, control ACTIVITY execution, etc. I believe the transformation between data in the CLUSTER to a timing expression is straight forward, but the inverse transformation is not (different timing specification structures could give the same cron expressions). I think the CLUSTER solves a problem for us developers: to know how to create a UI for timing data input. Because ACTIVITY.timing does not appear in archetypes, we have a lot of options of how to develop a UI to get timing info from the user, that will be totally custom, and we have to transform that information from our custom format to a parsable ACTIVITY.timing. With the CLUSTER, the structure is standardized, and we can create not so custom UIs and more generic transformations that we can reuse in different systems. About interchange, both (structure and expression) are suitable to be interchanged and interpreted correctly, the first because you have an archetype that helps the receiver to know how to process the received data, and the latter because is a parsable expression, and the DV_PARSABLE contains all the metadata needed to interpret the data correctly (e.g. choose the right parser).If a system can interpret openEHR archetyped data, it can interpret the timing CLUSTER. If a system supports the information model, then it can handle ACTIVITY.timing.
-- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com From: b...@dips.no To: openehr-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-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 10www.dips.com 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.comFrom: bna at dips.no To: openehr-technical at lists.openehr.org Date: Sat, 10 Aug 2013 10:24:14 +0200 Subject: ACTIVITY and timingHi 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 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list 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/1349bdf4/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4149 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130811/1349bdf4/attachment-0001.png>
