# HealthManager – Gesamtarchitektur **Stand:** 2026-07-12 **Geltungsbereich:** produktive lokale Health-Runtime, Automatisierungen, Dashboard, Backups und sichere JARVIS-Anbindung. ## 1. Architekturprinzipien - Die produktive SQLite-Datenbank, Originaldokumente, PDFs, Exporte und Zugangsdaten bleiben lokal bzw. in verschlüsselten Backups. - GitHub enthält ausschließlich Code, Schema, Service-Templates und Dokumentation ohne Patientendaten. - Original-Laborberichte sind die kanonische Quelle für Messwerte, Einheiten, Messdaten und Referenzbereiche; strukturierte Tabellen und Dashboardansichten sind sekundär. - Das Health Dashboard ist ein geschützter Detailarbeitsplatz. Das globale JARVIS Dashboard erhält nur streng sanitizte Status-/Ampelinformationen und keine Rohdaten. - Imports und Berichte laufen reproduzierbar über Skripte und Hermes-Cronjobs; die statische Dashboard-Ausgabe wird getrennt davon ausgeliefert. ## 2. Systemübersicht ```text Health Auto Export ─┐ YAZIO ──────────────┼──> Sync/Import/Normalisierung ──> health_data.db Drive-Dokumente ────┤ │ Telegram-Einträge ──┘ ├─> sichere multimodale Hypothesenschicht ├─> Dashboard-Generator ├─> Daily/Weekly Reports ├─> Arzt-/Laborberichte ├─> Datenqualität/Reviews └─> verschlüsseltes Wochenbackup health_dashboard.html ──> health-dashboard.service ──> Port 8014/Tailscale health_data.db/Reports ──> Sanitizing/Marker Adapter ──> JARVIS Health Cockpit (keine Rohdaten) ``` ## 3. Produktive Komponenten ### 3.1 Runtime und Persistenz | Komponente | Produktiver Pfad | Aufgabe | |---|---|---| | SQLite-Datenbank | `~/.hermes/assets/Gesundheit/health_data.db` | Zentrale strukturierte Health-Daten | | Health-Skripte | `~/.hermes/assets/Gesundheit/scripts/` | Import, Analyse, Reports und Dashboard | | Inbox | `~/.hermes/assets/Gesundheit/inbox/` | Eingehende Exporte/Dokumente | | Processed/Archiv | `processed/`, `archiv/` | Nachvollziehbare Verarbeitung/Ablage | | Reports | `~/.hermes/assets/Gesundheit/reports/` | Dashboard, Daily/Weekly- und Arztberichte | | Cron-Wrapper | `~/.hermes/scripts/` | Automatisierte Laufzeit-Aufrufe | Wichtige Datenbereiche: Dokumente und Dokumentstatus, Laborwerte inklusive Provenienz, Medikamente und Einnahmen/Injektionen, Health Events und Phasen, Apple-Health-Datensätze, Ernährung/YAZIO, Histaminbewertungen, Symptome, Tagebuch, Arztbesuche, Korrelationen, Review Queues und Processing-/Report-Runs. ### 3.2 Health-Pipeline Zentrale CLI: `scripts/health/health_pipeline.py` ```bash python3 scripts/health/health_pipeline.py dashboard python3 scripts/health/health_pipeline.py correlations python3 scripts/health/health_pipeline.py daily-report --date YYYY-MM-DD python3 scripts/health/health_pipeline.py weekly-report --end-date YYYY-MM-DD python3 scripts/health/health_pipeline.py generate-lab-report python3 scripts/health/health_pipeline.py register-inbox ``` Ergänzende Komponenten: - `health_dashboard_v3.py`: erzeugt das statische Detaildashboard. - `apple_health_drive_sync.py`, `apple_health_import.py`, `apple_health_analytics.py`: Download, atomarer/deduplizierter Import und Apple Health Analytics v2 mit Zürich-Lokaltagen, metric-aware Aggregation, Quell-/Auflösungspriorität sowie Coverage-/Missingness-Metadaten. - `multimodal_correlations.py`: verbindet ausschließlich vollständige, provenance-geprüfte Tagesbeobachtungen per Spearman, kalenderwochenbasierter Blockpermutation einschließlich beobachteter Teilwochen, mindestens 60 Prozent Ziel-Coverage, Lags 0–3, konservative Behandlungsphasen und Benjamini-Hochberg-Korrektur; persistiert nur allowlist-basierte aggregierte Hypothesenresultate und behandelt Missingness nie als Symptomfreiheit. - `yazio_nutrition_sync.py`, `nutrition_tolerance.py`: Ernährungssync und manuelle persönliche Toleranzen. `nutrition_insights.py` bleibt Legacy-Code und wird von Sprint-2-Refreshpfaden und Dashboard nicht mehr verwendet. - `health_symptom_quick_add.py`, `health_symptom_from_text.py`: strukturierte Symptom-Erfassung. - `process_all_health_documents.py`, `health_doc_review.py`, `link_lab_values_to_documents.py`: Dokumentverarbeitung, Review und Provenienz. - `generate_doctor_report.py`, `generate_health_data_quality_report.py`: Arzt- und Qualitätsberichte. - `low_histamine_experiment.py`: definierte Ernährungs-/Symptom-Experimente. ### 3.3 Dashboard-Auslieferung - Generiertes Artefakt: `~/.hermes/assets/Gesundheit/reports/health_dashboard.html` - HTTP-Server: `~/projects/Jarvis/scripts/health-dashboard-static-server.py` - User-Service: `~/.config/systemd/user/health-dashboard.service` - Bind: `0.0.0.0:8014`, Zugriff im Tailnet über den Tailscale-Hostnamen. - Routen: `/health-dashboard`, `/health-doc/` und `/health-report/`. - Sicherheitsheader: `Cache-Control: no-store` und `X-Content-Type-Options: nosniff`. Der HTTP-Service generiert keine Daten. Der Apple-Health-Cron bzw. ein manueller Pipeline-Aufruf regeneriert zuerst die HTML-Datei; der Service liefert danach immer die aktuelle Datei aus. ## 4. Automatisierung | Job | Zeitplan | Aufgabe | |---|---|---| | Gesundheitsdaten Daily Sync | täglich 23:10 | Health-Dokument-/Datenpipeline | | YAZIO Import | täglich 23:15 | Ernährung synchronisieren | | Apple Health Import | täglich 23:45 | Exporte importieren und Dashboard regenerieren | | Ernährungsstrategie-Check | täglich 19:00 | Strategieabgleich bei vorhandenen Einträgen | | Symptom Quick Log Reminder | täglich 20:30 | strukturierte Erfassung erinnern | | Gesundheits-Wochenbericht | Sonntag 18:00 | aggregierten Wochenbericht erzeugen | | Verschlüsseltes Backup | Sonntag 23:55 | lokale verschlüsselte Sicherung + Drive Upload | Die aktuellen Jobdefinitionen liegen in Hermes Cron. Repo-Dokumentation enthält keine Secrets und ersetzt nicht die produktive Scheduler-Konfiguration. ## 5. Backup und Restore ### Backup `weekly_health_drive_backup.py` erstellt: 1. konsistente SQLite-Backup-Kopie nach erfolgreichem `PRAGMA integrity_check`, 2. portablen SQL-Dump über Pythons `sqlite3.iterdump()` (keine Abhängigkeit vom optionalen `sqlite3` CLI), 3. Health-Skripte ohne PDFs/Bilder/Rohdokumente, 4. Hermes Quick Backup, 5. Skills und Runtime-Skripte, 6. optional benötigte Restore-Credentials ausschließlich innerhalb des verschlüsselten Bundles. Das Tar-Archiv wird mit GPG/AES256 symmetrisch verschlüsselt. Nur die `.tar.gz.gpg`-Datei wird zu Google Drive hochgeladen. Passphrase und GOG-Keyring-Passwort werden aus lokalen Secret-Dateien bzw. der Laufzeitumgebung geladen und nie ins Repo geschrieben. ### Restore 1. Verschlüsseltes Bundle aus Drive oder lokalem Backup-Verzeichnis beziehen. 2. Mit der lokalen GPG-Passphrase entschlüsseln. 3. Archiv in ein temporäres Verzeichnis entpacken und Manifest prüfen. 4. Vorhandene produktive DB separat sichern. 5. `health/health_data.db` und benötigte Skripte wiederherstellen. 6. Hermes Quick Backup kontrolliert importieren. 7. `PRAGMA integrity_check` ausführen, Dashboard regenerieren und Services/Crons prüfen. ## 6. JARVIS-Integration und Datenschutzgrenzen JARVIS ist Orchestrator; HealthManager bleibt Eigentümer der medizinischen Detaildaten. **Erlaubt für das globale Cockpit:** Pipeline-/Report-/Backup-Frische, begrenzte Review-Anzahl, feste Ampeldomänen und geschützter Linkstatus. **Nicht erlaubt:** Laborrohwerte, PDF/OCR-Inhalte, Dokumentnamen, lokale Pfade, Drive-IDs/Links, Symptome/Tagebuchtexte, Mahlzeiten, Medikationsdetails oder rohe Apple-Health-/YAZIO-Daten. Langfristiges Ziel ist eine kleine read-only Summary API. Bis dahin sind ausschließlich streng allowlist-basierte Metadaten-/Markeradapter zulässig; das Frontend liest nie direkt SQLite. ### 6.6 Dashboard v4 Dashboard v4 übernimmt den vollständigen v3-Datenumfang und ergänzt eine mobile, touchfähige Präsentations- und Eingabeschicht. Der versionierte HTTP-Server liefert ausschließlich allowlistete lokale Routen, Chart.js 4.5.1 und nonce-basierte CSP-Header aus. Der einzige Schreibendpunkt ist Same-Origin-/CSRF-geschützt und legt ausschließlich eine atomare, private Queue-Datei in einem separaten State-Verzeichnis ab. Ein netzwerkisolierter One-shot-Worker validiert die vollständigen Symptom-Tageswerte erneut und ruft den bestehenden Quick-Log-Workflow auf; der Netzwerkdienst erhält keinen Datenbank-Schreibzugriff. Quellenfrische, Baselines und Overlays sind Datenqualitäts- beziehungsweise Dokumentationsanzeigen und erzeugen keine Diagnose- oder Kausalitätsaussage. Details und Deployment-Gates stehen in `docs/sprint3-dashboard-v4.md`. ## 7. Betriebschecks ```bash systemctl --user status health-dashboard.service curl -fsS http://127.0.0.1:8014/health-dashboard >/dev/null python3 ~/.hermes/assets/Gesundheit/scripts/verify_system.py python3 ~/.hermes/scripts/weekly_health_drive_backup.py ``` Vor Git-Publish immer sicherstellen, dass keine DBs, PDFs, Exporte, Reports, Tokens, Secret-Dateien oder lokale Patientendaten im Index liegen.