Overview
We are currently using the Participant Report API to store information about Participants that are not time-series data. Since the data doesn’t have a date associated with it, we are using the dummy date of 2000-12-31. For example, Demographics and Engagement \survey results in mPower 2.0 are stored this way.
Scenarios
Passing Information to the Workers. mPower 2.0 uses the Engagement report to configure SMS notifications.
Save Participant State Outside of the App. The app saves the participant’s responses to Demographics, Engagement, Background, Tasks, etc. This can be used to, for example, drive UI changes or show the participant’s previous responses. Storing this information on the server means it persists when the participant reinstalls the app or changes phones.
Design
API
Method | URL | Description | Permissions |
|---|---|---|---|
GET | /v4/users/self/configsdata | List the identifiers of all reports saved for the user. | self |
GET | /v4/users/self/configsdata/{identifier} | Read a participant config with the given identifier | self |
POST | /v4/users/self/configsdata/{identifier} | Save (create or update) a participant config with the given identifier | self |
DELETE | /v4/users/self/configsdata/{identifier} | Delete a participant config with the given identifier | self |
GET | /v1/apps/{appId}/participants/{userId}/configsdata | List the identifiers of all reports saved for the participant | admin, worker |
DELETE | /v1/apps/{appId}/participants/{userId}/configsdata | Delete all reports for the given participant | admin |
GET | /v1/apps/{appId}/participants/{usedId}/configsdata/{identifier} | Read a config for the given participant and config identifier | admin, worker |
POST | /v1/apps/{appId}/participants/{usedId}/configsdata/{identifier} | Save a config for the given participant and config identifier | admin, worker |
DELETE | /v1/apps/{appId}/participants/{usedId}/configsdata/{identifier} | Delete a config for the given participant and config identifier | admin |
DynamoDB
We want to create a new class called DynamoParticipantConfig DynamoParticipantData with the following attributes:
...
See for example https://github.com/Sage-Bionetworks/BridgeServer2/blob/develop/src/main/java/org/sagebionetworks/bridge/dynamodb/DynamoReportDataDao.java and https://github.com/Sage-Bionetworks/BridgeServer2/blob/develop/src/main/java/org/sagebionetworks/bridge/dynamodb/DynamoReportData.java
Open Questions
Do we want to add study IDs to participant configs and create an index, similar to Report Index?
...