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
