This wiki has undergone a migration to Confluence found Here

Talk:FHIR Schedule

From HL7Wiki
Jump to navigation Jump to search

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

Detailed

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