We use the HL7 V2 TQ data type representation since it has been used in healthcare systems for 30 years and supports many of the weird and familiar timing scenarios such as BID etc.
Regards Heath On 13/08/2013, at 8:34 PM, Thomas Beale <thomas.beale at oceaninformatics.com> wrote: Hi Bjorn, Pablo, we originally put in the timing field in ACTIVITY as a DV_PARSEABLE precisely because there seemed to be no accepted standard for representing this information. I think there is still no single accepted standard, but I think that possible standards are better understood. One of the complicating factors is that timing that is linked to real world events (e.g. 'take one after evening meal') doesn't have a widely accepted representation. The HL7 GTS format is not widely liked, and probably doesn't deal with enough situations anyway. But it was a decent attempt, and i for one don't know of any standard that cleanly mixes purely clock timing concepts with real world events. 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 , if it is optional. It should always be meaningful as well, even if it's not guaranteed to be 100% correct. By that I mean that this field can only contain parseable (and therefore formal) timing expressions that might provide the overall correct dosage picture, e.g. 'every 8 hours', but extra information might be provided somewhere else to refine that, e.g. to say 'after meals'. However, the danger is that timing information provided elsewhere is not standardised. The timing archetype in CKM is as follows: <iedfciga.png> There is a parseable expression as the last item. I think to solve this properly, we would need to understand: * the range of requirements of clinical modellers (we know many basic needs, but I am sure in recent years, more exotic timing requirements have been discovered) * which of those could be formally expressed, which can't - and in what formalism * if there is no formal expression that handles all requirements, is it ok to use one for (we assume) 80% of cases that are in fact formalisable? * how can timing that is formalised in some ugly unreadable syntax be archetyped by clinical modellers who quite rightly wouldn't touch such a syntax? I.e. how do we make it look like the above archetype, but computer processable all the same? * if there is a formal expression, what will software do with it? Possibilities: * display it (i.e. app - back-end interoperability) * share it with other systems (i.e. system-system interoperability) * actually process it in some way, e.g. generate notifications to someone, e.g. nurse, patient? The problem is, I think solving the timing problem definitively might never happen, since there always seems to be some weird new need around the corner, and the possible uses of the information in the hospital are likely to be quite different from community / GP-based healthcare. I think that the 'basic' part of any timing than can easily be formalised in GTS, iCal, cron (I hadn't thought of cron before, but as an old unix guy, it's not a bad one actually) should be formalised, and should be put in the ACTIVITY.timing field. I also think that any extra information should be in a known location. Do we need an 'other_timing_details: CLUSTER' field in ACTIVITY? We need some input from clinical professionals and archetype modellers here to get further. Whatever the final solution might be, we should put up a guidance page on the wiki now, so I created a new page for this here <http://www.openehr.org/wiki/display/spec/ACTIVITY+Timing+in+Instructions> . Please feel free to work on this page rather than just in the mailing lists. - thomas On 11/08/2013 07:54, Bj?rn N?ss wrote: 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. _______________________________________________ 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/20130815/9c0b6776/attachment.html>
