Can we get some feedback on this Specification JIRA request?
We need a new set of terms to represent customary times of day, as often specified by healthcare staff in hospitals, for prescriptions and so on. At least:
morning
afternoon
evening
night
overnight
And probably also
early morning
early afternoon
early evening
late morning
late afternoon
I replied …
I can’t say I am very keen on making these part of the openEHR terminology - feels more like something that should be handled in a general reference terminology. What’s the context of use? We did discuss the use of standard coded ‘time events’ but decided that the potential list was just too variable and, in any case, inconsistent.
Let’s discuss with clinical list / slack and see if there is a way ahead.
Though that would raise some licensing issues as thing stand
I see that FHIR now has Codesystem-event-timing - FHIR v5.0.0 and I think that would be my preference to adopt/suggest, rather than openEHR maintining a new vocabaulary.
Timing is really non standardadazed, so anything would make things better. I’m OK on recommending/adopting the fhir valueset, would ease transformations
FHIR now has Codesystem-event-timing - FHIR v5.0.0 and I think that would be my preference to adopt/suggest, rather than openEHR maintaining a new vocabulary.
I’ve taken the liberty of copying @Joost’s comments from JIRA, as there are some important broader questions in there
Why do we need it?
And do we need it at RM level? Or archetype/template level?
A concern I have is that the semantics are unclear and differ by country/region. E.g. morning is 6-12am in NL. But different timings in Belgium. It’s easy to see these descriptions translated into (normal numeric) timings by implementers unaware of regional semantics. This would break semantic interoperability across regions. For e.g. medications this could be a safety issue.
Ideas for solving this? Or a risk assessment?
I also wonder if this is the first time we depend on HL7 for a part of the spec. I’m not against it perse, and prefer to reference actually instead of duplicating work, but if it’s not already done, I think we need some risk/benefit analysis, given the different scope and priorities of HL7 vs openEHR. (We can hopefully reuse this for the terminology server discussion)
I agree with @joostholslag on all points, especially the unclear and differing semantics. In Norwegian, there’s an additional category “formiddag” (literally “pre-noon”), approximately 09:00-12:00.
I suggest we leave any details out of the specs, but perhaps mention that it’s an area of unclear semantics and cultural differences, and should be defined for each localisation.
It feel right to adopt, but reviewing fist if that covers some use cases we can propose or take from the openEHR specs, just to be sure nothing is missing. Maybe people that has experience with medication management and long term treatments could propose some use cases to double check the FHIR terminology.
This is probably a perfect candidate for the “example” valueset property we discussed some time ago. I don’t think we ever thought it could end into RM attributes but I don’t see a problem with that if we mark it as such
I don’t understand why the original Jira request was raised. There is no context other than ‘We need’.
The modelling of complex timing is not optimal in openEHR. The modellers have developed a ‘hack’ via archetypes for complex timing over an above DV_DATE_TIME, using a 'Complex timing’SLOT more and more often and nesting a combination of ‘Service direction’ or ‘Therapeutic direction’ alongside ‘Timing-daily’ and ‘Timing non-daily’ to manage most requirements.
When I first spotted the FHIR Timing datatype I have to admit being impressed. They can represent most of what we can, but in a much more straightforward way.
If you want to start to represent ‘Times of the day’, it can’t be done in isolation and should ideally address the whole timing issue so we have a coherent whole. I’d welcome a solution that replaced the complex archetype approach we have now with something more making to the FHIR approach - both for semantic clarity and to make it easier for newbies to model complex timings.
The “Times of the day” value set proposed is one of the least complex aspects of timing.
I’m not keen on managing this as part of the openEHR terminology but it is being handled in FHIR as part of their timing structure and seems a decent candidate to me.
I accept that ‘in the morning’ is very culturally nuanced, indeed in the UK it would differ between care settings but it is the sort of language which is commonly used, certainly in community prescribing/ ordering, s perhaps there is value on having it as an 'example. set of terms.
There is definitely a good case for taking another look at how we do timing, and the idea of a Timing datatype, and looking at how it is done in FHIR, but we did work very hard to cover a bunch of use cases that I’d want to ensure remain supported. One to consult widely on before we jump in?
Some explanation and an earlier version of this here.
Essentially: Timing can be specified as a list of ‘occurrences’ (events in time) or in some ‘pattern’ manner, i.e. every 3rd tuesday and so on. The Occurrence_pattern part of the model is for all that.
Thast wasn’t clear from the Jira or the original post. It was particularly concerning when RM was mentioned. So thanks for the clarification
We proposed a number of potential value sets for that data element. None were ‘universal enough’ so left for constraints in the template, as per our usual practice in that scenario.
This is where ontoserver may help - will be interesting to see if Onto could be useful to offer example value sets.
We identified patterns within a 24-hour period and one that was outside the 24 hours - intra- and extra-daily, if you like. Hence the two CLUSTER archetypes.
The FHIR model does not support sequences of activities such as reducing doses of medications or a series of post-op observations in a single INSTRUCTION - eg hourly for 4 hours, 2 hourly for 12 hours and daily for a week. In that context some requests require a combo of intra-and extra-daily timing plus the timing for each direction within the request, as the aligned frameworks found in the Service direction and Therapeutic direction archetypes.
I still don’t think the solution is ideal, but it works until we can come up with something better.
In the current openEHR Entry model, the timing attribute attribute on ACTIVITY(type DV_PARSABLE) provides for timing on each activity within an order (modified medication doses was indeed one of the reasons we did this). The FHIR Timing type would need to be mapped to that attribute in each ACTIVITY, not the INSTRUCTION as a whole.
I’m not proposing the use of the FHIR data type, although the semantics it has appear good enough for a reasonable subset of use cases. If it is indeed ‘good enough’ for all single activities (I have not done a proper analysis) then the ACTIVITY.timing field could be set to a String value that encodes Timing values. Which would also help map in and out of FHIR data streams.
For medical records, morning/noon/evening/‘timing sequence details’ are OK.
For medication management, “Before breakfast”, “after breakfast”, “before supper” and “after supper” would be clear instructions to the patient in England, while “dinnertime” depends on the north/south/social class of the patient. Don’t record using localisation at all: patients (and specialists sometimes) move between countries.
