Bridge Server Policies

To request data deletion for an app, a Jira should be filed and assigned to the PM of the Bridge team. This Jira should unambiguously specify which app needs to be deleted (either by name or by ID). This Jira should also specify if only Bridge data needs to be deleted or if Synapse data also needs to be deleted. (Note: Only Synapse data exported by Bridge itself will be deleted by this process. Any data generated by teams and orgs outside of the Bridge team is not covered by this process.)

Direct approval from the Chief Technology Officer must be obtained to delete data associated with any externally-supported Sage project.  The Director will coordinate with the Sage President and other Leadership Team members to ensure Sage's responsibilities for deleting app data are understood by the company.

Bridge server engineers may independently delete server data associated with apps that are generated by the engineering team for testing purposes only.

We also recommend that the primary investigator or someone from their organization alert all users of the app that the app will no longer be supported (unless the app works without getting back activities and surveys from the server). One of Sage's PMs should coordinate this.

Engineering Process

Note: This process only covers deleting entire apps. If you need to delete only one study within a multi-study app, this will require a new process to be developed.

The following instructions detail how to destroy all the server data and users that were created as part of an app.

1. In the Bridge Study Manager, set the minimum supported app version for the study on each platform. Set this to a higher-than-released version number for each platform. A very high number such as 9999 is ideal. If you do this as far in advance of deleting the study as possible, users should get some idea that the app will go away, but note that right now, we have no way to message why the user is being locked out. This may need to be combined with other forms of messaging.  This step will ensure there is a long lag time (ideally at least a week) between when the server becomes inactive and when the study and associated user data is permanently deleted.
   
   Please note that the next steps are permanent and cannot be undone, not even with backups. To do this you must have administrative access to the Bridge server.
   
   
2. In the Bridge Study Manager, delete all surveys (make sure to use the drop down to select Delete Permanently) and all participants.
3. Go to each org and delete all accounts in each org (except your own). No need to delete the orgs themselves, since deleting the app wll automatically take care of this.
4. Under Server Config → Export Settings, note the Synapse Project ID and Synapse Access Team ID for both v2 and v3. Similarly, for each study in the app, note the Synapse Project ID and Synapse Access Team IDs under Export.
5. If requested, these projects and teams should be deleted from Synapse.
6. Under Sage Admin → Apps, select the app to delete and use the drop down on the upper right to Delete Permanently.

Not Yet Implemented

The following are not yet implemented:

• Automatically deleting surveys when the App is deleted.
• Automatically deleting Participant Versions and Demographics from Bridge database.

Limitations

• Doesn't delete OAuth access grants (such as FitBit access).
• Fails to remove some Report Indices (but the reports themselves are deleted).
• Doesn't delete SMS from the SMS log.
• Does not delete the upload encryption/decryption keys.
• Does not delete Upload Dedupe metadata (contains no data or identifiers, only which uploads are duplicates of others, keyed by health code, timestamp, and MD5 hash).
• Does not delete cached metadata (etags, expiration timetamps, urls, lists of other cache keys; no health data or identifying info, but some cache keys that include app version, OS, and languages).
• Consent Docs sent via SMS will not be deleted from S3.
• Some cache keys (for example, Intent To Participate, which includes emails and phone numbers) may persist in the cache for up to 4 hours.