Study-scoped events

Moving app-scoped custom activity events to studies raises a number of issues that should be addressed in the move.

First and foremost, schedules are global in scope along with studies, so if a study defines a set of events, the schedule may or may not be valid since it could reference events from another study.

The long-term plan had been for studies to be associated to protocols, which would have referenced one or more study arms and schedules which could be associated to those study arms. If we eliminate the protocol from the domain design, the study becomes the primary object for this purpose. Schedules would need to be copied between studies…there would be no protocol that could be associated to multiple studies.

Second, the existing system supports study burst designs, but only indirectly through automatic custom events. These events themselves represent time sequences that are not directly represented in the model.

To address these issues, I propose the following changes.

Scope schedules 1:1 with studies in our API.

Remove the following APIs:

GET /v5/schedules
POST /v5/schedules
GET /v5/schedules/{guid}
GET /v5/schedules/{guid}/timeline
POST /v5/schedules/{guid}
POST /v5/schedules/{guid}/publish
DELETE /v5/schedules/{guid}

Add the following APIs (to be phased out with the introduction of later APIs to support multi-arm studies with multiple schedules):

GET /v5/studies/{studyId}/schedule - will create a starter record if it doesn't exist
POST /v5/studies/{studyId}/schedule - will create the record if it doesn't exist
GET /v5/studies/{studyId}/timeline - transitional

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;

}

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):

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