Research: MongoDB schema design complete

- Zero-knowledge encryption for ALL sensitive data + metadata
- Blood pressure example: value + type + unit ALL encrypted
- 9 collections: users, families, profiles, health_data, lab_results, medications, appointments, shares, refresh_tokens
- Client-side encryption (AES-256-GCM, PBKDF2)
- Server NEVER decrypts data
- Privacy-preserving queries (plaintext fields: userId, profileId, familyId, date, tags)
- Tagging system for encrypted data search
- Date range queries (plaintext dates)

Key principle:
- Both value AND metadata encrypted (e.g., "blood_pressure" + "120/80")
- No plaintext metadata leaks
- Server stores ONLY encrypted data

Updated tech stack decisions with MongoDB schema

All major research complete (Rust, Mobile, Web, State, Auth, Database)

Next: Backend development (Axum + MongoDB)
This commit is contained in:
goose 2026-02-14 13:39:57 -03:00
parent 203c0b4331
commit 4dca44dbbe
3 changed files with 1427 additions and 36 deletions

View file

@ -96,6 +96,82 @@
---
### 6. Database: MongoDB with Zero-Knowledge Encryption
**Decision**: MongoDB 6.0+ with client-side encryption (ALL sensitive data + metadata)
**Score**: 9.8/10
**Core Principle**: **ALL sensitive data AND metadata must be encrypted client-side before reaching MongoDB**
**Example: Blood Pressure Reading**:
```javascript
// Before encryption (client-side)
{
value: "120/80",
type: "blood_pressure",
unit: "mmHg",
date: "2026-02-14T10:30:00Z"
}
// After encryption (stored in MongoDB)
{
healthDataId: "health-123",
userId: "user-456",
profileId: "profile-789",
// Encrypted (value + metadata)
healthData: [
{
encrypted: true,
data: "a1b2c3d4...",
iv: "e5f6g7h8...",
authTag: "i9j0k1l2..."
}
]
}
```
**Rationale**:
- **Zero-knowledge**: Server NEVER decrypts data
- **Metadata encryption**: Health data type, unit, doctor, lab ALL encrypted
- **Privacy-preserving**: No plaintext metadata leaks
- **Client-side encryption**: AES-256-GCM, PBKDF2 key derivation
- **Plaintext queries**: Query by userId, profileId, familyId, date, tags
- **Tagging system**: Client adds searchable tags for encrypted data
- **Flexible schema**: MongoDB document structure fits health data
- **Scalable**: Horizontal scaling with sharding
**Collections**:
- **users**: Authentication, profiles, family relationships
- **families**: Family structure, encrypted family name/metadata
- **profiles**: Person profiles, encrypted profile name/metadata
- **health_data**: Encrypted health records (value + metadata)
- **lab_results**: Encrypted lab data (value + metadata)
- **medications**: Encrypted medication data + reminders
- **appointments**: Encrypted appointment data + reminders
- **shares**: Time-limited access to shared data
- **refresh_tokens**: JWT refresh token storage
**What Must Be Encrypted**:
- ✅ Health data values (e.g., "120/80")
- ✅ Health data metadata (e.g., "blood_pressure", "mmHg")
- ✅ Lab test results (e.g., "cholesterol", "200", "LabCorp")
- ✅ Medication data (e.g., "Aspirin", "100mg", "daily")
- ✅ Appointment data (e.g., "checkup", "Dr. Smith")
- ✅ Profile data (e.g., "John Doe", "1990-01-01")
- ✅ Family data (e.g., "Smith Family", "123 Main St")
**What Can Be Plaintext**:
- ✅ User IDs (userId, profileId, familyId) - for queries
- ✅ Email addresses - for authentication
- ✅ Dates (createdAt, updatedAt) - for sorting
- ✅ Data sources (healthKit, googleFit) - for analytics
- ✅ Tags (cardio, daily) - for client-side search
**Reference**: [2026-02-14-mongodb-schema-design-research.md](./2026-02-14-mongodb-schema-design-research.md)
---
## Technology Stack Summary
### Backend
@ -103,7 +179,7 @@
- **Runtime**: Tokio 1.x
- **Middleware**: Tower, Tower-HTTP
- **Authentication**: JWT with refresh tokens
- **Database**: MongoDB (with zero-knowledge encryption)
- **Database**: MongoDB 6.0+ (with zero-knowledge encryption)
- **Language**: Rust
### Mobile (iOS + Android)
@ -145,53 +221,96 @@
---
## Still To Be Decided
## All Major Decisions Complete ✅
### 1. Database Schema (Priority: High)
**Collections to Design**:
- Users (authentication, profiles)
- Families (family structure)
- Health Data (encrypted health records)
- Lab Results (encrypted lab data)
- Medications (encrypted medication data)
- Appointments (encrypted appointment data)
- Shared Links (time-limited access tokens)
- Refresh Tokens (JWT refresh token storage)
1. ✅ Rust Framework: Axum 0.7.x
2. ✅ Mobile Framework: React Native 0.73+
3. ✅ Web Framework: React 18+
4. ✅ State Management: Redux Toolkit 2.x
5. ✅ Authentication: JWT with refresh tokens
6. ✅ Database: MongoDB 6.0+ with zero-knowledge encryption
---
### 2. API Architecture (Priority: Medium)
## Implementation Phases
**Options**:
- REST (current plan)
- GraphQL (alternative)
- gRPC (for microservices)
- **Phase 1: Research** (COMPLETE)
- Rust framework selection
- Mobile/web framework selection
- State management selection
- Authentication design
- Database schema design
- **Phase 2: Backend Development** (NEXT)
- Axum server setup
- MongoDB connection
- JWT authentication
- CRUD API endpoints
- Zero-knowledge encryption (client-side)
- **Phase 3: Mobile Development** (AFTER BACKEND)
- React Native app setup
- Redux Toolkit setup
- JWT authentication
- Health sensor integration
- QR code scanning
- Encryption implementation
- **Phase 4: Web Development** (PARALLEL WITH MOBILE)
- React app setup
- Redux Toolkit setup
- JWT authentication
- Charts and visualizations
- Profile management
- Encryption implementation
---
## Recommended Order
## Next Steps
1. Rust Framework: Axum (COMPLETED)
2. Mobile/Web Framework: React Native + React (COMPLETED)
3. State Management: Redux Toolkit 2.x (COMPLETED)
4. Authentication: JWT with refresh tokens (COMPLETED)
5. Database Schema: Design MongoDB collections (NEXT)
6. Create POC: Health sensor integration test
7. Implement Core Features: Authentication, encryption, CRUD
1. **Backend Development** (Axum + MongoDB)
- Create Axum server
- Setup MongoDB connection
- Implement JWT authentication
- Create MongoDB indexes
- Implement CRUD endpoints
2. **Client-Side Encryption** (React Native + React)
- Implement AES-256-GCM encryption
- Implement PBKDF2 key derivation
- Create encryption utilities
- Test encryption flow
3. **API Development** (Axum)
- Users API (register, login, logout)
- Families API (create, update, delete)
- Profiles API (CRUD)
- Health Data API (CRUD)
- Lab Results API (import via QR)
- Medications API (reminders)
- Appointments API (reminders)
- Shares API (time-limited access)
---
## Next Research Priority
## Timeline Estimate
**Research Question**: What should the MongoDB schema look like for Normogen's encrypted health data platform?
- **Phase 1: Research** (COMPLETE)
- **Phase 2: Backend Development** (8-10 weeks)
- **Phase 3: Mobile Development** (8-12 weeks)
- **Phase 4: Web Development** (4-6 weeks)
- **Phase 5: Testing & Polish** (4-6 weeks)
**Considerations**:
- Zero-knowledge encryption (all sensitive data encrypted)
- Family structure (parents, children, elderly)
- Health data types (lab results, medications, appointments)
- Refresh tokens (JWT storage)
- Shared links (time-limited access)
- Permissions (family member access control)
**Total**: 24-34 weeks (6-8.5 months)
**Estimated Research Time**: 3-4 hours
---
## References
- [Axum Performance Research](./2026-02-14-performance-findings.md)
- [Frontend Mobile Research](./2026-02-14-frontend-mobile-research.md)
- [State Management Research](./2026-02-14-state-management-research.md)
- [JWT Authentication Research](./2026-02-14-jwt-authentication-research.md)
- [MongoDB Schema Design](./2026-02-14-mongodb-schema-design-research.md)
- [Normogen Encryption Guide](../encryption.md)
- [Project Introduction](../introduction.md)