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:
o display it (i.e. app - back-end interoperability)
o share it with other systems (i.e. system-system interoperability)
o 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130813/2aef0d8f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iedfciga.png
Type: image/png
Size: 19468 bytes
Desc: not available
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130813/2aef0d8f/attachment-0001.png>
