...
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.
System Messaging APIs
UI designs show 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. Because “notifications” is heavily overloaded for Bridge, I will call these “system messages.”
We have had requirements to message both participants and study administrators over the years. For example, very early on we embedded a blog in an app for this purpose. Then we implemented support for remote push notifications and topics (rarely used). Instead in recent studies we have tried using local notifications based on scheduling information. Now we are talking about showing notifications to administrators about participants being out-of-adherence in an administrative UI. Because “notifications” is heavily overloaded for Bridge, I will call these “system messages.”
I would like to add a simple but complete messaging Ωmessaging system to Bridge which could be used to persist, deliver, and record the consumption of messages. Features would include:
API would be push-pull (write a message, request a list of active messages for a recipient; push-push via something like SMS or email is a lot more complicated);
recipients Recipients could include individuals or organizations (and other groups once we have them);each them…probably multiplexing the message to organization members, unless we need something more stringent);
Each recipient could mark the message as “read” to remove hide it from their UIs, separate from others, or “resolved” to remove hide it for everyone. They would not be deleted so they are auditable. We should record who deleted or resolved the message;
Messages could be assigned (change recipients), and indicate a status like “busy” along with the user currently working on the message. Now you have a very simple way to hand off work between team members.
Once pull messaging is working, we could support “push” messaging (where we send a message via email or SMS, or possibly through remote or local push notifications). This introduced a lot of additional complexity, however:
It needs to be integrated with Amazon’s messaging APIs, where we are recording “sent” status. The advantage is that we’d have a record of such messaging, which is part of the study protocol and something that we’ve put together one-off solutions for in the past for scientists;
We’d want to implement messaging preferences, per user/organization and possibly by message typewould have a type and messages could be filtered on the type. Messages could include types like “out of adherence,” “joined the study,” “completed the study,” etc.
This should meet the basics needs of our recent UI designs.