Specs about ACTIVITY.timing still unclear

[pablo (Pablo Pazos)]

Hi,

I was reviewing the latest specs and, compared with 1.0.2 where ACTIVITY.timing usage is not so clear, I think we still need to improve that specific point.

1. timing description is too focused on medication

“Many Instructions will have only one Activity, usually describing a medication to be administered and its timing…”

A treatment or procedure instruction can also be repeated, like do physiotherapy 3 times a week, ultrasound application daily for 10 repetitions, etc. (you can notice I sprained an ankle not so long ago).

2. specific codes / syntax to be used

I think for the sake of completeness we need to include this in the specs. I reviewed the time specification from the data_types spec v1.0.2 and I’m not sure we are defining the syntax we need for ACTIVITY.timing.

On HL7 specs I’ve seen a lot of commonly used codes that I don’t know if those are defined in any standard or if those are just common medical vocabulary, I mean: ac, pc, bid, tid, qid, qhs, q4h, q8h, q12h, prn, …

Maybe we can include those as part of the specs

3. the timing field description references HL7 GTS and ISO 8601

From HL7 v3 specs, the XML form is clear enough and it has a XSD that defines the GTS, but the literal expression (the string code) is not so obvious (AFAIK the rules to create it are not formally defined). What I’m not sure of is if we can use the XML form (might complicate XSD validation or the literal form). From v3:

Literal Expression | Meaning |

• | - |
  M09 D15 H16 N30 S34.12 | September 15 at 4:30:34.12 PM as the intersection of multiple periodic intervals of times (calendar patterns) |
  M0915163034.12 | September 15 at 4:30:34.12 PM as one simple periodic interval of time (calendar pattern) |
  M01; M03; M07 | January, March, and July (a union of three periodic intervals of time) |
  M04..09 M/2 | Every second month from April to September (April, June, August) |
  J1; J2; J4 | Monday, Tuesday, Thursday |
  W/2 J2 | every other Tuesday (intersection of every other week and every Tuesday) |
  1999 WY15 | the 15th calendar week in 1999 (period code is optional for the highest calendar unit) |
  WM2 J6 | Saturday of the 2nd week of the month |
  M05 WM2 J6 | Saturday of the 2nd week of May |
  M05 DM08..14 J7 | Mother’s day (second Sunday in May.) |
  J1..5 H0800..1600 | Monday to Friday from 8 AM to 4 PM |
  J1..4 H0800..1600;
  J5 H0800..1200 | Monday to Thursday 8 AM to 4 PM and Friday 8 AM to 12 noon. |
  [10 d] H/8 | Three times a day over 10 days (each time a 60 minutes interval). |
  H0800..1600 \J3 | Every day from 8 AM to 4 PM, except Wednesday. |
  (M0825..31 J1)..M0831 | The last calendar week of August. |
  JHNUSMEM..JHNUSLBR | The season from the U.S. holidays Memorial Day to Labor Day |

