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 Director of Technology Services 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 study app data are understood by the company.

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

Engineering Process

The following instructions detail how to destroy a study and all the data and users that were created as part of this study.

First, we recommend that you alert users of the application that the application We also recommend that the primary investigator or someone from their organization to alert all users of the app that the app will no longer supported (unless it will the app work 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

...

1. 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 in far 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

...

1. the next

...

1. steps are permanent and cannot be undone, not even with backups. To do this you must have

...

1. administrative access to the Bridge server.
   

...

1. 
   
2. In the Bridge Study Manager, delete all

...

Once this is done, you can delete the study through the administrative Bridge API, and this will delete the study.

Finally, the Synapse project(s) that contain the exported scientific data may need to be deleted, depending on retention policies for the coded study data for a particular project (please refer to the Synapse documentation on how to do this).

...

1. surveys (make sure to use the drop down to select Delete Permanently) and all participants.
2. 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.
3. 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.
4. If requested, these projects and teams should be deleted from Synapse.
5. 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.