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.
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
