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 the following changes to Schedule:

• 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:

o Once per week: “1d per 7d” o Every other day: “1d per 2d” o 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.

<x xmlns="http://hl7.org/fhir">

<event></event>

<repeat>      
  <frequency></frequency>
   
    <when></when>
    <offset><!—0..1 Duration offset from the life event</offset>
  
 
  <days> 
     <day></day>
     <pick></frequency>
     <pause></count>
  </days>

  <count></count>
  <end></end>
</repeat>

</x>