Talk:FHIR Schedule

Background

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.

Use cases

Discussion regarding what the use cases for a Schedule data type are

High Level

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