...
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.
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
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.
...
Remove the following APIs:
...