Of all the data types, Schedule is the most controversial and least well established. There's open questions about whether it should be a data type at all, and how complex it should be.
Discussion regarding what the use cases for a Schedule data type are
The schedule data type is intended to cover the following things:
- suggested treatment regimes
- prescription schedules ??
The schedule data type is not intended to cover:
- clinical trial scheduling
Proposed Alternate Models
In the past, I have both read implementation manuals using GTS and actually implemented GTS in a medication system. It turns out that most actual implementations constrain GTS for a set of specific usecases: "How to specify a daily schedule?" "How to determine on which days to administer?" "How to specify a pause?". To avoid the complexity of GTS, but be a tad more powerful that Grahame's originally proposed schema, I propose some changes to Schedule. Some are simplifications others are additions. Let's start with the end result, the rationale is below:
<x xmlns="http://hl7.org/fhir"> <event><!-- 0..* dateTime When the event occurs --></event> <repeat> <!-- Only if there are no events above --> <frequency><!-- 0..1 integer daily frequency --></frequency> <time> <!-- 0..* specific moment(s) within day when event occurs --> <when><!-- 0..1 code | dateTime Specific time or common life event --></when> <offset><!—0..1 Duration offset from the life event</offset> </time> <days> <day><!-- 0..* code a specific weekday --></day> <pick><!-- 0..1 Ratio which days per period to pick --></frequency> <pause><!-- 0..1 Duration time to wait before repeating the day pattern--></count> </days> <count><!-- 0..1 integer number of times to repeat --></count> <end><!-- 0..1 dateTime | Duration when to stop repeats --></end> </repeat> </x>
- Move out “duration” as in “duration” of a single event. Either completely (duration is specified somewhere else, maybe dependent on flowrates etc.) or out of the repeat: events are supposed to be equally long within one schedule. We can however extend the “end” element to determine the total duration of the Schedule.
- Make the schedule a choice: you either specify a set of specific moments OR you use repeat.
- Limit frequency to specify the frequency per 24 hours. Frequency could be expanded by a Ratio to use a period like “1x per 3h”, but this might add unneccesary complexity.
- Group attributes concerning life events and offset in a group (“time”), so its obvious they work together and can be repeated to specify multiple moments per day. Add the possibility to specify an exact time instead of a life event.
Those are the small tweaks. Now, this is enough to specify a daily repeating schema. If you wanted something more complex, like “once every 2 days” or “on Wednesday”, we need additional elements to specify on which days the schedule needs to run:
- So, add an optional group of elements “days”. These will determine on which days the timed events specifed above will be active.
- Add an element “day”, which are 0 or more exact weekdays (mon, tue, fri, etc.).
- Add an element “pick” which is a Ratio an can be used for a number of scenario’s:
- Once per week: “1d per 7d”
- Every other day: “1d per 2d”
- Twenty consecutive days: “20d per 20d”. This is only useful when combined with an extra element “pause”, to specify pill schema’s “20d in a row and then a week of pause”.
Notice how all these elements specify relative moments. The “event” attribute could be used as an alternative to specify exact date/times, or a starting moment for the relative schedule.
Furthermore, it should be clear whether “count” limits the number of repeats or the actual number of occurrences.
- LM: Add 5-6 examples.
- LM: "event" isn't an intuitive name, "pick" I don't really understand, "pause" being nested inside "days" is sort of weird. Having "end" and not "start" seems odd.
- LM: Having "event" serve dual purposes seems bad. EK: agree. Only reason is that I don't want a huge list of elements. LM: Well, you can use interval for start/end.
- LM: Have <start> (of schedule) OR <occurrence> (list of specific times). You can even do "once on jan 1, 15 minutes before lunch": start = Jan 1. Repeat once. 15 minutes before lunch. Just need to add a comment to "repeat" to note that "repeat once" is legitimate.
- JD: Scheduling for specific days (the <days> element) is out of the 80%.
- JD: how would we do "every 4-6 hours" with Schedule? I think that frequency needs to be Interval(integer)? LM: agree
- LM: One thing we *don't* have in schedule is something that's common in most systems - coded schedule. QD, PID, HS, etc. JD: isn't that Schedule.repeat.when? EventTiming looks like it has HS and could have QD and BID LM: BID is a frequency, not an event JD: understood, but HS is normally used in the same place as BID. In a drop-down of frequency codes, you'll see HS, QAM, QPM, etc. LM: Which is why I think "schedule" needs a "code" element that is also exclusive. So you have one of 3 things: 1. list of date/times 2. code (defining a spec) 3. simple timing spec