Hello everyone, good time to you all.
Does the data_types in Better’s Archetype Designer include the ‘time_specification’?
You example is about DV_TIME not about DV_TIME_SPECIFICATION.
2 Likes
Sorry about that, I thought it was an uniformed question but obviously I was the one uninformed. 
thank you for pointing it out.
Here is the part of the spec that describes it’s intended use: Data Types Information Model
But the CKM appears to use a different pattern, by recording DV_DATE/TIME in a cluster slotted into INSTRUCTION.medication_order
@thomas.beale whats the status of that part of the spec?
Is it intended for process models (only?)
@borut.fabjan what is the support in AD (and better platform) for DV_TIME_SPECIFICATION?
That time specification is (AFAIK_ only used by the INSTRUCTION.activity.timing attribute. It is based on an older HL& GTS timing pattern and I’m pretty sure is not much used, if at all.
We don’t make use of it at all. It is a pretty opaque syntax, even to engineers, is overkill for simple timings and not sufficient to capture complex medication or service request timings. As well as the medication timing clusters there are also a set of service-related timing cluster archetypes. I’d strongly suggest using these, and not the activity.timings attribute.
1 Like
So shall we propose to deprecate that bit of the spec?
We have those data types in LinkEHR Studio, but as others said, I don’t think it has been ever used.
1 Like
I know some e.g @pablo have advocated more use of this attribute but it is really pretty obscure, even to technical people, so I’d be in favour of gentle deprecation
1 Like
@ian.mcnicoll I didn’t advocate more use of the attribute, but better specification. The issue is not the attribute, the issue is it’s practical implementation.
1 Like
Thanks Pablo - have you ever used the GTS timings in a real use-case. AFAIK they are not used much now if at all , even within the HL7 community. In general everyone has found structural approaches to timing much easier to work with.
Yes, I don’t remember if it was HL7v2.x or CDA, we used GTS, or one of it forms, for simple ranges and periodicity. The expression is quite powerful, though it’s difficult to input, basically the input form should be user friendly, like creating a calendar event with many periodicity and occurrences options, then that structure should be mapped to a string expression, which is the difficult part. Though not trivial, it can be done and the result is processable.
I understand the point of the TIME_SPECIFICATION in openEHR, though with archetypes being able to create complex structures, it seems modelers choose structures to model complex time expressions than TIME_SPECIFICATION. I’m not saying one approach is better than the other, just saying we have alternatives and most of the time one is chosen, though I’m not 100% if the reason is that is a better way of modeling a complex time expression or that the TIME_SPECIFICATION is actually misunderstood or maybe miss-specified in some way. Another option is that the lack of support on modeling tools makes modelers to have just one option: use the archetype for the structure, since TIME_SPECIFICATION is not available.
It’s kind of a deadlock situation: TS spec → no TS tool support → no TS use in archetypes → no TS use on CDRs → remove TS from specs
I would not rush things here. It would be worth to analyze how complex time expressions are entered by clinical users, then check if that could be mapped to a TIME_SPECIFICATION instance, if not, there is a good reason to remove it from the specs for good. If that is a good representation, we might want to try to support it on more modeling tools. You are more familiar than me on time specs for medication and other records that require complex timing 
3 Likes
I totally agree. It’s somehow similar to what also happens with the UCUM units. It might be a good specification or not, or it might just be a problem of having good modeling tools (or end user interfaces).
It is not just a case of the GTS specification being obscure and lacking tooling support. I t simply is not rich enough to handle the complexities of medication timing, and I suspect the timing requirements of other clinical orders such as social care provision.
For medication there is particular problem in that the dose and timing are inextricably linked at different levels, and a simple timing structure, even if layered dis not work.
I agree a careful review is required but I think we need to start to remove or deprecate unused RM features, as they get in the way of understanding. If GTS had wide adoption e.g. in FHIR, that might be different but that is not the case - they have gone down a similar route of a structural approach to timing.
1 Like
Does that happen for one case? Done cases? Many cases? Always?
I’m not sure if a use case that might not be so frequent is enough argument to data the DV doesn’t work for other cases or most of the time.
By doing some analysis we would understand the scope/limits of the DV, if it’s a good/bad fit for which use cases, and detect use cases that are exceptions to the scope of this DV in particular. We might find something useful out of the exercise.
In Medication it is the case for almost all prescriptions…
Something like
Paracetamol tablets 500mg 1-2 tablets 4 times a day
or
Paracetamol tablets 500mg-1000mg 4 times a day
or
Enalapril 2.5 mg each morning for 3 days then 5mg twice daily for 3 days then 10mg indefinitely
And that does not include cycles /patterns that are outside a single day e.g Only on Mon, Wed,Friday.
We made a major breakthrough in getting this to work that was just not possible with GTS.
The pattern also works for other requests like e.g Home care service delivery
Please attend for 3 hours per day on Tuesday and Saturdays
The question for me is why we would not deprecate GTS timing - if no-one is using it. It is just something that (as here) causes confusion).
I think the idea of having an expression of time is to represent some kind of pattern that could be processed by a computer program.
In this case:
That’s really a family of patterns, since it’s not analogous to say “every six hours”, “4 times a day” includes “every six hours” but also includes many other event patters, even some that are not patterns at all (need to express the occurrence of each of the 4 daily events as 4 individual point or interval time expressions).
So looking at a GTS to actually represent such an open use case isn’t really worth it at all. We could argue if “4 times a day” is actually a time specification at all. For me, is more like a time recommendation, which is less strict, something that could be better to represent as a free text, rather than as a computable expression.
Computationally, “4 times a day” means “the event can happen in any pattern, in any period or randomly, it just needs to happen 4 times in the same day”. Consider that is independent from the events actually happening, an outpatient could take the medication 3 times a day, 5 times a day, etc. so in this context “4 times a day” is still a recommendation, not a formal specification.
This would be different on an inpatient setting, for this there should be more defined (maybe computable) patterns. For instance, in this context there should be an expression like “each 6 hours”, since the nurse should know when to administer the medication.
This is a good post to help understand the scope of the GTS http://www.healthintersections.com.au/?p=769
For analyzing this one, we need to take out the time expression:
That would be:
- Event A: each morning (time interval) for 3 days (period)
- Event B: twice daily (again, this is a recommendation, not a pattern or specification, it’s the same problem as “4 times a day”) for 3 days (period)
- Event C: indefinitely (this is missing the times, I would consider this as incorrect)
Then there is a rule: Event B should start when Event A ends, AND, Event C should start when Event B ends.
Here we see a mix of requirements that do not match a pattern, for instance, there are recommendations mixed with rules. For me this is neither a time specification.
Considering the requirements, I wouldn’t expect GTS or TIME_SPECIFICATION to handle any of these cases. Those should handle cases that are actually time specifications, which follow a pattern and are computable.
And I agree with that. GTS shouldn’t even be considered for these requirements.
That is actually a time specification: there is a time period, a duration and a specific day pattern. It could be even expressed by a cron expression. What would be missing is a start point in time, like “attend at 10AM for 3 hours …”.
Still the question on why it’s not used is still open. If modeling tools don’t allow access to the data type, it’s impossible for anyone to do anything with it, even if it fits some use case, modelers and implementers will look for a workaround.
1 Like