17efc4f656
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).
8.4 KiB
8.4 KiB
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 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 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 for complete roadmap.
Open Source Philosophy
Normogen is open-source because:
- Transparency: Users can verify how their data is handled
- Trust: Public code builds trust in security practices
- Collaboration: Community contributions improve the product
- Flexibility: Users can self-host if they prefer
- Innovation: Open development accelerates feature development
Contributing
We welcome contributions from developers, designers, and users. See 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
Community
- Repository: [GitHub/Forgejo URL]
- Issues: Report bugs and request features
- Discussions: Ask questions and share ideas
- Contributing: See development/README.md
Last Updated: 2026-03-09
Maintained By: Project maintainers
Version: 0.2.8 (Phase 2.8 implemented)