Stream: implementers
Topic: Timing Offset
Grahame Grieve (Mar 23 2016 at 08:02):
Task 8697 proposes to add offset and offsetUnit to Timing.repeat. but I do not know why offset would be in anything other than minutes. Adding offset units seems overkill to me. Why don't I just add offset and document that it's in minutes....
Grahame Grieve (Mar 23 2016 at 08:04):
further, the proposed definition of the element: "If negative, indicates that the activity should occur this amount of time prior to the occurrence of the event specified by repeat.when. If positive, indicates that the activity should occur this amount of time after the occurrence of the event specified by repeat.when" - is problematic; the when includes codes for 'before' and 'after' - should we drop the before and after codes? or make yet another constraint that you can't say -10 minutes after breakfast?
Grahame Grieve (Mar 23 2016 at 08:05):
moved by @Michelle (Moseman) Miller and Michael? (Epic?) - Maybe Michelle can comment...?
Michelle (Moseman) Miller (Mar 23 2016 at 22:49):
Grahame, you bring up some valid points.... The best I can recall is that offset units could be needed in the future if other values were ever added to the Timing.repeat.when value set, such as to represent a use case like "5 days after surgery". However, offset is currently tied to Timing.repeat.when and all of the codes are daily occurrences (e.g. eating, sleeping) more so than events (e.g. surgery, cast removal) so minutes could be assumed for the time being.... Same reasoning on the second question of why the positive/negative support is needed. If, in the future, the Timing.repeat.when value set is expanded to include a generic event (e.g. surgery, cast removal), then we'd need the positive/negative if the value set didn't include the corresponding before/after codes.
Grahame Grieve (Mar 23 2016 at 22:50):
ok. so right now, I'll add offset as minutes, and positive only. The direction indicated by the code. We'll re-assess if we need to after implementation experience
Grahame Grieve (Mar 23 2016 at 23:32):
more on this task. BID, 30 mins before meal, starting tomorrow for next 10 days. The starting tommorow for next 10 days - can't be done.
Grahame Grieve (Mar 23 2016 at 23:34):
it's also quite opaque to me whether the code is understood to stand for the entire TIming, or to introduce a base from which the timing builds.
Grahame Grieve (Mar 23 2016 at 23:34):
for me, it was always the former. I'm going to update the definitions to say that explicitly
Michelle (Moseman) Miller (Mar 24 2016 at 18:59):
1) I don't agree with the new comment saying that the code represents the entire Timing structure.... Examples like you gave of "BID for 14 days" break that rule, such that BID doesn't convey the boundsDuration of 14 days. It might be better to scope the "code" as an alternative for frequency* and period* elements only
2) Regarding the "starting tomorrow for 10 days" example, it could be represented via a combination of effective (start) date on the order/statement, itself, and timing to convey the 14 days. Ignoring the possible duplication of dates across timing and other resources, we do support knowing both boundsDuration and boundsPeriod, such that it would be nice to support both.
Grahame Grieve (Mar 24 2016 at 19:03):
Scoping the code down to just frequency and period nobbles it though. But you wouldn't have codes the included bounds - so maybe exempt bounds from that?
Grahame Grieve (Mar 24 2016 at 19:04):
i don't know how you would use both period and bounds..
Michelle (Moseman) Miller (Mar 24 2016 at 20:29):
boundsDuration = boundsPeriod.end - boundsPeriod.start when both start and end are known
Otherwise, it is what you mentioned earlier -- "starting tomorrow for 14 days" which is a boundsDuration = 14 days and boundsPeriod.start = tomorrow.
It could be possible to have a code = BID and when = before meals....so I would want to "exempt" bounds and when. Count is another possible exemption if it was ordered as code = BID and count = 28 (implies a duration of 14 days).
Grahame Grieve (Mar 24 2016 at 23:12):
Exempting when from code is exactly what I don't want to do because it is the most complicated.
Grahame Grieve (Mar 24 2016 at 23:13):
The idea of code is to allow institutions to manage timing by a look up table
Grahame Grieve (Mar 24 2016 at 23:13):
as for bounds, if you have start as a real date, and duration, you can turn that into a real end. What does allowing you to mix them and contain internal disagreements buy?
Michelle (Moseman) Miller (Mar 25 2016 at 03:15):
If we don't exempt when from code, then are you suggesting the code would be "BID before meals" (which is actually what we have in our system)? The only thing that makes me pause is whether a code = "BID before meals" meets the code definition of being "ubiquitous" especially since it isn't even defined in the preferred value set.
Regarding the boundsDuration and boundsPeriod, you are correct that they *should be* conveying consistent information, especially if systems do the calculation you mentioned. I don't have a strong opinion or reason to support both -- other than just simply stating that our system has the ability to calculate, persist, and return both. That said, it makes writes/updates more complex if we have to check for disagreements between the two.
Last updated: Apr 12 2022 at 19:14 UTC
