Make the project's documentation match the code and remove the sprawl. The docs
claimed Phase 2.8 (drug interactions) was 'planning/0%' and the backend '~91%
complete' — both wrong: 2.8 is implemented and live, plus the P0/P1 security
and test work is done. Five root CI/CD docs described a 'docker-build' CI job
that was removed; ~18 backend/ status snapshots and ~24 docs/implementation
duplicates cluttered the tree.
Deletions (85 files):
- Root: 4 stale CI/CD reports (CI-CD-{COMPLETION-REPORT,IMPLEMENTATION-SUMMARY,
STATUS-REPORT,FINAL-STATUS}.md) — all describe the removed docker-build job.
- backend/: 18 phase/build/fix snapshots and code-dump .txt files.
- docs/: the 3 one-time reorg reports; ~17 docs/implementation duplicates and
process artifacts; 4 stale docs/development CI docs + git snapshots;
redundant deployment/testing files.
- thoughts/: STATUS.md (said Phase 2.4 in-progress), superseded phase notes and
duplicative research inputs. tmp/ (928KB of CI debug logs, gitignored).
Moves (18 files):
- 9 genuine decision records -> docs/adr/ (Architecture Decision Records),
date-prefixes stripped, with an index README.
- 8 historical-but-valuable phase plans/specs + the old CI-CD-FINAL-SOLUTION ->
docs/archive/ (now-populated, with a README explaining it's superseded
material). thoughts/ tree removed.
Rewrites (13 files) to match reality:
- Drop the fake '% complete' figures everywhere in favor of Implemented /
In-Progress / Planned with concrete endpoint/feature lists.
- Phase 2.8 -> Implemented; add /api/interactions/* and /api/auth/{refresh,
logout} to the endpoint lists; fix 'Rust 1.93' -> edition 2021.
- Add a Security section (token_version validation, hashed refresh-token
persistence, fail-fast config, real-IP audit) and correct the test-coverage
and deployment claims to reality.
- New canonical docs/development/CI-CD.md (4 jobs: format/clippy/build/test,
mongo service, no docker-build + why).
- README, docs/README, product/{STATUS,ROADMAP,PROGRESS,README,introduction},
implementation/README, development/README, testing/README, AI_AGENT_GUIDE,
.cursorrules, .gooserules all updated.
Verified: greps for 'Phase 2.8 (Planning)', 'PLANNING (0%)', 'Rust 1.93',
'91%/10%/85% complete', and 'docker-build' return nothing outside docs/archive;
all internal doc links resolve; backend/src untouched (cargo build clean).
276 lines
8.4 KiB
Markdown
276 lines
8.4 KiB
Markdown
# Normogen Project Introduction
|
|
|
|
## Naming & Origin
|
|
|
|
**Normogen** comes from Mapudungun (the language of the Mapuche people), relating to "Balanced Life." The commercial name is yet to be defined.
|
|
|
|
---
|
|
|
|
## Purpose & Vision
|
|
|
|
### Vision Statement
|
|
> "To empower individuals with complete control over their health data through secure, private, and open-source technology."
|
|
|
|
### Mission Statement
|
|
> "Build the most comprehensive, secure, and user-friendly health data platform that puts users in control, not corporations."
|
|
|
|
### Core Purpose
|
|
To record as many variables related to health as possible, store them in a secure, private manner, to be used by **the user**, not by corporations. From reminding about medication, to comparing data changes over time, and finding emerging patterns.
|
|
|
|
---
|
|
|
|
## What Makes Normogen Different
|
|
|
|
### 🔒 Privacy-First
|
|
- **Zero-knowledge encryption**: Your data is encrypted and only you hold the keys
|
|
- **No data selling**: We will never sell your data to third parties
|
|
- **Open-source**: Full transparency in how we handle your data
|
|
|
|
### 👤 User-Centric
|
|
- **You own your data**: Complete control over your health information
|
|
- **Easy sharing**: Share specific data with healthcare providers, family, or caregivers
|
|
- **Self-hostable**: Run your own instance if you prefer
|
|
|
|
### 🌐 Community-Driven
|
|
- **Open-source**: Built by the community, for the community
|
|
- **Transparent**: All code is publicly auditable
|
|
- **Collaborative**: Bug fixes and features from open-source contributors
|
|
|
|
---
|
|
|
|
## Business Model
|
|
|
|
### Sustainable, Not Surveillance
|
|
|
|
Normogen's revenue will come from **user subscriptions**, not from using or selling data.
|
|
|
|
**Why subscriptions?**
|
|
- Aligns our incentives with user privacy
|
|
- Funds ongoing development and maintenance
|
|
- Provides predictable, sustainable revenue
|
|
- No pressure to monetize user data
|
|
|
|
**Why open-source?**
|
|
- The architecture is complex enough that users will want to pay for a hosted service rather than setting it up themselves
|
|
- Bug fixes and features from the open-source community offset potential lost income
|
|
- Builds trust and transparency
|
|
- Encourages community contributions
|
|
|
|
### Target Audience
|
|
|
|
#### Primary: Privacy-Conscious Individuals
|
|
- Age: 25-45
|
|
- Tech-savvy
|
|
- Concerned about data privacy
|
|
- Wants to track medications and health stats
|
|
- Values control over their data
|
|
|
|
#### Secondary: Family Caregivers
|
|
- Age: 30-55
|
|
- Managing health data for dependents (children, elderly)
|
|
- Needs easy data sharing
|
|
- Wants medication reminders
|
|
- Manages family health history
|
|
|
|
#### Tertiary: Health Enthusiasts
|
|
- Age: 20-40
|
|
- Tracks fitness, sleep, nutrition
|
|
- Uses wearables and sensors
|
|
- Wants data analytics and insights
|
|
- Interested in health trends
|
|
|
|
---
|
|
|
|
## Architecture
|
|
|
|
### Client-Server Architecture
|
|
- **Server**: Linux Docker container (Rust backend)
|
|
- **Clients**: Web application and mobile apps (iOS, Android)
|
|
- **Database**: MongoDB 7.0 with encryption
|
|
|
|
### Technology Stack
|
|
|
|
#### Backend
|
|
- **Language**: Rust (edition 2021; performance, safety)
|
|
- **Framework**: Axum 0.7 (async web framework)
|
|
- **Database**: MongoDB 7.0 (flexible document storage)
|
|
- **Security**: JWT authentication, PBKDF2 password hashing, AES-256-GCM encryption
|
|
|
|
#### Frontend
|
|
- **Web**: React 19.2.4 + TypeScript 4.9.5
|
|
- **Mobile**: Native iOS (Swift) and Android (Kotlin) - planned
|
|
- **UI**: Material-UI (consistent design)
|
|
|
|
### Security Architecture
|
|
- **Encryption at rest**: All sensitive data encrypted
|
|
- **Zero-knowledge**: Server cannot access user data
|
|
- **Shareable links**: Secure sharing with time-limited access
|
|
- **Comprehensive**: See [encryption.md](./encryption.md) for details
|
|
|
|
---
|
|
|
|
## Application Features
|
|
|
|
### User Structure
|
|
- **User accounts**: Secure authentication with JWT
|
|
- **Person profiles**: Multiple profiles per account (e.g., parent managing child's data)
|
|
- **Family structure**: Link related individuals (parents, children, elderly under care)
|
|
|
|
### General Features
|
|
|
|
#### Health Data Management
|
|
- **Lab results storage**: Store and track lab results over time
|
|
- **Medication management**:
|
|
- Pill shape and identification
|
|
- Duration of treatment
|
|
- Timetable and reminders
|
|
- Drug composition and interactions
|
|
- **Health statistics**: Track weight, height, blood pressure, etc.
|
|
- **Medical appointments**: Schedule and track appointments
|
|
- **Regular checkups**: Preventive care tracking
|
|
- **Period tracking**: Menstrual cycle tracking
|
|
- **Pregnancy tracking**: Pregnancy milestones and health data
|
|
- **Dental information**: Dental records and appointments
|
|
- **Illness records**: Track illnesses and recoveries
|
|
|
|
### Phone App Features
|
|
|
|
#### Core Features
|
|
- **Pill reminders**: Never miss a medication dose
|
|
- **QR code reader**: Quick access to lab results and medical data
|
|
- **Health statistics import**: From phone's Health API and connected devices:
|
|
- Steps and physical activity
|
|
- Breathing and respiratory data
|
|
- Sleep patterns
|
|
- Blood pressure
|
|
- Temperature and other vitals
|
|
- **Regular sync**: Sync data back to main server at regular intervals
|
|
- **Privacy control**: Instant nuke option to delete all local data
|
|
|
|
#### Sensor Integration
|
|
Most sensors will have a common interface or data will be accessible through the phone's Health API, but plugin support for custom sensors will be available.
|
|
|
|
### Data Import/Export
|
|
|
|
#### Plugins System
|
|
- **Lab results**: Import from various labs (non-standard format)
|
|
- **Wearables**: Import data from fitness trackers and health devices
|
|
- **EHR systems**: Export/import from electronic health records (planned)
|
|
- **Pharmacies**: Medication data and refill information (planned)
|
|
|
|
---
|
|
|
|
## Success Metrics
|
|
|
|
### User Engagement
|
|
- User adoption rate
|
|
- Active user retention
|
|
- Data entry frequency
|
|
- Feature utilization
|
|
|
|
### Privacy & Security
|
|
- **Zero** data breaches (target)
|
|
- Security audit results
|
|
- Encryption coverage
|
|
- User trust scores
|
|
|
|
### Technical Excellence
|
|
- API uptime (target: 99.9%+)
|
|
- Response times
|
|
- Test coverage (target: 90%+)
|
|
- Bug fix time
|
|
|
|
### Community
|
|
- Open-source contributors
|
|
- GitHub stars/forks
|
|
- Community engagement
|
|
- Feature requests
|
|
|
|
---
|
|
|
|
## Current Status
|
|
|
|
**Backend**: ✅ Phase 2.x feature-complete (through drug interactions); security-hardened.
|
|
**Frontend**: 🚧 Early (Login/Register + API/store layer; router not yet wired).
|
|
**Deployment**: Docker on Solaria (image built manually — not in CI).
|
|
|
|
See [STATUS.md](./STATUS.md) for detailed progress tracking.
|
|
|
|
---
|
|
|
|
## Roadmap Highlights
|
|
|
|
### Phase 2.8 (core implemented)
|
|
- ✅ Drug interaction checking (`/api/interactions/check`, `/check-new`)
|
|
- 🔔 Automated reminder system (not started)
|
|
- 📊 Advanced health analytics (not started)
|
|
- 📄 Healthcare data export, FHIR/HL7 (not started)
|
|
|
|
### Phase 3 (Planned - Q2 2026)
|
|
- Complete frontend web application
|
|
- Dashboard with health overview
|
|
- Medication management UI
|
|
- Data visualization
|
|
|
|
### Phase 4 (Future - 2027)
|
|
- Mobile apps (iOS, Android)
|
|
- AI/ML features for predictions
|
|
- Third-party integrations
|
|
- Wearable device support
|
|
|
|
See [ROADMAP.md](./ROADMAP.md) for complete roadmap.
|
|
|
|
---
|
|
|
|
## Open Source Philosophy
|
|
|
|
Normogen is open-source because:
|
|
|
|
1. **Transparency**: Users can verify how their data is handled
|
|
2. **Trust**: Public code builds trust in security practices
|
|
3. **Collaboration**: Community contributions improve the product
|
|
4. **Flexibility**: Users can self-host if they prefer
|
|
5. **Innovation**: Open development accelerates feature development
|
|
|
|
### Contributing
|
|
We welcome contributions from developers, designers, and users. See [development/README.md](../development/README.md) for guidelines.
|
|
|
|
---
|
|
|
|
## Privacy Commitment
|
|
|
|
### We Promise
|
|
- ✅ **Never** sell your data to third parties
|
|
- ✅ **Never** use your data for advertising
|
|
- ✅ **Always** encrypt your data at rest
|
|
- ✅ **Always** give you control over your data
|
|
- ✅ **Always** be transparent about data practices
|
|
|
|
### We Don't
|
|
- ❌ Sell user data
|
|
- ❌ Share data without consent
|
|
- ❌ Use data for advertising
|
|
- ❌ Track users across websites
|
|
- ❌ Retain data longer than necessary
|
|
|
|
---
|
|
|
|
## Contact & Community
|
|
|
|
### Documentation
|
|
- [Product Documentation](./README.md)
|
|
- [Development Status](./STATUS.md)
|
|
- [Project Roadmap](./ROADMAP.md)
|
|
- [Security Architecture](./encryption.md)
|
|
|
|
### Community
|
|
- **Repository**: [GitHub/Forgejo URL]
|
|
- **Issues**: Report bugs and request features
|
|
- **Discussions**: Ask questions and share ideas
|
|
- **Contributing**: See [development/README.md](../development/README.md)
|
|
|
|
---
|
|
|
|
**Last Updated**: 2026-03-09
|
|
**Maintained By**: Project maintainers
|
|
**Version**: 0.2.8 (Phase 2.8 implemented)
|