Hi
You need to unsubscribe yourself via the link at the bottom of the list
email.
Ian
Dr Ian McNicoll
Clinical modelling consultant Ocean Informatics
Mobile +44 (0) 775 209 7859
Skype imcnicoll
On 13 Aug 2013, at 12:46, Lipszyc Norbert <irl at club-internet.fr> wrote:
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<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-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/20130813/efe0b658/attachment-0001.html>
