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.