Page Comparison

...

public class SessionsOnDate {
  String userId;
  LocalDate date;
  List<SessionOnDate> sessions;
}

This is a flat grouping report that lists all sessions that have a startDate/endDate that overlaps with the date of the record (remember that a session really exists for each window in each session in a schedule), grouped by the date. In the database, this is a set of records that will be groupedsimplify the representation of a session. For this reason, the date range is low: 1-7 days only. The database SessionOnDate table would look something like this:

CREATE TABLE `SessionOnDate` (
  `appId`,
  `studyId`,
  `userId`,
  `sessionInstanceGuid`,
  `timeWindowGuid`,
  `startDate`,
  `endDate`,
  `state`,
  `label`,
  `symbol`,
  PRIMARY KEY (`studyId`, `userId`, `sessionInstanceGuid`, `date`),
  CONSTRAINT `SessionsOnDate-Study-Constraint` FOREIGN KEY (`appId`, `studyId`) REFERENCES `Substudies` (`id`, `studyId`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Here is a visual design for this feature…this is all I got on requirements at this point:

...

Study SessionsOnDate API

Finally, the records above can be returned for a set of users. This is a very large amount of information (if you are looking for one week and are showing 25 users, it’s 25x7 pages of information). This is the visual design of the report this supports:

...

The information on the left-hand side about week and study burst cannot hold for all the sessions in the row, and is not easily inferred or stored for every user, but once implemented we can think about the cost of capturing this information. I am convinced the only way this view can be assembled is by aligning each user according to date (that is, there is no query to produce this that doesn’t relate it to calendar time, nor is it useful if it’s not related to calendar time since “this week” is implicitly calendrical).

Presumably we will only persist the records we need for this view, and then we can return all records in the paged API. I think one record in this API must be equal to one participant, and it will contain nested information to draw one or more of these rows.

DateAdherenceReport

Here’s one possible report structure for the above (all the sessions and session windows are squished into one day of information, and all the relative information is dropped because that dashboard is about now—it’s date-based). The above dashboard shows seven of these reports for each user, one per day—this is too much so we need another level of summation where we create a weeklong report for each user.

I do not yet understand how we show multiple sessions in the above report…side-by-side icons of different shapes? One row per kind of session? That’ll change this report.

This report can be calculated from the EventDay report.

...

...

since “this week” is implicitly calendrical and this chart makes no sense if we’re not looking at a specific point in time, since each user is at their own point in the study).

I am not sure how this view reduces the information over making N requests to the view for a single user. Still thinking about this.

Protocol adherence and notifications

...