Overview

Components:

• BridgePF requestUserData API
• User Data Request Queue
• Bridge User Data Download Service
• Email with Download Link

The user (participant) will call the requestUserData API The Bridge User Data Download (BUDD) Service is the name of a stack that includes the following pieces:

• A way for the user to request user data.
• An asynchronous BUDD Daemon, which processes the request and gathers health data from AWS.
• A way for the user to get their data back from the BUDD Daemon.

Specifics in the following sections.

Requesting User Data

Alternative #1: BridgePF API and SQS Queue

The user calls the requestUserData API, which lives in BridgePF. The user will pass in a start date and end date (we can limit the time range to something like a week to make sure they don't brown out our system; also they can use this to get incremental updates of their data). BridgePF will write then write the start and end date, along with health code , and email address, start date, and end date to an entry to the User Data Request Queue SQS queue and return OK to the user. If necessary, we can put a max delta on the start date and end date. Advantages: BridgePF is still the

The SQS queue will contain entries representing a request for health data, containing health code, email address, start date, and end date. These entries will be consumed by the BUDD Daemon.

Pros:

• We only have one front-end for all user interaction (BridgePF).
• Apps can integrate with this API without having to configure an entirely separate

...

• end point.

The User Data Request Queue is a backed by SQS. Queue entries contain health code, email address, start date, and end date. (NOTE: It's probably a bad idea to have health code and email address live in the same place, even if only temporarily, as this means someone only needs to break into our AWS account to potentially get identified user health data. One alternative is to put just the email address in the SQS queue and have the Bridge User Data Download Service query Stormpath, but that still leaves us with personal identifying info in SQS.)

...

• Much cheaper to build compared to a web portal.

Cons:

• Potential security risk from having both email address and health code in SQS, even if only temporarily. (Even just the email address may be a security risk.)

Alternative #2: Web Portal

Users log into a web portal using their Bridge credentials and submit a user data request through the web portal. This request will include the start date and end date. (Again, we can limit the time range.) The BUDD Daemon is an asynchronous process on the same host that handles this request.

Pros:

• If we're building a web portal for returning user data, might as well use the same web portal for requesting it too.
• Security is simpler, since everything lives in a single system that's protected by the user's Bridge credentials.

Cons:

• More expensive compared to building a BridgePF API and an SQS queue.
• Users need to get their Bridge credentials from the apps, which may or may not be easy.

Recommendation

Building a web portal is significantly more expensive than building a BridgePF API and an SQS queue. However, the security concerns for not having email address and health code (or even just email address) living in SQS while "in transit" potentially more than justifies the cost.

Recommendation: Web Portal

BUDD Daemon

The BUDD Daemon is either a process running in EC2 that consumes an SQS queue or a process running in the web portal, depending on other design decisions. (TBD What framework? How is this deployed?) This process will poll the User Data Request Queue for The BUDD Daemon processes user data requests . It then queries by querying the HealthDataRecord and HealthDataAttachment DDB tables and the attachments S3 bucket to pull the raw health data records, bundles , bundling them up, and uploads uploading them to S3. The service then sends an email to the user with a link to download their health data.The Email with Download Link is an email with an

Returning User Data

Alternative #1: Email with S3 Pre-signed URL

The BUDD Daemon generates an S3 pre-signed URL that points to the user's health datarequested data, and emails it to that user. For security, the pre-signed URL will expire expires after 24 hours.

Pros:

• Much cheaper compared to building a web portal.

Cons:

• If the email is intercepted, somebody could use the S3 link to get the user's data.
• If the link expires, the user

...

• either needs

...

• to

...

• request their data again (starting the whole process over again), or we need a way to create a new S3 pre-signed URL

...

• from an existing user data request (which increases complexity and cost of this solution).

Alternative #2: Web Portal

The BUDD Daemon notifies the user view email that their data is available on the web portal. The user logs onto the web portal, and go to their completed request. The web portal generates an S3 pre-signed URL, which the user can click to download. For security, the pre-signed URL expires after 5 minutes (we can tweak this up or down depending on security concerns vs user convenience). If the user needs to download their data again, they can log in again and go to the completed request, and the web portal will generate a new S3 pre-signed URL and sends a new Email with Download Link. Advantages: Users can download their data on a system other than their phone. We don't need to build a web UI for users to download their data.

Alternative Designs

Bridge User Data Download as a Web Portal

Advantages:

• fewer moving parts, since everything is encapsulated in a single service
• security is simpler, since the user must provide their credentials to access Bridge User Data Download

Disadvantages:

...

.

Pros:

• If we're building a web portal for requesting user data, might as well use the same web portal for returning it too.
• Better security around the S3 link, since it's not sent out externally, and the expiry time can be much shorter.
• Better story for the user generating a new S3 link after the old one expires.

Cons:

• More expensive compared to building a BridgePF API and an SQS queue.
• Users need to get their Bridge credentials from the apps, which may or may not be easy.

Recommendation

Again, building a web portal is significantly more expensive than just sending out an email. But the web portal has a much better story for security and for generating a new link after the old one expires. Plus, if we're already building a web portal for requesting user data, we might as well use it for returning it too.

Recommendation: Web Portal