Please Tale me off this distribution list Norbert Lipszyc Envoy? de mon iPad
Le 13 ao?t 2013 ? 13:04, Thomas Beale <thomas.beale at oceaninformatics.com> a ?crit : > > 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. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130813/32a0e203/attachment.html>
