...
API would be pub-sub and pull-based (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 should include individuals only, opt-in, to start;
Each recipient could mark the message as “read” to hide it from their UIs, or “resolved” to hide it for everyone. They would not be deleted so they are auditable. We should record who deleted or resolved the message;
Messages would have a type (“out of adherence,” “study joined,” “study completed”, etc.) and messages could be filtered on the type . Messages could include types like “out of adherence,” “joined the study,” “completed the study,” etcand/or study;
These should be app-scoped because it would be very annoying to have to go into every study to see what needed attention in that study.
This should meet the basics needs of our recent UI designs.
Method | Path | Description |
|---|---|---|
GET | /v1/messages | Get the messages (paged and filterable by type and whether message has been read) for the caller. |
POST | /v1/messages | Publish a message to all subscribers. |
DELETE | /v1/messages/{guid} | Mark a message as read or resolved (if resolved=true) |
GET | /v1/messages/subscriptions | Get the studies and types of messages you are subscribed to |
POST | /v1/messages/subscriptions/{studyId}/{type} | Subscribe to receive messages of a specific type in a specific study. |
DELETE | /v1/messages/subscriptions/{studyId}/{type} | Unsubscribe from receiving messages of a given type in a given study. |