Hi Koray,
I think the RM timing attribute really refers to the date/time when the information about that Activity was committed ? not necessarily the actual time the event modelled in an Action type of entry. So it can be an arbitrary date/time, e.g. within the next 2 weeks etc. It may not happen in real life (e.g. waiting lists or patient no show etc.) but if/when happens the ACTION will capture that. Reviewing the specs, I think that's not correct. For recording ACTIVITY commit times, the model would use DvDateTime instead of DvParsable, and there are a lot of places you can use to record that time, e.g. in the COMPOSITION, AUDIT_DETAILS, ...The specs say that's the time spec for the planned ACITIVY, i.e. when the ACTIVITY should be executed by an ACTION, not when the ACTIVITY was recorded or committed "... the timing information in each Activity does indicate times, days and the usual specifications of ?with meals? etc. The timing information is also sufficient to specify a three drug chemotherapy regime, by indicating which days each drug is administered on." ehr_im page 60 A related issue, I think it?d be a good idea to include within the archetype very clear description of timing (as opposed to capturing using RM date/time from a series of related archetypes) for summary type records (e.g. medicines list, care summaries, reconciliation report etc.) I think it is a bit too much to expect EHR systems to look at each and every relevant archetype (in this case Instruction and Action types) and create a summary view by finding which one is the beginning, most recent etc. While individual events? timing can be dealt with RM timing attribute I think summary type instances should capture this information. Anyway I may be wrong or even not directly an answer to current topic but relevant. For planned ACTIVITIES is good to have a clear time specification for executing those ACTIVITIES. That was what I meant on previous emails comparing the archetyped timing vs. the parsable on ACTIVITY.timing: the archetyped form help us (developers) to create the UI and DB on one way, the parsable form give us too much freedom (sometimes this is a problem :) Cheers, -koray From: openEHR-clinical [mailto:[email protected]] On Behalf Of pablo pazos Sent: Wednesday, 14 August 2013 3:24 a.m. To: openEHR Clinical; openeh technical Subject: RE: SV: ACTIVITY and timing 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? BTW, for all in this discussion, there are some awesome slides from Sam that shows different timing options for medication: http://www.slideshare.net/atalagk/what-if-we-never-agree-on-a-common-health-information-model (form slide 6) -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com Date: Tue, 13 Aug 2013 12:04:12 +0100 From: [email protected] To: openehr-technical at lists.openehr.org; openehr-clinical at lists.openehr.org Subject: Re: SV: ACTIVITY and timing 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: 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. 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-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_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/20130815/30365ef6/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 19468 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130815/30365ef6/attachment-0001.png>
