Page Comparison

...

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 What this means however is that a schedule can only be used in the context of a study. If a study designer wanted to reuse a schedule (or events, or study arms) these would need to be copied between studies…there would be no protocol that could be associated to multiple studies.Remove into the new study. It would no longer be possible to just reference the same protocol as the original study.

Therefore, 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 from design. 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 will share this set of event definitions.

...

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 tablethrough some model collections (objects will be in separate tables):

/**
 * 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 studyBurstIdstudyBurstPrefix;
  String originEventId;
  Period offset; // positive or negative
}

The new configuration is the StudyBurst, which describes how to generate a set of automatic custom events:

class StudyBurst {
  String identifierprefix;
  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 studyBurstPrefix, 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 , 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

...