ACTIVITY and timing

Technical (archive)
1

Hi
ACTIVITY has a field for timing. It’s datatype is parsable.
Some archetypes use a CLUSTER archetype to define detailed timing information for the given ACTIVITY.

I am curious if anyone have experiences with implementing timing for Activity and which strategy you are using?
Will detailed timing information in a CLUSTER make timing information on Activity obsolete? Or will detailed timing information on Activity remove the need for a timing CLUSTER?

Bjørn Næss
Product Owner
DIPS ASA

Mobil +47 93 43 29 10

2

Hi Bjørn,

I don’t use timing yet, but only because the healthcare domains I’m working on doesn’t require complex timing management.
Said that, I have investigated how to use timing for more complex scenarios, like hospitalization medication management.

One option is to use cron expressions. That’s great because is a de facto standard for developers, and linux support that at the OS level. So it’s something that you can write/parse but also execute to trigger events. Another option would be to use ISO 8601 duration notation, standard and easy to create/parse. I’m sure there are more options out there, but I would recommend those two.

In my opinion the current specs lack information about how to use timing, and that makes things more complex to us (developers).

http://en.wikipedia.org/wiki/Cron
http://en.wikipedia.org/wiki/ISO_8601

3

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.

With regards,
Bjørn Næss
Product owner
Telephone +47 75 59 24 55
Mobile +47 93 43 29 10

www.dips.com

This message is for the designated recipient only and may contain confidential or private information. If you have received it in error, please notify the sender immediately and delete the original.

4

Good morning!

That archetype seems very new, my recommendation is to use it carefully.

The purpose states: …suitable for computation and display for human interpretation.
The second part is not accomplished (directly) by ACTIVITY.timing (a clinician will not understand a cron expression :slight_smile:

In the other hand, ACTIVITY.timing is mandatory in the information model, but in my case I don’t use it (let’s say I use an empty constraint that allows any timing there, because I can’t put there something like ASAP, because I’m dealing with emergency cases).

A wild guess about the use of openEHR-EHR-CLUSTER.timing.v1 would be to give structure to timing specifications entered by users, e.g. when you create an event on google calendar and you can configure repetitions / frequency, etc. Then, with that info, you can create a cron expression or ISO6801 duration, and put that on ACTIVITY.timing, and use that expression to trigger events, control ACTIVITY execution, etc. I believe the transformation between data in the CLUSTER to a timing expression is straight forward, but the inverse transformation is not (different timing specification structures could give the same cron expressions).

I think the CLUSTER solves a problem for us developers: to know how to create a UI for timing data input. Because ACTIVITY.timing does not appear in archetypes, we have a lot of options of how to develop a UI to get timing info from the user, that will be totally custom, and we have to transform that information from our custom format to a parsable ACTIVITY.timing. With the CLUSTER, the structure is standardized, and we can create not so custom UIs and more generic transformations that we can reuse in different systems.

About interchange, both (structure and expression) are suitable to be interchanged and interpreted correctly, the first because you have an archetype that helps the receiver to know how to process the received data, and the latter because is a parsable expression, and the DV_PARSABLE contains all the metadata needed to interpret the data correctly (e.g. choose the right parser).
If a system can interpret openEHR archetyped data, it can interpret the timing CLUSTER. If a system supports the information model, then it can handle ACTIVITY.timing.

(attachments)

image001.png

5

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&gt;\. Please feel free to work on this page rather than just in the mailing lists.

- thomas

(attachments)

iedfciga.png

6

Hi Thomas, thanks for the input, is great to understand the rationale behind ACTIVITY.timing.

Right now I’ve more questions than proposals :slight_smile:

“…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)

(attachments)

iedfciga.png

7

Hi Pablo & all,

I’m working on the medication list at the moment and have had discussion with others.

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.

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.

(attachments)

iedfciga.png

8

There is no assumption in ACTIVITY.time that the activity is repeated. In the GTS syntax, you can just as easily express a one-off event at a certain time as you can a repeated event. If you use cron syntax, I think you just put a full date / time from memory (although that’s pretty unusual usage of cron syntax). One crucial thing is to ensure that these data remain interoperable. To do that, we need to limit the syntaxes that could be used in ACTIVITY.timing to a reasonably small number, and standardise their use. I am not sure for example, if it will be a good idea to have 3 ways of expressing ‘3 times/day for 7 days’ or other typical things. - thomas

9

Adding a namespace (prepending "cron://", "GTS://" or some such) may help.

Karsten

10

the problem isn't to do with not knowing which formalism is being used - the DV_PARSABLE type takes care of recording that. I am just saying that having too many alternative ways for implementers to support is not necessarily a good thing....

- thomas

11

True enough.

Karsten

12

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

13

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 :slight_smile:

Cheers,

-koray

(attachments)

iedfciga.png

14

Hi Thomas,

Hi Thomas, thanks for the input, is great to understand the rationale behind ACTIVITY.timing.

Right now I’ve more questions than proposals :slight_smile:

“…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?

There is no assumption in ACTIVITY.time that the activity is repeated. In the GTS syntax, you can just as easily express a one-off event at a certain time as you can a repeated event. If you use cron syntax, I think you just put a full date / time from memory (although that’s pretty unusual usage of cron syntax).

I understand that timing can express just one date or a set of dates, what I try to understand is more about semantics: what’s the purpose / meaning of having just one date on ACTIVITY.timing?

If the answer is to “specify the exact date/time that the ACTIVITY should be executed”, the RAD/LAB case can be taken as a counter example, because the execution time depends on scheduling, and that is done after the recording the ACTIVITY.

I don’t know if I made that clear, please let me know if my question is not clear or if my understanding of the timing attribute is incorrect.

One crucial thing is to ensure that these data remain interoperable. To do that, we need to limit the syntaxes that could be used in ACTIVITY.timing to a reasonably small number, and standardise their use. I am not sure for example, if it will be a good idea to have 3 ways of expressing ‘3 times/day for 7 days’ or other typical things.

Is not a problem to have several ways of expressing timing, as long as those are specified publicly. Then we just need to define some terminilogy subset to express each notation identifier e.g. as MIME-TYPE for email content. Then when we parse the expression, knowing the term id, we can choose the right parser. Obviously we need to write those, that’s the easy part, but is easy only if all the notation specs are available and the term subset is specified.

  • thomas

_______________________________________________ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

15

here, I didn’t mean anything special by the word ‘processing’ - I just meant any software that looks at this object - it should expect to be able to decode and do things with the timing information, e.g. display it in a human-comprehensible way, maybe generate notifications from it etc. - t

16

One way of modelling it would be: agree, but obviously 2 or 3 is better than 20 or 30 posibilities! - thomas