# Health Wallet Design/Development Plan
## Overview
Health Wallet is a semi-decentralized service for tracking, storing, and sharing healthcare data.
The target audience of users is web native, health concious people, who agree to share anonymized healthcare data with companies that use data science and machine learning on the data set.
Due to issues with bureaucracy, Health Wallet will not integrate with doctor's offices, despite the existence of laws allowing people to request their primary care provider's records to be transmitted electronically to arbitrary endpoints. These reports would be idiosyncratic to the PCP office, so writing a general purpose receiving API would be nearly impossible.
Instead, the app will request standardized data from users, similar to the forms sent out by long-term health studies. Users will voluntarily complete forms, and be compensated with a novel cryptocurrency for their submission.
When submitting these forms, the data will be stored in two places - first, on IPFS via the Ceramic protocol, and the CID will be saved to the user's device. The user will be able to use the LIT protocol to give revocable read access to this data. IPFS does not provide write or delete capabilities. The second data storage location is in an ERC1155 contract, after the backend API encrypts and tags the data. The tagging structure is described later in this document.
The novel cryptocurrency mentioned earlier will have a lot of inflationary pressure - it's free and easy to submit data. To maintain the value of that cryptocurrency, the ERC1155 submitted data will be sold to researchers - holding the ERC1155 attached to a record makes the specific data readable. The ethereum earned from these sales will be sent to a liquidity pool consisting of an ETH/COIN pair on the ETH side, providing liquidity for users submitting data.
For this app to be completely decentralized, users would need some method of storing their list of private CIDs privately and/or ideally locally. This is an uncommon feature for web apps as usually the app creator wants to store as much data as possible.
For a V1 to test PMF, we recommend storing CIDs for users.
## Web App Features
### General Framework
We recommend using NextJS hosted at Vercel with some kind of SQL database for storing CIDs.
Vercel is an ideal choice for hosting because it provides automatic cloud compute scaling of backend API transactions. The app, using health data form requests, would likely have large periods of inactivity punctuated by activity coming in from every user at once.
Vercel also provides edge serving for the static pages that NextJS produces via Serverside Rendering. This means that the web app will feel fast for users from a wide variety of geographic locations.
A SQL-like database is ideal here because there are a lot of competing services to host that database style, reducing costs. It also has a high number of experienced developers due to it's age and established popularity, and is all that is required for this app.
### Personal Health Data Side
#### User account creation
Onboarding should be easy - we should use a general web2 sign in flow (NextJS offers NextAuth which accepts a wide variety of SSO partners) and connect any web3 activity to that user via [Biconomy](https://www.biconomy.io/) | [(SDK here)](https://docs.biconomy.io/). Biconomy offers a smart wallet service that allows users to interact with the blockchain without handling their own wallet or gas.
At the time of account creation, we should also collect basic demographic data - birth date, height, gender, etc.
- Next Auth Integration
- Biconomy Integration
- Demographic Data capture
- User onboarding flow that explains how tokens are received and sold to have value
#### Home Screen - Unverified User
Prompted to capture data from user. User goes through data capture form for high-level health related question submission.
- Modal for verify indentity upon succesful submission
- Would redirect users to "Home Screen - Verified User"
#### Home Screen - Verified User
The verified home screen should give users easy access to important controls and data. It should display their current cryptocurrency value, provide a link to submit a health data form, and provide a link to a page that handles providing access to their personal healthcare data.
- Dashboard showing crypto price, amount held, total value
- Badge announcing next health submission request time
- Link to submit health data (if during health data submission event)
- Link to access sharing page
**Opportunities:**
Section called "Opportunities" that would be lower "side quest" like forms that users can fill out other questions related to their individual appearence (ie eye color, ethnicity, income etc..)
#### Data capture form - "Submit My Data"
Data capture also needs to be easy - the data should be captured during data capture event windows, perhaps 1 week out of each month, or every two months. It should be easily accessible from the home screen after logging in.
#### Access sharing page - "Share My Data"
Users should be able to add email addresses to grant access to their healthcare data to people using the indicated email account. That email account, if not already a user, needs to have a paper wallet associated with it that recieves access via LIT protocol, so that the access is ready when the shared user signs in.
Users should also be able to revoke access here, so the emails should appear in an array with a matching button to delete the email address, ie revoke access.
- Email address entry field
- API that searches for an associated user, creates user if one doesn't exist, and assigns LIT access to that user
- Display all email addresses with LIT access, delete button for removing access
#### Reviewing Shared Data - "Data Shared With Me"
Users that have been given data need a dashboard to review their data. We expect users that are given data to have access to a number of users, for example a chiropractor or folk medicine healer might have many patients.
- Display a searchable list of all users that have given access. Selecting a user reveals a list of all shared records.
- There should be a dashboard view that allows similar fields to be plotted on a time series graph.
#### Reviewing Personal Data - "Review My Data"
Users that have submitted data should be able to review it and track progress or declines and make adjustments.
- Dashboard view that allows similar fields to be plotted on time series graph (ie weight over time) with controls for restricting or expanding the time or adding/removing data tags.
### Purchasing Data (Commercial Use)
#### Commercial Use On-Boarding
We would want commercial users to submit a sign-up form to screen any unwanted access. A sign-up form with basic onboarding questions (Company Name, Location, Business Phone Number, Email Contact etc..)
* Email submission proof of incorporation might be the best way to validate commercial users
**Validate Commercial Use:**
As somepoint it would be best to hire an in-house team for both commercial & non-commercial user validation.
#### Commercial Use Purchase Data Flow
We need to have a dashboard for commercial users to purchase data sets. This dashboard would include the ability to use & operators and customize their cart.
The ability to price data sets would happen dynamically and increase based on how how specific and large your data set might become.
**Making Purchase**
After curating the correct data needed for the commercial customer they would be presented 2 fees.
* Gas Fees
* Purchase Amount
* Purchase amount would be split up two ways
* HealthWallet Income
* 15 - 30% would go to HealthWallet Token liquidity pool
**Note to VC/DAO investors**: This democratizes the benefit of the data to all users. This tokenomic control encourages participation for all users by evenly distributing revenue to all data submitters, commensurately with the specific amount of HealthWallet Coin they hold.
Due to the high frequency of ERC1155 transfers that take place during a data set purchase, we recommend running this infrastructure on an L2 such as Arbitrum or ZKSynk.
**Payment Options:**
* Fiat (Visa / Mastercard)
* Fiat would then be converted to eth via Biconomy SDK
* ETH
#### Purchased Data Dashboard
Commercial users need a method to review the data they purchased inside the app. This dashboard should operate similarly to the dashboard described in **Reviewing Personal Data - "Review My Data",** but with additional controls for displaying a third dimension to the data (# of people per Y value, given X = time).
This is the primary place that Commercial users would spend time, so it needs a lot of care and attention to UX.
Furthermore, we need to protect data submitters, so we need to put controls in the app that refuse to return data on a filtered data set lower than 1000 people... this is also statistically insignificant, so it prevents bad science from happening at the same time!~
### Tokenomics
Company (health wallet) collects and openly sells anonymized healthcare data to ML training engineers, medical researchers, or insurance underwriters.
A portion of revenue (15-25%) is committed to providing liquidity for the ERC20 that Health Wallet provides to users in exchange for submitting the healthcare data.
This gives Health Wallet economic controls over user activity - more revenue committing to LP means coins have more value, so more frequent entries / lower churn.
Less revenue committed to LP means more assets for marketing and adding features, but less frequent entries / higher churn.
### Security
#### User Login
2FA would be needed for both commercial & non-commercial sign-ins using email & Oauth.
Verifiable phone number would be best.
#### Uploading Data Securely
Two types of data uploads - personal and commercial. Both happen on upload.
Encrypt payload client side, decrypt serverside.
After decryption:
Commercial data is anonymized, tagged, and encrypted so that people know what the commercial data might be before trying to make a purchase to decrypt the specific data.
Personal data is securely stored in IPFS and should be *revokably* shared with others. This data should be non-anonymized and true, and give temporary access.
#### Anonymizing
Any data transmitted to the blockchain needs to be either hashed securely or anonymized, or ideally both. Healthwallet can store cypher keys for users in a Web2 (email/password/2fa) secured db.
The [LIT Protocol with Ceramic](https://github.com/LIT-Protocol/CeramicIntegration) is ideal for this application.
LIT handles revokable, temporary access to sensitive data, but relies on IPFS via Ceramic. IPFS is immutable, we'll have to keep a record of which IPFS CID (Content Identifier, basically a hash of the content of the file (which will be encrypted)) matches which autogenerated cypher. This cypher generation, encryption, and storage of the cypher and IPFS CID should all happen in a serverless environment, and additionally the decryption and delivery of decrypted data should happen serverside as well.
### Onboarding
Web2 like. Sign in with OAuth gmail/apple account etc, add more KYC data, then transmit any earned tokens to hosted wallet with send controls.
Form to send in ID to verify identity.
Users are incentivized to upload data for intellectual and emotional reasons - intellectually they are compensated for their upload with cryptocurrency that is valued by AI engineers and Medical Researchers, and emotionally they get to take their power back from big health tech and have control over their own healthcare data.
[Biconomy](https://www.biconomy.io/) | [SDK](https://docs.biconomy.io/) is a product that helps startups do exactly this.
### Uploading Data Easily
While users may be able to register a Primary Care Provider that provides information for them, because [under HIPPA, patients are entitled to request a full medical record from their PCP](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7495255/).
There's no consistent standard - bureaucracy is in full effect.
Solution: App works as a questionnaire, infrequently sending an alert that the user is eligible for new coins in exchange for answering healthcare questions. Gamelike and inobstrusive.
Further on above solution: If user has apple watch etc, allow user to integrate that for more/more consistent coin remittance.
### Estimates
Developer cost is going to be one small slice of all the headaches you're going to deal with here.
#### $90k Backend - [3 months]
#### $63k Front End - [3 months]
#### $36k Smart Contracts - [1.5 months]
#### $27k Design - [1.5 months]
#### Summation $216k