Cskyleryoung
commented
9 months ago Thanks @mrshll1001, this looks good. I'll add that, long term, we should look at redesigning the "schedule" object so that we can normalize the plain text descriptions across multiple schedules. That said, an additional field of "schedule.group" may be an elegant way to group them up without requiring a major version change at this early date. Descriptions will be duplicated, but so be it.
I'll also note that I like "schedule.group" better than using attributes, because attributes don't have a label field, and therefore it can be difficult to parse their context when there is more than one related to any given record.
dan-odsc
Stemming from: https://forum.openreferral.org/t/challenges-with-the-schedule-table-for-organizations-in-the-usa/429
@Cskyleryoung and I had a discussion about this yesterday and came up with a need to group schedule objects in some way.
The motivation for this is that in cases where data input is a single lump of plaintext but also contains details of multiple schedules then it is difficult or impossible to parse out. This creates issues when multiple schedule objects are created to represent the different schedules because it is impossible to tell which ones "belong together".
For example if Service A operates a regular schedule and a holiday schedule. The regular schedule is Mon-Thurs 0900-1730 and Fri 1000-1400 while the holiday schedule is Mon-Thurs 1000-1300 and Fri 1200-1400. There would be four schedule objects created with the appropriate RRULEs, but the description would be carried across all four. Therefore it's impossible to tell which Mon-Thurs schedule goes with which Fri schedule as they aren't labelled.
There are multiple ways we can tackle modelling this in the standard, from adding a simple grouping label field in the Schedule object or adding new objects which provide the grouping. We could even redesign the Schedule object but that would have MAJOR version implications.
@Cskyleryoung please add anything I've missed!