Page Comparison

...

class Study {
  List<CustomEvent> customEvents;
  List<AutoCustomEvent> automaticCustomEvents;
}

Custom events and automatic custom events will function identically to their App model counter-parts. For study-scoped events, but they will be configured with some additional information, through some model collections (objects will be in separate tablesreferenced for validation rather than the app-scoped custom events and automatic custom events (which are being replaced with study bursts, see below):

/**
 * This is the same event as in the App map, but with a display label.
 */
class CustomEvent {
  String identifier;
  ActivityEventUpdateType updateType;
}

/**
 * Almost identical to automatic custom events in the App, but with a label
 * and a means of finding all the automatic custom events that are generated
 * from a study burst configuration.
 */
class AutomaticCustomEvent {
  String identifier;
  String studyBurstPrefix;
  String originEventId;
  Period offset; // positive or negative
}

The new configuration is the StudyBurst, which must go into the Schedule2 object. which describes how to generate a set of automatic custom events:

class Schedule2 {
  List<StudyBurst> studyBursts;
}

Schedules will take a new array of StudyBurst objects which will be used to validate submitted events and to trigger schedules:

class Schedule2 {
  List<StudyBurst> studyBursts;
}

// Session is augmented to reference one or more study bursts. A session 
// must referenced at least one event ID or study burst ID (it does not
// need to have both, but it can).
class Session {
  List<String> studyBurstIds;
}

class StudyBurst {
  String prefixidentifier;
  String originEventId;
  String int occurrences;
  Period interval; // positive or negative
}

On study create and update, the server will remove all automatic custom events with a study burst prefix, then iterate through the study burst configurations and create the automatic custom events specified by that configuration. NOTE: this will eventually involve doing this for all schedules in a study every time one schedule is saved, which is a bit of a drag. I’ll continue thinking about this.

For example, a study burst named “foo” triggered from “enrollment” four times, at When an event is published (this can be a custom event or a compound system event, like the time a session is finished), and it matches a study burst originEventId, then a sequence of events will be published based on the StudyBurst configuration. The event ID will be in the format burst:<studyBurstIdentifier>:# where the # is the occurrence number of the new event (1-based). The value will be the timestamp of the event + (the interval specified by the study burst * the occurrence number). All these events are published up-front because they are mutable. If the internal publication of these events finds that the event is already in the user’s event map, then it will not be regenerated.

...

Initially a schedule would need to reference these automatic custom events, but we can probably include a study burst reference in the Session object and expand that when generating a timeline, so that the client still works with automatic custom events, which is what it finds in the participant’s event map.

This last part is a drag for Alina until we can improve the system; I will try and do that when I add the ability to associate multiple event IDs as triggers for a given session.

Make automatic custom events mutable

...

In effect, study bursts are calculated and treated similarly to automatic custom events, but they are defined in a way that captures the intent of automatic custom events.

When a study is converted to a Timeline, each session that has one or more study bursts will determine the event identifiers of the study burst (which does not require calculation of a time), and all these event IDs will be added to the session’s startEventIds before the session is then converted into scheduled sessions that encode one starting event each.