|
|
| Line 1: |
Line 1: |
| | {{FHIR Discussion Page}} | | {{FHIR Discussion Page}} |
| − | [[Category:Active FHIR Discussion]] | + | <!--[[Category:Active FHIR Discussion]]--> |
| | | | |
| − | = Background =
| + | The Schedule type has been updated and included in the official spec |
| − | | |
| − | 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:
| |
| − | <nowiki>
| |
| − | <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></nowiki>
| |
| − | | |
| − | | |
| − | * 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
| |
