Stream: implementers
Topic: Timing.repeat.when/timeOfDay
Grahame Grieve (Dec 05 2017 at 21:27):
GF#13385 proposes the addition of some new codes for time period in the day - specifically, probably early morning, late morning, early afternoon, late afternoon. Does anyone have any comments about this?
Yunwei Wang (Dec 06 2017 at 15:12):
"Early morning" is very vague term. Can it be more specific, such as "before 10 am" ?
Eric Haas (Dec 06 2017 at 15:55):
for patient reported dated - I think "early morning" is appropriate. my early morning ( 5 AM ) and your early morning( 9 AM) are not the same.
Yunwei Wang (Dec 06 2017 at 16:12):
That is the problem. "Early morning" causes the understanding gap between who entered the data and who read the data.
Jose Costa Teixeira (Dec 06 2017 at 16:18):
I think this is not intended to provide unambiguity of times, but to support "take this whenever your early morning is".
Jose Costa Teixeira (Dec 06 2017 at 16:19):
in some cases, forcing a "early morning = 6 am" is not needed nor good.
Jim Kreth (Dec 06 2017 at 16:21):
I could certainly use these time periods to help orchestrate notification delivery to patients. For clinical staff, we really need the concept of "shift" but amongst our many hospitals shift definitions are inconsistent and they apply differently to different job roles.
Lloyd McKenzie (Dec 06 2017 at 17:56):
The existing terms of morning, afternoon, evening and night are already equally vague. Institutions might choose to assign specific time-ranges to them, but the reality is an order will often be "Take this in the morning" which for some people might mean 4am and others might be 11:30am.
Grahame Grieve (Dec 06 2017 at 20:37):
I think the point of this is to be vague
Richard Townley-O'Neill (Dec 07 2017 at 00:29):
It seems like time of day with a granularity of about 3 hours. Maybe "early evening", "late evening" would be useful.
Should provide distinct terms for "shortly after midnight" and "shortly after dawn", as both could be called "early morning".
Danielle Friend (May 31 2018 at 23:33):
I just submitted GF#17283 to a similar effect. How do you capture "before exercise", "before sex", "before travel", etc. I'd like to see the binding loosened.. what do you all think of making it an extensible binding? It seems hard to define all possible ambiguous times..
Grahame Grieve (May 31 2018 at 23:36):
background: the intent of this is to capture fairly predictable times, such as meals etc, so that a system can prompt a user to take a medication. We've said, in the past, when we talk about this, that prompts to take a medication before or after some event that does not repeat regularly are not in scope for this. For instance, I believe that I remember that we have rejected before/after exercise and coitus before
Grahame Grieve (May 31 2018 at 23:36):
of course, that leaves absent how to actually represent these things
Eric Haas (Jun 01 2018 at 00:29):
That leaves you with 1) observation (specifically component code for observation or code precoordination. in OMH they essentially created code sets ('temporal-relationship-to-{category]' schemas) which I am mapping to component.observation as a code value pair.
Lloyd McKenzie (Jun 01 2018 at 00:54):
There's a separate element in MedicationRequest that lets you capture the "before x" as a trigger. (Event-based triggers aren't the same as "timings")
Danielle Friend (Jun 01 2018 at 14:13):
@Lloyd McKenzie which element are you referring to?
Lloyd McKenzie (Jun 01 2018 at 14:55):
I believe the guidance is to use dosage.asNeededCodeableConcept or dosage.patientInstruction. @Melva Peters @John Hatem
Melva Peters (Jun 04 2018 at 19:41):
There is the asNeeded choice in the Dosage type that is intended to be used with the timing to convey "Take 1 tablet three times daily "AS NEEDED FOR PAIN" or "AS NEEDED". Pharmacy is looking at updates to the Dosage type to be able to say "TAKE/ADMINISTER "X" "WHEN THE BLOOD GLUCOSE IS Y"".
Melva Peters (Jun 04 2018 at 19:41):
The patientInstruction is intended to be patient friendly instructions on how to take the medication.
Cooper Thompson (Oct 12 2021 at 20:02):
Grahame Grieve said:
of course, that leaves absent how to actually represent these things
We are still running into issues with not being able to represent timings relative to events. This applies to both medications, but also procedures. We have the structure @Danielle Friend mentioned where you can order things to be done relative to an event. E.g. "before lunch" "after exercise". Mapping all of this info into "PRN" seems less than ideal. Are we the only folks that run into this?
At the very least, the required binding for Timing.repeat.when seems like it needs to be loosened. The valueset provided seems more like an Example value set than something that would be required. Given that the vote for FHIR#17283 was just 2-0-0, can we re-open that and revisit the resolution?
Grahame Grieve (Oct 12 2021 at 21:53):
well, you can, but I doubt that will change the resolution. The list of things Timing.repeat.when are appropriate for a regular every day events. Every time we look at 'timings relevant to events' we come to identifying specific events that the timing is relative to, and we will always say, 'that doesn't fit into the Timing data type'. What kind of event? What specific event, and how is it identified? And what if you start a course of medication, taken 10 minutes before meals, after a specific event? No, Timing.repeat.when is for repeating timings.
Maybe you want to propose a startingCondition and endingCondition as fields of Timing, that take an expression? That might orientate to the actual requirements
Grahame Grieve (Oct 12 2021 at 21:53):
at least aa provided.
Lloyd McKenzie (Oct 13 2021 at 02:36):
Dosage.asNeededCodeableConcept is intended to be used for things like "before exercise". There's already a Timing.event code for "before lunch".
Jean Duteau (Oct 13 2021 at 04:27):
Umm, I’m sorry but I don’t think that you should re-open it without a vote from the WG. I think that there is a process to follow.
Grahame Grieve (Oct 13 2021 at 05:43):
umm that's what I assumed - that we'd follow the process to reopen it
Cooper Thompson (Oct 13 2021 at 13:32):
Sorry - I didn't realize the button was overriding the vote. My bad from a Jira process perspective. I attempted to clean up the Jira status.
Cooper Thompson (Oct 13 2021 at 13:32):
Do we really think the value set in http://hl7.org/fhir/valueset-event-timing.html is complete enough to be a required binding?
Grahame Grieve (Oct 13 2021 at 19:49):
yes. It has stood for many years, with use in CDA as well. That doesn't mean that we won't consider enhancements
Cooper Thompson (Oct 15 2021 at 17:12):
Ah yeah, looks like we have been sending free text in our CDAs since we couldn't make it fit into the CDA value set. So we ran into the same problem there too.
Grahame Grieve (Oct 15 2021 at 19:46):
ok. that's very useful information. do you have any way to list the free texts you've been sending?
Last updated: Apr 12 2022 at 19:14 UTC
