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: [email protected] Date: Sat, 18 Jun 2016 08:41:13 +0100 Subject: Re: Specs about ACTIVITY.timing still unclear To: [email protected] CC: [email protected] 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: [email protected] twitter: @ianmcnicoll Co-Chair, openEHR Foundation [email protected], freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 18 June 2016 at 03:26, pablo pazos <[email protected]> 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 SpecificationsLiteral ExpressionMeaningM09 D15 H16 N30 S34.12September 15 at 4:30:34.12 PM as the intersection of multiple periodic intervals of times (calendar patterns)M0915163034.12September 15 at 4:30:34.12 PM as one simple periodic interval of time (calendar pattern)M01; M03; M07January, March, and July (a union of three periodic intervals of time)M04..09 M/2Every second month from April to September (April, June, August)J1; J2; J4Monday, Tuesday, ThursdayW/2 J2every other Tuesday (intersection of every other week and every Tuesday)1999 WY15the 15th calendar week in 1999 (period code is optional for the highest calendar unit)WM2 J6Saturday of the 2nd week of the monthM05 WM2 J6Saturday of the 2nd week of MayM05 DM08..14 J7Mother's day (second Sunday in May.)J1..5 H0800..1600Monday to Friday from 8 AM to 4 PMJ1..4 H0800..1600; J5 H0800..1200Monday to Thursday 8 AM to 4 PM and Friday 8 AM to 12 noon.[10 d] H/8Three times a day over 10 days (each time a 60 minutes interval).H0800..1600 \J3Every day from 8 AM to 4 PM, except Wednesday.(M0825..31 J1)..M0831The last calendar week of August.JHNUSMEM..JHNUSLBRThe 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 http://cabolabs.com _______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
