"Times of the day" vocabulary?

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.

and @yampeku said

Take a look at children of ‘Temporal periods of day (qualifier value)’ (SCTID: 272106006). Maybe can give you some pointers

SNOMED International Browser

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.

2 Likes

Timing is really non standardadazed, so anything would make things better. I’m OK on recommending/adopting the fhir valueset, would ease transformations

3 Likes

Looks good @ian.mcnicoll , is there a way to formalise that usage in the openEHR specification i.e. point to the FHIR terminology as a reference?

Paul

Next step is to propose to the SPEC group but I’d like to get more clinical modelling input first.

@siljelb @varntzen @heather.leslie @vanessap @joostholslag or others -any thoughts on this?

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)

2 Likes

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.

2 Likes

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

1 Like

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.

1 Like

I agree - ‘Times of the day’ was not about a new element in timing but really a proposed valueset for Event name in Timing - daily

It came from a JIRA request from @thomas.beale [SPECPR-341] - openEHR JIRA

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?

Here’s a UML model that more or less reverse engineers the FHIR Timing data type.

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.

The Hour_specifier part gets used by both.

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.

2 Likes

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.

2 Likes

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.