RE: Specs about ACTIVITY.timing still unclear

[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

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Thomas Beale
Sent: Wednesday, 13 July 2016 5:59 PM
To: openehr-technical@lists.openehr.org
Subject: Re: Specs about ACTIVITY.timing still unclear




On 26/06/2016 22:23, pablo pazos wrote:
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.

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.



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.

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.




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

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.



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

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 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).

I'm not sure if we need to do anything special - if someone wants to use FHIR 
timing<http://hl7-fhir.github.io/datatypes.html#Timing>, 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



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.


No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2015.0.6201 / Virus Database: 4627/12599 - Release Date: 07/11/16
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Specs about ACTIVITY.timing still unclear

[Thomas Beale]

On 26/06/2016 22:23, pablo pazos wrote:

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.


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.




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.


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.





*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: ?



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.




*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: ?



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 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).


I'm not sure if we need to do anything special - if someone wants to use 
FHIR timing , 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



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.


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Specs about ACTIVITY.timing still unclear

[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.


-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

From: i...@freshehr.com
Date: Sat, 18 Jun 2016 08:41:13 +0100
Subject: Re: Specs about ACTIVITY.timing still unclear
To: openehr-technical@lists.openehr.org
CC: s...@lists.openehr.org

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.
IanDr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnicoll@openehr.orgDirector, freshEHR 
Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 18 June 2016 at 03:26, pablo pazos <pazospa...@hotmail.com> wrote:



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, p

Re: Specs about ACTIVITY.timing still unclear

[Ian McNicoll]

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

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll

Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 18 June 2016 at 03:26, pablo pazos  wrote:

> 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:
>
>   Table 46: Examples for Literal Expressions for Generic Timing
> Specifications
> Literal ExpressionMeaning
> 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.
>
> --
> Kind regards,
> Eng. Pablo Pazos Gutiérrez