Page Comparison

...

CREATE TABLE `WeeklyAdherenceReports` (
  `appId` varchar(255) NOT NULL,
  `studyId` varchar(255) NOT NULL,
  `userId` varchar(255) NOT NULL,
  `createdOn` bigint(20) unsigned NOT NULL,
  `labels` text NOT NULL,
  `weeklyAdherencePercent` int(3) unsigned NOT NULL,
  `json` mediumtext NOT NULL,
  PRIMARY KEY (`appId`, `studyId`, `userId`),
  CONSTRAINT `WeeklyAdherenceReports-Study-Constraint` 
      FOREIGN KEY (`studyId`, `appId`) 
      REFERENCES `Substudies` (`id`, `studyId`) ON DELETE CASCADE,
  CONSTRAINT `WeeklyAdherenceReports-Account-Constraint` 
      FOREIGN KEY (`userId`) 
      REFERENCES `Accounts` (`id`) ON DELETE CASCADE,
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

The “labels” column will pull out the labels from the JSON into a pipe-delimited string, to enable searching for records that match the label (this is a design requirement) in the study-scoped API.

Weekly Adherence Reports for Study

The weekly adherence API for a user will persist the report

[TODO]

Protocol adherence and notifications

There is definitely a lot of possible ways we could measure adherence and I have some questions I have asked above about this. We can probably be pretty flexible on this since at some point, we have to load the whole state of the user’s participation to generate this report. We could then set a threshold for this (ie. warn administrators if there are any non-compliant assessments, vs. setting a proportion threshold that would need to be hit before notifying administrators). This warning apparently applies to specific participants, so it would be generated as part of the worker process described above. Another API will allow an admin to retrieve all these records using a paging API that is similar to the study participants search API. Those search criteria will be used to retrieve the page of user IDs, and then those will be used to retrieve and sort the appropriate set of adherence reports. If the adherence report hasn’t been requested for a specific user, it will come back empty. (A worker process will be created to run through users nightly and regenerate these reports, but the weekly adherence report API will accomplish the same refresh for one user).

All the same arguments should exist as the /v5/studies/{studyId}/participants/search API. In addition, it should be possible to filter and or sort on the following fields:

• The adherence percentage;

• The label of individual windows (through a like query on the labels column).

Protocol adherence and notifications

Since all the reports give an adherence percentage, we can use this to sort records by adherence in the weekly view, or to generate a message to administrators as part of the worker process that will be run nightly to update these. Any necessary configuration for this can be added to the Study model.

A worker process would go through all apps nightly, looking for apps with studies that have schedules, and then for each of these studies, it would iterate through all participants in the study, calling the weekly adherence API endpoint for that participant to generate and cache their adherence report. It can also generate messages, if need be.

Messaging APIs

One UI design I have seen shows a list of notifications in an administrative UI, indicating specific participants that are out-of-adherence with the study protocol. This hints at a very large amount of functionality.

...