And about ISO, I think we are talking about the “repeating intervals” form (https://en.wikipedia.org/wiki/ISO_8601#Repeating_intervals). If that is corrent, we should say that on the spec (the referenc to ISO 8601 is vague). On the other hand, the ISO specification is not publicly available, so we are referencing a closed spec from an open spec. That’s why I think we should define the syntax in our specs to avoid referencing closed specs.

[system]

Hi Pablo,

I think it is fair to say that ACtivity.timing not used much (if at all). The various timing syntax options are far from standardised around the world.

.timing is also difficult since real-world timings are often nested and need to be associated with specific parts of the archetype.

The approach we have taken with Medication is to develop two timing Cluster archetypes.

Timing - daily, Draft Archetype [Internet]. openEHR Foundation, openEHR Clinical Knowledge Manager [cited: 2016-06-18]. Available from: http://openehr.org/ckm/#showArchetype_1013.1.2245

and

Timing - repetition, Draft Archetype [Internet]. openEHR Foundation, openEHR Clinical Knowledge Manager [cited: 2016-06-18]. Available from: http://openehr.org/ckm/#showArchetype_1013.1.2246

and have also allowed for a parseable dose string in the Medication order archetype.

Medication order, Draft Archetype [Internet]. openEHR Foundation, openEHR Clinical Knowledge Manager [cited: 2016-06-18]. Available from: http://openehr.org/ckm/#showArchetype_1013.1.1445

I have an outstanding task to show some examples of use in more complex medication orders.

Personally, I advise implementers to avoid ACTIVITY.timing.

I would be interested to know if/how others use it.

Ian

[pablo (Pablo Pazos)]

Thanks for your message Ian,

IMO avoiding the implementation of ACTIVITY.timing raises the question of why that was introduced in the model and if we should keep it or not.

On the other hand, I think timing there can be a powerful tool for advanced systems that can use that info to manage / automate flows / processes.

The problem with timing is that it is difficult to specify in a generic way, and I have seen at least 3 kinds of proposals:

1. Computable expressions
2. Terminology based
3. Structure based

1. Computable expressions

• idea: try to define a code that can be processed by software.
• pro: everyone loves codes, systematized approach
• con: expressions are too complex to be defined just by a code, makes this solution almost unrealistic.

2. Terminology based

• idea: just define all the possible timing schemes and their definitions e.g. QID, Q4H, AC, PC, …
• pro: easy to use, easier to define and maintain than approach 1.
• con: ?

3. Structure based

• idea: define a structure (maybe a hierarchy in an UML model) to represent different timing expressions (like the HL7 time expressions datatypes or what Ian mentioned of creating a CLUSTER archetype)
• pro: easy to specify in an OO model, extendable, easy to implement (the model can include state + behavior)
• con: ?

I would like we consider to make a proposal on how to use timing on the openEHR specs, oriented to implementation, and not focused only on medication (current specs examples are just for medication).

1. We can extend our timing specification to be compatible with the HL7 / FHIR one (add/modify our datatypes). I think with this we don’t need to make custom timing specs on archetypes.
2. Add to our terminology spec the most commonly used terms for timing, so we can use them as part of our timing specification.
3. Add more examples oriented to long term treatment, procedures, tests, etc. alongside with medication therapy in the specs, or maybe in a “timing addendum”.

OR

Define to remove timing completely from the openEHR model and rely on archetyped timing on ACTIVITY.description.

[system]

it was included on the assumption that timing would be represented as a formal expression, like HL7 GTS, which uses a ISO 8601-derived expression. I think the attribute should stay there because it allows this kind of approach, which is more computable. Whether it is always used is another question - I am concerned that there may be too much ad hoc modelling going on in archetype-land, without paying enough attention to the RM facilities in some areas. only some expressions are too complex; most are not. It’s always a 90/10 situation. I think the mistake on the part of some is that because there is a 10% set of cases that can’t easily be represented as expressions, they want to ditch that approach and use something else entirely, when in fact expressions would work most of the time. the con is that you have to have a terminology concept for every possible permutation of expressions - that’s not realistic. Unless you rely on post-coordination, but then you are really just using terminology as a weak expression language. this is the equivalent of 1. If you can represent something as a formal structure, you can represent it as an expression, these are two things that lie on either side of the thing called a parser Also, the structural representation of a very compact expression string may be quite large. I’m not sure if we need to do anything special - if someone wants to use , we just need an expression form of that, and since ACTIVITY.timing is a DV_PARSEABLE, its syntax can be set to ‘FHIR::timing’ or similar. - thomas

[Heath_Frankel3 (Heath Frankel)]

We have more recently used iCAL for Instruction timing not associated with Medication orders such as service requests. It has served us well so far. Although FHIR has its own Appointment resource, they actually suggest the use of iCal instead of using this resource.

I am not sure if iCal could be used for Medication, theoretically it may be possible but we would need someone that knows iCal better than I and a clinician to work through the use cases.

Heath