## Audit-Ergebnis ### Gesamturteil HealthManager verfügt über eine breite Datensammlung und gute Import-/Dashboard-Komponenten. Die domänenübergreifende Insight-Architektur ist jedoch nur für **Ernährung ↔ Symptome** teilweise umgesetzt. Apple Health, Verhalten, Medikamente und Laborwerte werden überwiegend parallel dargestellt oder gespeichert, aber nicht in einem gemeinsamen, methodisch abgesicherten Korrelationsmodell integriert. ## Abdeckung nach Domäne | Domäne | Erfasst/normalisiert | In Reports/Dashboard | Echte domänenübergreifende Analyse | Bewertung | |---|---:|---:|---:|---| | Ernährung/YAZIO | Ja | Ja | Ja, mit Symptomen und Medikationsphase | **Teilintegriert** | | Symptome | Ja, aber zwei Modelle | Ja | Ja, primär mit Ernährung | **Teilintegriert** | | Medikamente | Gaben/Termine vorhanden | Ja | Nur grobe Hyrimoz-Phasenbildung | **Überwiegend Kontext** | | Apple Health | Ja, dedupliziert/aggregiert | Ja | Nein | **Visualisiert, nicht korreliert** | | Laborwerte | Ja, mit Review/Provenienz | Ja | Nur isolierte Legacy-Labor↔Labor-Korrelation | **Nicht in multimodale Insights integriert** | | Verhalten/Stress/Sport/Schlaf | Generisch in `tagebuch`; Schlaf/Aktivität teilweise Apple Health | Teilweise | Nein | **Nur gespeichert** | | Allgemeine Insights | Tabellen vorhanden | Kaum genutzt | Kein zentraler Generator | **Architektur-Gerüst ohne Engine** | ## Priorisierte Findings ### P0 – Statistische Fehlinterpretation durch „fehlend = symptomfrei“ `nutrition_insights.py` erzeugt für jeden Ernährungstag einen Symptomwert und setzt nicht protokollierte Folgetage auf `0.0`: - `nutrition_insights.py:240–246` baut die Symptomserie. - `nutrition_insights.py:249–277` verwendet `symptoms.get(..., 0.0)`. - `nutrition_insights.py:299–303` macht dasselbe für Lebensmittel-Insights. Damit ist „kein Symptom-Log vorhanden“ nicht von „explizit Score 0“ unterscheidbar. Unvollständiges Logging kann künstliche Safe-Food-Signale und verzerrte Korrelationen erzeugen. **Sofortmaßnahme:** Nur Tage mit explizitem vollständigem Quick-Log als Outcomes verwenden; Missingness separat speichern und aus Analysen ausschließen. --- ### P0 – Legacy-Laborkorrelation verwendet falsches Datum und ungeprüfte Werte `health_manager.py`: - `get_laborwerte()` filtert und datiert über `ermittlung_datum` (`health_manager.py:166–184`). - `compute_correlations()` pivotiert darauf (`health_manager.py:332–370`). - Es gibt keinen Filter auf `validierungsstatus`. - Das Skript kann nichtnumerische Werte teilweise als `0.0` interpretieren, etwa beim CRP-Trend (`health_manager.py:293–330`). `ermittlung_datum` ist laut Workflow Import-/OCR-Zeitpunkt, nicht klinisches Abnahmedatum (`docs/health_intelligence_workflow.md:87–91`). Dadurch ist die Legacy-Korrelation medizinisch nicht belastbar. **Sofortmaßnahme:** Diese Funktion als Legacy/experimentell markieren oder deaktivieren. Nur validierte Werte und `abnahme_datum` bzw. geprüftes `befund_datum` verwenden; Zensierungen wie `<5` explizit modellieren statt Grenzwert oder Null als exakte Messung zu behandeln. --- ### P1 – Ernährung ↔ Symptome ist tatsächlich integriert, aber explorativ Vorhanden sind: - Tages- und Mahlzeitensummen, Nährstoffe und Histamin-Mappings: `yazio_nutrition_sync.py:239–351`. - Mapping-Review-Queue: `nutrition_insights.py:95–166`, `221–237`. - Pearson-Korrelationen für Histamin, Energie, Protein, Zucker, Ballaststoffe und gesättigte Fette mit Lags 0–3: `nutrition_insights.py:249–278`. - Lebensmittelbezogene Trigger-/Safe-Kandidaten: `nutrition_insights.py:281–320`. - Dashboard-Ausgabe der Korrelationen, Food-Insights, Reviews und Empfehlungen: `health_dashboard_v3.py:193–198`, `379–407`. - Persönliche Toleranzklassifikation und manueller Mapping-Workflow: `nutrition_tolerance.py:79–113`. **Limitationen:** - Pearson ohne Konfidenzintervalle, p-Wert, multiple-testing-Korrektur oder Autokorrelationskontrolle. - Nahrungstage ohne passenden Symptomlog werden als Null behandelt. - Food-Insights vergleichen exponierte Tage nicht mit geeigneten nicht exponierten Kontrolltagen. - Wiederholte Beobachtungen und zeitliche Trends werden wie unabhängige Daten behandelt. - Symptomdimensionen werden zu einem Gesamtscore addiert; unterschiedliche klinische Outcomes vermischen sich. - `n` ist Anzahl Ernährungstage, nicht Anzahl vollständiger gepaarter Beobachtungen. - Histaminregeln sind hypothesenbasierte Zuordnungen, keine individuellen Kausalitätsnachweise. Die vorhandenen „Trigger-Kandidat“- und „Safe-Kandidat“-Labels dürfen daher ausschließlich als **Hypothesengenerierung** gelten. --- ### P1 – Zwei Symptomtabellen führen zu inkonsistenter Integration Das Schema enthält sowohl `symptome` als auch `symptom_log` (`database/schema.sql:65–83`). - Quick-Logging schreibt ausschließlich in `symptom_log` und legt sieben explizite 0–3-Dimensionen an: `health_symptom_quick_add.py:25–55`, `58–93`. - Nutrition Insights lesen beide Tabellen: `nutrition_insights.py:240–246`. - Laborchart-Eventmarker und ein Teil der Nutrition-Dashboardkurve lesen nur `symptome`: `health_dashboard_v3.py:180`, `209–226`, `302–314`. - Die separate Symptom-Score-Kurve liest dagegen `symptom_log`: `health_dashboard_v3.py:437–469`. Dadurch können dieselben Dashboardbereiche unterschiedliche Symptomlagen zeigen. **Empfehlung:** Ein kanonisches `symptom_observations`-Modell bzw. eine SQL-View schaffen. Felder: Dimension, Score 0–3, explizit symptomfrei, Vollständigkeit des Tageslogs, Beginn/Ende, Quelle und Erfassungszeit. --- ### P1 – Medikamente sind sichtbar, aber nur grob als Confounder integriert Das Dashboard verwendet `medication_administrations` für Timeline, nächste Gabe und Arztübersicht (`health_dashboard_v3.py:192`, `377`, `430–445`, `494–497`). Die einzige analytische Integration: - Ermittlung des ersten Hyrimoz-/Adalimumab-Datums: `nutrition_insights.py:323–326`. - Einteilung in „vor“, erste 56 Tage und „stabil“: `nutrition_insights.py:329–367`. - Aggregierte Ernährung-/Symptommittelwerte nach Phase. **Defizite:** - Die produktiv verwendete Tabelle `medication_administrations` fehlt im versionierten `database/schema.sql`. - Keine expliziten Therapieepisoden mit Start, Ende, Dosisänderung, Pause oder Adhärenz. - Feste 56-Tage-Grenze statt konfigurierbarer, klinisch reviewbarer Phase. - Keine Wash-in-/Wash-out-Fenster. - Keine Trennung von Medikamentenwirkung, Krankheitsaktivität, Ernährung und Verhalten. - Andere Medikamente und Begleittherapien werden nicht als Confounder berücksichtigt. --- ### P1 – Apple Health ist technisch gut normalisiert, aber analytisch isoliert Positiv: - Rohdaten bleiben als Audit-Trail erhalten. - Überlappende Exporte werden dedupliziert. - Wochenaggregate werden für Sum-Metriken in Tagesäquivalente umgerechnet. - Der aktuelle, noch unvollständige Tag wird ausgeschlossen. Referenz: `apple_health_analytics.py:1–15`, `59–100`. Das Dashboard visualisiert Schritte, Distanz, Puls, HRV, Schlaf, SpO₂, Atemfrequenz, Energie, Belastung und Gewicht (`health_dashboard_v3.py:32–44`, `143–152`, `270–281`). **Aber:** Es gibt keine Apple-Health↔Symptom-, ↔Ernährung-, ↔Medikation- oder ↔Laboranalyse. Apple Health ist daher **integriert in Darstellung und Arztbericht**, nicht in die Insight-Engine. Zusätzliche Limitationen: - Tageswerte sind teilweise Mittelwerte heterogener Records. - Quellen-/Gerätewechsel werden nicht als Messregime modelliert. - Schlaf wird als Summe aggregiert; überlappende Schlafsegmente benötigen eine intervallbasierte Konsolidierung. - Das Jahresformat wird anhand eines konkreten Dateinamens erkannt (`apple_health_analytics.py:49–56`) und ist daher fragil. --- ### P1 – Labor-Provenienz ist der stärkste Safety-Bereich, aber Dashboardquelle bleibt inkonsistent Positiv: - Staging und Vier-Augen-Review sind modelliert: `database/schema.sql:115–152`. - Validierungsstatus, Abnahme-/Befunddatum und Review-Batch sind vorhanden: `database/schema.sql:14–25`. - Konservative Originaldokument-Verlinkung verlangt validierte Werte und einen Mindestscore: `link_lab_values_to_documents.py:64–93`. - Der Arztbericht filtert explizit auf validierte Laborwerte: `generate_doctor_report.py:118–143`, `181–188`. Problematisch: - Das Hauptdashboard baut die Labormatrix primär aus einer XLSX-Arbeitsmatrix: `health_dashboard_v3.py:167–169`, `234–268`. - Die Dokumentation bezeichnet den Originalbericht ausdrücklich als kanonische Quelle: `docs/architecture.md:8–11`. - Damit ist die Provenienzregel dokumentiert, aber nicht vollständig in der Dashboard-Datenquelle erzwungen. **Empfehlung:** Dashboardtrends aus einer validierten DB-View erzeugen; XLSX nur als Review-/Exportartefakt verwenden. Jeder Chartpunkt sollte intern `laborwerte.id`, `dokument_id`, Messdatum, Validierungsstatus und Quelle tragen. --- ### P2 – Allgemeine Insight-Tabellen sind weitgehend ungenutzt Schema und Migration definieren: - `health_daily_summary` - `health_insights` - `document_insights` - `korrelationen` - `auswertungen` Referenzen: `database/schema.sql:95–103`, `153–195`; `health_system_migrate.py:93–145`. Die produktive Nutrition-Engine schreibt jedoch in eigene `nutrition_*`-Tabellen. Es gibt keinen zentralen, domänenübergreifenden Generator für `health_insights`; `health_pipeline.py` zählt diese Tabelle lediglich (`health_pipeline.py:331–339`). Auch Tages-/Wochenberichte sind keine echte multimodale Zusammenfassung: - Tagesbericht liest nur Legacy-Ernährung, `tagebuch` und `symptome`, nicht `symptom_log`, Apple Health oder Medikationsgaben: `health_pipeline.py:357–379`. - Wochenbericht zählt Dokumente, Legacy-Ernährung, `symptome` und Laborreviews: `health_pipeline.py:383–404`. --- ### P2 – Verhalten ist kein analytisch nutzbares Datenmodell `tagesbuch.kategori` sieht Ernährung, Symptome, Medikamente, Sport, Schlaf und Stress vor (`database/schema.sql:104–114`). Das ist jedoch Freitext ohne: - standardisierte Intensität/Dauer, - explizite Nullbeobachtung, - Zeitzone/Tagesgrenze, - Provenienz und Vollständigkeit, - kontrolliertes Vokabular, - gemeinsame Feature-Aggregation. Damit sind Stress, Sport, Schlafhygiene, Alkohol, Rauchen oder Tagesroutinen höchstens gespeichert, nicht sicher korrelierbar. --- ### P2 – Schema-Drift zwischen Repository und produktivem Code Das versionierte Schema endet bei `sync_state` (`database/schema.sql:218–273`) und enthält mehrere vom Dashboard vorausgesetzte Tabellen nicht, unter anderem: - `nutrition_items` - `nutrition_item_nutrients` - `nutrition_histamine_scores` - `nutrition_meal_summary` - `nutrition_daily_summary_v2` - `nutrition_review_queue` - `nutrition_correlation_results` - `nutrition_food_insights` - `personal_food_tolerance` - `nutrition_treatment_phase_summary` - `nutrition_action_recommendations` - `medication_administrations` - `low_histamine_experiments` Ein Neuaufbau allein aus dem Repo-Schema wäre daher nicht reproduzierbar. ## Safety-first Roadmap ### Phase 0 – Sofort absichern 1. Legacy-`compute_correlations()` nicht klinisch anzeigen. 2. Fehlende Symptomlogs als `NULL`, nie als Score 0 behandeln. 3. Alle Insights sichtbar kennzeichnen: „explorativ – keine Kausalität“. 4. Mindestanforderungen je Analyse definieren: - vollständige gepaarte Tage, - ausreichende Expositions- und Kontrolltage, - ausreichende Varianz, - keine offenen Mapping-/Provenienzreviews. 5. Produktives Schema vollständig versionieren und Migrationstests ergänzen. ### Phase 1 – Kanonische Tages-Feature-Schicht Eine reproduzierbare `health_daily_features`-View bzw. materialisierte Tabelle schaffen: - Datum und Zeitzone - Datenvollständigkeit je Domäne - Symptomscore je Dimension plus `explicit_zero` - Ernährungsmakros und Mapping-Coverage - Apple-Health-Werte plus Quellen-/Gerätekennung - aktive Medikationsphase und Tage seit Gabe/Änderung - Verhalten: Stress, Sport, Alkohol, Schlafhygiene - keine Labore als künstliche Tageswerte; Labore bleiben sparse Events - Version der Featurelogik und Erzeugungszeit ### Phase 2 – Reviewbare Insight-Engine Ein gemeinsames Ergebnisformat in `health_insights`: - Hypothese und Zielvariable - Exposition und Lag - Analysezeitraum - vollständiges `n` und Missingness - Effektgröße plus Konfidenzintervall - Sensitivitätsanalysen - bekannte Confounder - Provenienzreferenzen, keine Rohdatenkopien - Status: `draft`, `review_required`, `accepted`, `rejected`, `expired` - Ablaufdatum bei neuen Daten oder Featurelogikänderung ### Phase 3 – Sichere Analysereihenfolge 1. **Symptom-Logging-Qualität** vor jeder Korrelation. 2. **Deskriptive Zeitreihen** und Event-Overlays. 3. **Within-person Exposed-vs-Unexposed-Vergleiche** je Symptomdimension. 4. **Lagged Modelle** mit Wochentag, Zeittrend, Medikation, Schlaf und Aktivität als Confounder. 5. Block-Bootstrap statt naiver unabhängiger-Tage-Annahme. 6. Multiple-Testing-Korrektur und Mindest-Effektgröße. 7. Ergebnisse nur als: - „kein auswertbares Signal“, - „exploratives Signal“, - „wiederholt beobachtetes Signal“. Keine automatische Kategorie „sicher“ oder „Auslöser“. ### Phase 4 – Kontrollierte N-of-1-Experimente `low_histamine_experiment.py` modelliert bisher nur Start/Challenge/Ende (`low_histamine_experiment.py:12–24`, `27–60`). Ergänzen um: - vorab festgelegtes Outcome, - Baseline- und Challenge-Dauer, - Abbruchkriterien, - Medikamentenstabilität, - Compliance/Missingness, - Re-Challenge, - adverse-event flag, - ärztliche Freigabe für potenziell riskante Änderungen. Keine automatischen Medikamenten-, Supplement- oder restriktiven Ernährungsempfehlungen. ## Explizite Grenzen des Audits - Ausschließlich Code, versioniertes Schema und Dokumentation wurden geprüft. - Keine produktiven Tabelleninhalte, Patientenwerte, Dokumenttexte oder Reports wurden gelesen. - Daher keine Aussage über tatsächliche Datenmenge, Vollständigkeit, aktuelle Cron-Ausführung oder individuelle medizinische Zusammenhänge. - Dokumentation kann der produktiven Runtime voraus- oder hinterherlaufen; die festgestellte Schema-Drift verstärkt diese Unsicherheit. ## Durchführung - Geprüft: produktive Skripte unter `~/.hermes/assets/Gesundheit/scripts/` sowie Repo-Dokumentation und `database/schema.sql`. - Keine Dateien erstellt oder verändert. - Hauptproblem: produktive Nutrition-/Medikationstabellen sind im Repo-Schema unvollständig abgebildet; dadurch ist eine rein schema-basierte Reproduktion derzeit nicht möglich.