...
To address these issues, I propose the following changes.
Scope schedules 1:1 with studies in our API
...
Remove the following APIs:
...
Schedule publication will happen only as part of changing the phase of the study. The schedule will only be deleted when the study is deleted. Now events can be defined in a study, referenced from a schedule, and we can expand to multiple arms/schedules later that share this set of event definitions.
Add events to the study object
...
Move the configuration from the App to the Study object with some improvements:
class Study {
List<CustomEvent> customEvents;
List<StudyBurst> studyBursts;List<AutoCustomEvent> automaticCustomEvents;
}
| Code Block |
|---|
class Study {
List<CustomEvent> customEvents;
List<AutoCustomEvent> automaticCustomEvents;
List<StudyBurst> studyBursts;
} |
Custom events and automatic custom events will function identically to their App model counter-parts, but they will be configured with some additional information, so am embedded object is appropriate (along with a separate table):
| Code Block | ||
|---|---|---|
| ||
/** * This is the same event as in the App map, but with a display label. */ class CustomEvent { String identifier; String label; 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 label; String studyBurstId; String originEventId; Period offset; // positive or negative } |
The new configuration is the StudyBurst, which describes how to generate a set of automatic custom events:
| Code Block |
|---|
class StudyBurst {
String identifier;
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 studyBurstId, then iterate through the study burst configurations and create the automatic custom events specified by that configuration.
For example, a study burst named “foo” triggered from “enrollment” four times, at an interval of P1W, would (in the old notation) generate the automatic custom events “foo1 → enrollment:P1W”, “foo2 → enrollment:P2W”, “foo3 → enrollment:P3W”, “foo4 → enrollment:P4W”.
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 to include the auto custom events that the client would expect to find in the participant’s event map.
Make automatic custom events mutable
Once created, it should be possible to change the timestamp associated with an automatic custom event through the existing study custom event APIs.