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?