--- name: health-data-management description: Gesundheitsdaten-Verwaltungssystem — JARVIS verwaltet alle Gesundheitsdaten (Laborwerte, Dokumente, Symptome, Auswertungen) version: 2.4.30 tags: [health, database, pdf, camelot, watchdog, statistics] --- # Health Data Management — Chief Medical Data Officer ## Übersicht Alle Gesundheitsdaten unter `~/.hermes/assets/Gesundheit/`. **Live-State-Regel:** Keine Labor-, Dokument-, Event-, Volltext- oder Tabellenanzahl aus diesem Skill als aktuellen Zustand übernehmen. Solche Zähler altern nach jedem Import oder Sprint. Vor Analyse, Migration oder Release die aktive DB read-only abfragen und bei Labor-/Dokumentparität den reproduzierbaren Audit aus `references/labor-source-reconciliation-and-private-release.md` verwenden. In Skills bleiben nur Schema-/Workflowverträge; konkrete Zähler gehören in datierte, aggregierte Release-Evidenz. Master-Datenbank: `health_data.db`. Auch Tabellenbestand und optionale Tabellen (`processing_log`, FTS-/Stagingtabellen usw.) vor Verwendung über `sqlite_master` beziehungsweise den aktiven Schema-Contract ermitteln, nicht aus historischen Skillzahlen ableiten. **Sicherer Dokumenteingang:** Bestandszahlen und Extraktionslücken immer live ermitteln. Neue und bestehende medizinische Dokumente über Quarantäne → lokale, versionierte Extraktion → Kandidaten-Staging → expliziten Review führen; keine automatische medizinische Freigabe oder kanonische Übernahme. Vollständiger Vertrag: `references/secure-document-intake-and-medical-review.md`. Historische Docling-Zähler sind keine aktuelle Evidenz. **Geführtes Dokument-Prüfzentrum:** Nutzerarbeit als echte Entscheidungen statt als Dokumentanzahl modellieren. Byte-Dubletten und identische Abschnitte deterministisch unterdrücken, nahe Wiederholungen nur als Diff zeigen, DB/XLSX-Abgleich getrennt halten und kanonische Übernahme ausschließlich über versioniertes Preview → separate Action-Inbox-/Worker-Bestätigung erlauben. Der Worker prüft nur ein vorab migriertes Schema und verwirft veraltete Vorschauen anhand Text-/Kandidaten-/Reconciliation-Revision. Vollständiger Vertrag und fokussierte Gates: `references/guided-document-reconciliation-and-transfer.md`. **Sichere lokale klinische Medien:** HEIC/HEIF/JPEG/PNG und kurze HEVC-MOV/MP4 nur über einen gemeinsamen inhaltsbasierten Validator für Dokument- und Mobile-Capture annehmen. Echte Decode-Selbsttests, private Originale, metadatenfreie Derivate, additive Reviewmetadaten und synthetische Browser-/Migrationsgates sind in `references/secure-local-clinical-media-intake.md` beschrieben. Medien allein erzeugen niemals kanonische medizinische Fakten. ## Verzeichnisstruktur ``` Gesundheit/ ├── health_data.db # Master-Datenbank; Bestand live prüfen ├── inbox/ # Neue Dokumente (Watchdog überwacht) ├── processed/ # Verarbeitete Dokumente ├── archiv/ # Alle Dokumente kategorisiert │ ├── laborberichte/ │ ├── klinische_befunde/ │ ├── medikamente/ │ ├── krankheitsgeschichte/ │ ├── wearables/ │ ├── ernaehrung/ │ └── sonstiges/ ├── reports/ # Generierte Reports (PNG, HTML) ├── scripts/ # Verarbeitungs-Skripte │ ├── health_manager.py # Haupt-Manager (CRP, Korrelationen, Dashboards) │ ├── health_watchdog.py # Daemon für automatische PDF-Verarbeitung │ ├── health_watchdog.sh # Start/Stop/Status Wrapper │ └── verify_system.py # System-Verification ├── backup_original/ # FRIDAY-Backup (62 Dateien) └── logs/ # Watchdog-Logs ``` ## Datenbank-Schema (fachliche Tabellen; Bestand live prüfen) Typische kanonische bzw. fachliche Tabellen sind unter anderem: 1. **laborwerte** — kanonische, originalgeprüfte Laborbeobachtungen 2. **health_events** — dokumentierte Gesundheitsereignisse 3. **dokumente** — Dokumentmetadaten und private Originalreferenzen 4. **medikamente** — Medikamentenstamm/-status 5. **dokumente_status** — Status-Tracking 6. **symptome** und **symptom_log** — Symptomstamm und Tagebuch 7. **vitalzeichen** — Blutdruck, Puls, Temperatur 8. **arztbesuche** — Arztbesuche 9. **ernaehrung** — Ernährungsdaten 10. **tagebuch** — universelle Tagebuch-/Gesundheitseinträge 11. **korrelationen** und **auswertungen** — Analysen und generierte Ergebnisse Optionale Staging-, Review-, FTS-, Apple-Health-, Nutrition- und Migrations-Tabellen hängen vom aktiven additiven Schema ab. Vor jedem Workflow über `sqlite_master`, Spaltenverträge und Migration-Marker ermitteln; weder Tabellenanzahl noch Zeilenzähler aus dieser Skill-Datei ableiten. **Dokument-Coverage:** Extraktions-, Original-, Kandidaten- und Review-Coverage stets live und aggregiert aus dem aktiven Schema bestimmen. Fehlender Volltext ist keine Aufforderung für einen Legacy-Direktimport; für V5 immer den sicheren Quarantäne-/Reviewvertrag verwenden. ## Workflow ### Dokumenten-Klassifizierung (KRITISCH) **Arztbericht** (Ambulanter Bericht, Konsultation, Visitenbericht): - Kategorie: `BEFUNDE` - Methode: PyMuPDF (fitz) → Volltext extrahieren - Speicherung: Volltext in `extrahierte_inhalte` für spähere Abfragen - Metadaten: Dokumentdatum, Behandler, Diagnose als Annotation am Textbeginn - Datei: `archiv/befunde/` **Laborbericht** (Blutwerte, Urin, Befunde mit tabellarischen Werten): - Kategorie: `LABOR` - Methode: Camelot/pdfplumber → tabellarische Werte extrahieren - Speicherung: Einzelne rows in `laborwerte` Tabelle - Datei: `archiv/laborberichte/` **Sonstiges** (Rezepte, Sonstiges): - Kategorie: `SONSTIGES` - Methode: Je nach Inhalt - Datei: `archiv/sonstiges/` ### Legacy-Verarbeitungsablauf (nur Altpfad, nicht für V5-Dokumentreview) > **Nicht für neue V5-Imports verwenden:** Die folgenden Schritte beschreiben den historischen Direktimport. Für V5 gilt `references/secure-document-intake-and-medical-review.md`: maschinelle Extraktion und Kandidaten bleiben ungeprüft; keine direkte Mutation kanonischer Labor-/Medikamenten-/Diagnosedaten und kein automatischer Reviewstatus. 1. Dokument → `inbox/` kopieren 2. Dokument-Typ klassifizieren (Arztbericht vs. Laborbericht) 3. **Fallback:** Watchdog-Daemon ist unzuverlässig → manuell verarbeiten mit `health_manager.process_inbox_pdf()` 4. Bei Arztbericht: PyMuPDF Volltext → Datenbank (extrahierte_inhalte) 5. Bei Laborbericht: Camelot/pdfplumber → laborwerte Tabelle 6. Metadaten extrahieren (Datum, Behandler, Diagnose) → im Text annotieren 7. Datenbank-Eintrag erstellen/aktualisieren mit korrekter Kategorie 8. Status auf `eingearbeitet` setzen 9. Datei an korrekten Archiv-Ort verschieben ## Health Manager Subagent ### Haupt-Skript: `health_manager.py` **Methoden:** - `get_laborwerte(parameter, start_date, end_date)` — Laborwerte laden (FRIDAY-Schema: `parameter_name`, `ermittlung_datum`) - `compute_crp_trend()` — CRP-Trend mit scipy (P-Werte) - `compute_correlations(target_parameter)` — Korrelationsanalyse mit statsmodels - `generate_plotly_dashboard(output_path)` — Interaktives HTML-Dashboard - `generate_profiling_report(output_path)` — ydata-profiling HTML-Report - `generate_heatmap(parameter_list, output_path)` — Heatmap mit matplotlib/seaborn - `process_inbox_pdf(pdf_path)` — Manuelle PDF-Verarbeitung ### Watchdog-Daemon ```bash # Starten bash ~/.hermes/assets/Gesundheit/scripts/health_watchdog.sh start # Stoppen bash ~/.hermes/assets/Gesundheit/scripts/health_watchdog.sh stop # Status bash ~/.hermes/assets/Gesundheit/scripts/health_watchdog.sh status # Neustarten bash ~/.hermes/assets/Gesundheit/scripts/health_watchdog.sh restart ``` ### Python-Umgebung - Keinen globalen Interpreter oder Paketinstallationsort voraussetzen. Vor Health-Pipelines und Deployments den tatsächlich verwendeten Interpreter für CLI, systemd-Unit und `sys.executable`-Subprozesse getrennt ermitteln. - Für jede Laufzeitrolle den deklarierten Interpreter separat verifizieren: Unit-/Server-Imports mit `ExecStart`, Worker/Mutation mit deren `sys.executable`, Offline-Generator mit seiner dependency-vollständigen Umgebung. Ein grüner Test oder Generatorlauf in einem anderen Virtualenv beweist die jeweilige produktive Rolle nicht; der Server muss aber nicht künstlich alle reinen Build-Abhängigkeiten des Generators enthalten. - Wenn eine Unit einen verwalteten Interpreter benötigt, diesen deklarativ in `ExecStart` festhalten, per Regression und `systemd-analyze` prüfen und erst danach deployen. - **Capture-Worker-Abhängigkeitsfalle:** Vor klinischem Medien-Intake mit dem exakten `ExecStart`-Interpreter sowohl `media_runtime_self_test()` als auch eine echte V5-Generierung testen. `Pillow` allein genügt nicht; `deploy/requirements-health-media.txt` enthält `pillow-heif`. Der V5-Provider importiert außerdem `scipy` über `multimodal_correlations.py`. Fehlt eine transitive Abhängigkeit, kann `apply_capture_action()` die DB-/Mediendaten bereits committen und erst bei der nachgelagerten Dashboard-Regeneration scheitern; dann steht das Receipt auf `rejected` und die Queue-Datei auf `.failed`. Abhängigkeit im Unit-Interpreter reparieren, dieselbe `.failed`-Datei mit identischem Idempotency-Key erneut als `.json` einreihen und erst nach `processed`, frischem Dashboard-mtime, DB-Integritätscheck und erfolgreichem `open_capture_media(..., 'preview')` abschließen. - Watchdog-PID: `~/.hermes/assets/Gesundheit/health_watchdog.pid` - System-Verification immer mit demselben verifizierten Interpreter ausführen. ## Health Intelligence Workflow (ab 2026-05-12) - JARVIS Health Risk Cockpit / Safe Summary: when exporting Health status to JARVIS, use `references/jarvis-health-risk-cockpit-safe-summary.md`. Emit only fixed risk-domain Ampeln and freshness categories; keep reports, PDFs, OCR, raw labs, raw symptoms, filenames, paths, Drive IDs, and exact values inside HealthManager/protected dashboard. - Migration: `scripts/health_system_migrate.py` legt Review-/Staging-/Insight-/Report-Tabellen an und macht vorher ein DB-Backup unter `backups/`. - `scripts/health_pipeline.py` ist die zentrale Pipeline: `generate-lab-report`, `export-correction`, `import-correction`, `dashboard`, `daily-report`, `weekly-report`, `status`. - Vollverarbeitung/Datenqualität: `scripts/process_all_health_documents.py` verarbeitet alle Dokumente in `dokumente` mit PyMuPDF/OpenPyXL und Docling-Fallback, aktualisiert `extrahierte_inhalte`, `datei_hash`, `local_original_path`, `document_insights` und markiert Duplikate konservativ als `review_status='duplicate_candidate'` ohne zu löschen. **Das Legacy-Skript `scripts/link_lab_values_to_documents.py` nicht für kanonische Backfills verwenden:** seine datums-/namensbasierte Heuristik erfüllt den exakten Provenienzvertrag nicht. Labor↔Dokument-Abgleich stattdessen read-only auditieren und nur bereits vorhandene eindeutige `dokument_id`-Relationen oder eindeutige unveränderliche Hashrelationen nach Digestbestätigung, privatem Backup und Copy-first-Validierung nach `canonical_document_id` übernehmen. Vor Commit muss eine vollständige logische DB-/Schema-Digestprüfung alle Tabellen und alle nicht beabsichtigten Linkzellen schützen; Trigger-Nebenwirkungen auf andere Laborzeilen oder `dokumente.review_status` müssen die Transaktion zurückrollen. Private Reports/Backups erst nach symlinkfreier `lstat`-Prüfung des Roots anlegen oder chmodden. Danach `scripts/generate_health_data_quality_report.py` nur als technischen QA-Bericht ausführen. Vollständiger Ablauf: `references/labor-source-reconciliation-and-private-release.md`. - Dashboard v3 (`scripts/health/health_dashboard_v3.py`) rendert Labortrends stabil ohne Chart.js-Annotation-Plugin: Messlinien, Achsen, Referenzbänder/-Grenzlinien und Health-Event-Marker sind normale Chart.js-Datasets. `health_pipeline.py dashboard` ruft diesen Renderer auf. Die Tabelle „Klinische Events, Medikamente & Symptome“ schliesst routinemässige LABOR/PROFIL/BEFUNDE-Artefakte aus; Laborwerte gehören in die Trendcharts, nicht in die Event-Tabelle. Seit 2026-05-12 enthält das Dashboard zusätzlich Behçet-relevante Charts wie BSG, Differentialblutbild, Fibrinogen, Gesamtcholesterin, Triglyceride, Homocystein, Nieren-/Urinmarker und Leberwerte. - Laborwarnungs-Safety: automatische Dashboardhinweise ausschließlich aus `validierungsstatus='validiert'`, `verified_against_original=1` und `reference_range_source='scanned_original'`. Vergleichsoperatoren `<`, `<=`, `>`, `>=` semantisch erhalten; Einheit und Original-Referenzgrenze verlangen. Keine festen CRP-/D-Dimer-Grenzen ohne labor-/einheitensichere Referenz. Fehlende automatische Hinweise sind niemals medizinische Entwarnung. Dieselben Grenzen gelten für automatisch ausgewählte Laborwerte in Arztberichten. - Dashboard v3 enthält Originaldokument-/PDF-Links via `drive_web_url` oder `file://`, Health-Event-/Symptom-Tabellen, `health_event_periods` für Aphthen/Schübe/Medikationsphasen und `nutrition_daily_features` mit keywordbasierter Ernährungsplan-Treue. Zeitraum-Events können per `scripts/health_add_event_period.py --start YYYY-MM-DD --end YYYY-MM-DD --type Aphte ...` erfasst werden. - YAZIO Nutrition Dashboard: Für YAZIO-Ernährung keine Live-Webapp als Primärquelle bauen; immer in HealthManager-DB normalisieren (`nutrition_items`, `nutrition_item_nutrients`, `nutrition_meal_summary`, `nutrition_daily_summary_v2`, Histamin-/Alias-Tabellen) und das Dashboard über `health_pipeline.py dashboard` regenerieren. Backfills sind per Datum möglich; Sync muss idempotent sein, heute/gestern im Cron prüfen, still bleiben wenn unverändert, und nur bei Änderungen Dashboard neu rendern. Histamin/SIGHi-Ampeln sind reviewbare Hypothesen mit Unknown-State und dürfen nicht als medizinische Kausalität ausgegeben werden. Dashboard-Nährstoffe erst nach read-only Feld-/Einheiten-/Coverage-Inventur über einen versionierten, fail-closed Normalisierungsvertrag freigeben; Missingness bleibt `null`. Rohwert/-einheit unverändert neben kanonischer Einheit, Faktor, Status und Vertragsversion speichern; niemals nach plausibler Größenordnung umrechnen. Export-Default-Nullen ohne explizite Null-Evidenz als `unknown` mit Rohprovenienz erhalten, nicht verwerfen oder als `not_reported`/echte null umdeuten. Food, lokale Schätzung und Supplement getrennt aggregieren; Kombination nur explizit als Gesamtsicht. Cockpit-Charts brauchen eigene 0-/1-/n-Punktzustände, maximal sechs Prioritätskarten und Detailtabelle/Ereignisspur im normalen eingeklappten Layoutfluss. Patient-Action-DDL ausschließlich über eine explizite Copy-first-/Restore-getestete Migration ausführen; der Worker prüft das Schema vor jeder Mutation und verändert es nie. Details: `references/yazio-nutrition-dashboard-workflow.md` und `references/dashboard-v5-nutrition-cockpit-safe-migrations.md`. - Lokale öffentliche Nährstoffreferenzen: Offizielle BLV-/vergleichbare Tabellen nur als datierten, checksum-verifizierten lokalen Snapshot verwenden. Profilgruppen, Lebensphasen, Zuschläge, Alters- und Zeitraumgrenzen fail-closed auflösen; alle Nährstoffe inklusive Unknown sichtbar halten und 1/7/30-Tage-Nenner pro Nährstoff bestimmen. Browser-Actions benötigen fortbestehende Session + exakten erlaubten HTTP/HTTPS-Origin + Einmal-CSRF; Idempotenz muss über private Worker-Receipts auch nach Queue-Konsum halten. Schwere statische Browser-Katalogabfragen pro Seite deduplizieren, weil parallele SQLite-Deadline-Abbrüche trotz seriell grüner Endpunkte auftreten können. Vollständiger Vertrag: `references/local-nutrient-references-and-secure-dashboard-actions.md`. - Apple Health Auto Export: iPhone-App auf Google Drive + JSON konfigurieren. Tatsächlicher App-Zielordner nach Testexport: `Health Auto Export` ID `1BPtqp9h72eh5GQZRSszIn-pYKX6AGUaT` (Dateien `HealthAutoExport-2026-19.json`, `HealthAutoExport_jahr-2025.json`, tägliche `HealthAutoExport_jahr-YYYY-MM-DD.json`). Import über `scripts/apple_health_drive_sync.py`; Parser unterstützt `{data:{metrics:[{name,units,data:[...] }]}}` und Schlafwerte via `totalSleep`. Raw/normalisierte Daten liegen in `apple_health_records`, Importdateien in `apple_health_import_files`. Für Berichte/Dashboard niemals Rohwerte direkt summieren: `scripts/apple_health_analytics.py` nutzen. Analytics v2 behandelt Zürich-Lokaltage, provisorische aktuelle Tage, Exportduplikate, direkte-vor-gruppierter Auflösung, konservative Quellenklassen, metrikspezifische Summe/Durchschnitt/Last-Semantik, kanonische Einheiten sowie metric-aware Coverage. Coarse-Fallback nur über explizite gruppierte Dateiverträge bestimmen; unterbrochene 1–2-Zeilen-Exporte trotzdem klassifizieren, datierte Tagesdateien ausschließen. Vor Deduplizierung UTC-Zeit, Einheit und Quellenklasse kanonisieren; Alias-Namen derselben gewählten Quellenklasse kombinieren. Coverage in Zürich-Zeit SQL-seitig begrenzen, keine `raw_json`-Payloads laden und ausschließlich als Datenqualität darstellen. Für Dashboard-API-Zeiträume Apple-Rohkandidaten bereits per indexfreundlichem `(metric,start_date)`-Fenster begrenzen: einen Kalendertag vor `start` bis einschließlich einen Tag nach `end` (technisch mit exklusiver ISO-Kante am Folgetag). Die endgültige Tageszuordnung und exakte Filterung bleiben ausschließlich bei `daily_points()` in `Europe/Zurich`; niemals `substr(start_date,...)` dafür verwenden. ISO-Minimum-/Maximum-Grenzen ohne Datumsüberlauf behandeln; Source-Row-Limit und Query-Timeout bleiben fail-closed. Regression: kleines Rohzeilenlimit, historische Out-of-window-Zeilen und ein relevanter UTC-naher Zielwert müssen für Serie, Kalender und Day API konsistent erfolgreich sein. Vollständige Muster und Tests: `references/apple-health-analytics-v2-patterns.md`. Täglicher no-agent Cron `bdc03626e17f` läuft 23:45 via `~/.hermes/scripts/apple_health_daily_sync.py` und bleibt still, wenn nichts Neues importiert wurde. - Dashboard v4 Security/Medical-Safety: Netzwerk-Serving, Queue und DB-/Report-Writer strikt trennen; alle Analytics-Helfer vollständig DB-injizierbar halten; Host-Allowlist vor jeder HTTP-Methode, monotone CSRF-TTL, rekursive Duplicate-JSON-Key-Abweisung, kanonische Pfadgrenzen und nonce-CSP ohne Inline-Eventhandler verwenden. Missingness in jeder Day/Meal/Item/Timeline/KPI-Ansicht als unbekannt erhalten, explizite Null unterscheiden, Histamin nur bei vollständiger Klassifikation anzeigen und Medikationsgaben ausschließlich über eine positive `administered`/`verabreicht`-Allowlist markieren. Adversariale Tests und Release-Gates: `references/privacy-hardened-health-dashboard.md`. - Sensible read-only Gesundheitsdaten-API: Vor parametrisierten Serienendpunkten einen evidenzgebundenen Metrikkatalog bauen; beobachtete Identifier nicht automatisch freigeben. API default-off mit strikt vom Legacy-/Dokumentpfad getrennter read-only DB und privater Bearer-Token-Datei, Host/Auth/Origin/Methoden-Gate, strikt gebundenem Queryparser, festen SQL-Templates, Query-Deadline, getrennten Source-/Response-Limits und `no-store` auch bei unbekannten/Absolute-Form-Methoden, Serialisierungsfehlern oder nicht-endlichen JSON-Werten. Availability muss exakt den ausgabefähigen Serien-/Laborvertrag spiegeln: vollständige Symptomtage, kanonisch eindeutige Laborbeobachtungen, endliche Werte, gültige Referenzgrenze, sichere Einheit und kein Zukunftsdatum. API-Dokumente erhalten nichtnumerische opaque IDs ohne Legacy-Route; Metadatenfilter blockieren auch Traversal, allgemeine absolute Pfade, URLs und Drive-ID-Tokens. Medikamenten-Positive-Allowlist bereits vor SQL-Limit anwenden. Missing/Null/0, ISO-Grenzdaten, vollständige Wochen, gepaarter Blutdruck, statischer Fallback sowie eingefrorene dreistufige RC-Reviews sind in `references/sensitive-read-only-health-api-patterns.md` beschrieben. - Dashboard-v5 Gesundheitsakte und lokale Dokumentensuche: Aktenfunktion generatorseitig default-off halten; ein explizites Flag darf abhängige Kalender-/Explorer-Features aktivieren, aber ohne Flag weder Akten-Markup/-Asset noch Session-/API-Anfragen erzeugen. Die bestehende Explorer-Session bleibt der einzige Browser-Session-Eigentümer. Akten-Read-APIs additiv halten; bestehende strenge `/labs`-Defaults nicht mit Aktenfiltern aufweichen. Dokumente nur über domänenseparierte opaque IDs projizieren; weder numerische IDs, Pfade, Originaldateinamen, Drive-IDs/-URLs oder Tokens ausgeben. Lokale FTS5-Indizes ausschließlich in einem expliziten, idempotenten Maintenance-CLI bauen (`--check`, `--rebuild`, `--drop`); Dashboard-Reads schreiben nie. Nur `review_status='geprueft'` indexieren, FTS5-Verfügbarkeit prüfen, Rebuild transaktional ausführen und nach Restore deterministisch neu aufbauen. Browser-Suchtext zu 2–80 Literal-Tokens normalisieren und binden; keine Operatoren/Spaltenselektoren sowie keinen `LIKE '%…%'`-Fallback zulassen. Viewer liefert Plaintext-Abschnitte und strukturierte Trefferpositionen; Hervorhebung nur per DOM-Textknoten, nie `innerHTML`. Originalroute bleibt authentisiert, opaque, reviewed-only, mit kanonischer Root-/Symlink-/MIME-/Größenprüfung sowie `no-store`, `nosniff`, `no-referrer` und generischem Dateinamen. Bei vollständiger Browsermatrix Testprozesse mit prozesslokal bereinigten `HEALTH_DASHBOARD_*`-Variablen starten: aus einem vorigen Matrixlauf verbliebene synthetische Instance-/Inbox-Variablen können Legacy-Servertests korrekt fail-closed auslösen und sind kein Produktfehler. Detailvertrag und synthetische Testmuster: `references/dashboard-v5-health-record-document-search.md`. - Dashboard-UX und SIGHi-Mapping: Zusätzliche Karten, Accordions und Bottom-Navigation verbessern die wahrgenommene UX nicht, wenn alle Inhalte auf einer langen Seite bleiben. Für v5 task-orientierte echte Views und Progressive Disclosure verwenden. Für unbekannte Lebensmittel nur einfache exakte SIGHi-Einträge direkt mappen; Marken-/Mischprodukte benötigen Barcode/Zutaten, komponentenweise Quellenprüfung, Provenienz und manuellen Review. Queue-Identitäten nie über interpunktionslöschende Slugs bilden: einen domänenseparierten opaque Digest des exakten normalisierten Namens verwenden, Alias/Beispielname exakt binden, mehrere Rohbezeichnungen mit derselben Normalform fail-closed als mehrdeutig ablehnen und bestehende abweichende Klassifikationen nie überschreiben. `sighi_reference` serverseitig gegen eine lokale versionierte Regel samt exaktem Score prüfen und ausschließlich deren Provenienz persistieren; Client-Provenienz nicht übernehmen. Frischschema und Upgrade-DDL inklusive Defaults und CHECK-Constraints synthetisch vergleichen; nullable Histamin-Summarydefaults bei Upgrades per inhaltserhaltendem, idempotentem Rebuild migrieren. Die offizielle SIGHI-Quelle ist PDF-basiert, nicht als öffentliche strukturierte DB gefunden; Vollübernahme nicht ohne Lizenzklärung veröffentlichen. Informationsarchitektur/Mapping: `references/dashboard-v5-information-architecture-and-sighi-mapping.md`; sichere Parallel-Preview, Bundle-Vertrag, Worker-Aufteilung und Browser-Gates: `references/dashboard-v5-parallel-app-patterns.md`; adversariale Review-Findings und 4B-Eingangsgates: `references/dashboard-v5-review-and-advanced-explorer-gates.md`; konkrete Advanced-Explorer-Vertrags-, Scatter-, Lag-, Phasen- und Browsermuster: `references/dashboard-v5-advanced-explorer-contract.md`; sichere Tages-/Wochenaggregation, vollständige-Woche-Missingness, Nullerhalt, cadence-konsistenter Scatter, dynamische Presets, Ereignisspur und responsive Chart-Gates: `references/dashboard-v5-explorer-daily-weekly-patterns.md`; sichere mobile Erfassung via private Queue, explizite DB-Wahl, exakter Origin, immutable Zürich-Tagesvertrag und echter nativer POST: `references/private-mobile-health-capture.md`; Foundation für größere Dashboard-/Chart-Migrationen mit Legacy-Paritätsmatrix, ADR, lokal gepinntem default-off Synthetic-Prototyp, Accessibility-Tabelle und gestuften Gates: `references/dashboard-modernization-foundation.md`. - Dashboard-v5 Kalender-/Tagesrouter: Alle Einstiege (Chart, Ereignis, Labor, Kalender, Header, Heute, Deep Link und Browserhistorie) müssen einen einzigen strikt validierten Day-Router und denselben serverautoritativen Zürich-Tag verwenden. Browser-`new Date()` darf Gesundheitszeitfenster nicht verankern; nach dem gemeinsamen Session-Promise den aktuellen Serververtrag erneut lesen, weil ein generiertes HTML-Bundle altern kann. Das Feature bleibt generatorseitig default-off, erzeugt ohne Flag weder Markup/Assets noch Requests und teilt sich genau einen bestehenden Same-Origin-Session-Bootstrap. Day Contract additiv entwickeln und Legacy-Schlüssel bis zur nachgewiesenen Consumer-Migration erhalten; Null von Missing, geplant von verabreicht sowie persönliche Baseline von beobachtungsspezifischer Laborreferenz trennen. Kalenderabfragen werden per fester Range-Aggregation statt N vollständiger Tagesabfragen gebaut. Architektur, Mobile-/Keyboard-Gates, isolierte Browsermatrix und Release-Disziplin: `references/dashboard-v5-central-day-routing-patterns.md`. - V5-Kalender Apple-Health-Kanonisierung: Kalender und Day API müssen exakt denselben allowlist-gesteuerten Apple-Pfad verwenden: reale Quelle `apple_health_records.start_date`, nur `APPLE_SOURCE_SPECS`/Metrikkatalog freigegeben. Tageszuordnung ausschließlich über die Analytics-Normalisierung (aware Timestamps → `Europe/Zurich`, naive ausdrücklich lokal); nie per `substr(start_date, 1, 10)` für UTC-/Offset-Zeitstempel. Nicht freigegebene Metriken dürfen weder Count/Kategorie im Kalender noch Messwert im Day Contract erzeugen. Regressionen müssen UTC-nahe Mitternacht, mindestens eine DST-Grenze sowie Kalender↔Day-Konsistenz abdecken. Für `arztbesuche` ohne explizites Statusfeld keinen Besuch aus vergangenem Datum als `occurred` ableiten: neutral `documented_visit` oder `status_unknown`; explizite Statuswerte nur aus einer belegten Quellenspalte. Deep Links mit dupliziertem `view` oder `date` ablehnen bzw. eindeutig kanonisieren. - Health Sprint-0 Safety: GOG-Keyring-Credentials niemals als Default im Code führen; **alle** GOG-Consumer per statischem Scan inventarisieren (inkl. Cron-, Gmail-, Drive-, Briefing-, Backup- und Report-Skripte), nur Runtime-Environment oder `~/.hermes/secrets/gog_keyring.env` nutzen und vor dem Subprozess bei fehlendem/leerem Secret fail-closed abbrechen. Ein Apple-Health-Dateiimport muss Records, Erfolgsmarker und `--move`-Archivierung als atomaren Ablauf behandeln: Archivfehler vor Commit, vollständiger Rollback, Datei bei Commitfehler zurückstellen und separater retrybarer `status='error'`; nur `status='imported'` gilt als abgeschlossen. Nur die erwartete `record_hash`-UNIQUE-Kollision darf übersprungen werden, andere `IntegrityError` müssen den Gesamtimport zurückrollen. Bereits bekannte Inbox-Dateien bei `--move` kontrolliert archivieren. Labor-Referenzgrenzen aus TEXT-Spalten müssen nichtleer **und numerisch parsebar** sein; `IS NOT NULL` allein reicht nicht. Regressionstests: `tests/test_sprint0_safety.py` im HealthManager-Repo. Release erst nach wiederholtem unabhängigen Spec-/Medical-Safety-Review, Runtime-Hashabgleich, realer PDF-/Drive-/HTTP-Verifikation und Privacy-/Secret-Scan. Vollständiger Workflow: `references/health-sprint0-safety-hardening.md`; wiederverwendbare Prüfmuster: `references/sprint0-safety-patterns.md`. - Arztbericht/PDF: `scripts/generate_doctor_report.py` erzeugt `reports/arztbericht_aktuell.pdf` im Querformat mit automatischem Tabellen-Zeilenumbruch, neutralen Apple-Health-Verlaufsgrafiken und einer klaren Grenze zur ärztlichen Interpretation. Keine automatischen medizinischen KPI-Ampeln, grünen Entwarnungszustände, festen Laborgrenzen oder zusammengesetzten „Health Index“-Scores. Laborwerte nur bei `validiert`, Originalprüfung, `scanned_original`, Einheit und dokumentbezogener Referenzgrenze; Vergleichsoperatoren sichtbar erhalten. Es lädt das PDF in Google Drive Ordner `Gesundheitsberichte` (`1oVpcbpelbt2IwHL9oGw9QTi2haQL63-v`) hoch und schreibt `reports/arztbericht_drive_link.json`. `abnahme_datum`/`befund_datum` verwenden; `ermittlung_datum` ist Import-/OCR-Zeitstempel und darf nicht als medizinisches Datum angezeigt werden. Nach PDF-Änderungen real erzeugen, erste Seite rasterisieren und auf Lesbarkeit, Überlappung, neutrale Farben und sichtbaren Safety-Disclaimer prüfen. Dashboard v3.1 zeigt lokale PDF- und Drive-Links sowie Apple-Health-Module für Schritte, Distanz, Ruhepuls, HRV, Schlaf, SpO₂, Atemfrequenz, Aktivität, Physical Effort und Gewicht. - Apple Health Auto Export: Für die iPhone-App `Health Auto Export - JSON + CSV` bevorzugt **Google Drive + JSON**. Zielordner: `Gesundheitsdaten Inbox / Apple Health Auto Export` (`1T2kpxRyRyH8mSknXm85RRNFFfex61iWQ`). Lokale Inbox: `inbox/apple_health_exports/`. Import-Skripte: `scripts/apple_health_import.py` und `scripts/apple_health_drive_sync.py`. Details: `references/apple-health-auto-export.md`. - `scripts/generate_labor_report.py` ist nur noch ein Kompatibilitäts-Wrapper für `health_pipeline.py generate-lab-report`. - `reports/aktuelle_blutwerte.xlsx` wird im gewünschten Pivot-Format erzeugt: eine Spalte pro Untersuchung/Datum, eine Zeile pro Parameter. Die aktuellste Referenz-XLSX aus `inbox/260510_Laborwerte_Uebersicht.xlsx` wird bevorzugt, weil sie Datums-Spalten bis `2026-05-07` enthält. - Dashboard: `reports/health_dashboard.html`. - **V5-Kalender-/Day-Sichtbarkeit prüfen:** Eine erfolgreiche DB-Erfassung beweist nicht die Darstellung. Nach manuellen Telegram-Symptomen zusätzlich `/api/v1/calendar` und `/api/v1/day/YYYY-MM-DD` gegen die produktive read-only DB prüfen. `symptom_log`-Einträge außerhalb `daily_quick_score` müssen als zusätzliche Symptome erscheinen; ein zu langer oder aus Privacy-Gründen verworfener optionaler Event-Notiztext darf den sicheren Event-Titel nicht aus dem Day Contract entfernen. V5 danach mit dem aktivierten Feature-Flag neu erzeugen und den Dienst neu starten; Runtime-Dateihashes, HTTP-200/`no-store`, Kalenderkategorien und Day-Labels verifizieren. - Workflow-Dokumentation: `reports/health_intelligence_workflow.md`. - Google Drive Korrektur-Ordner: `Gesundheitsdaten Korrektur` (`18wPP6yHjdp8XShhue7OZcamcqc09ec9g`). - Cron Scripts: `~/.hermes/scripts/health_daily_sync.py` (täglich 23:10), `~/.hermes/scripts/yazio_sync.py` (YAZIO-Ernährungsimport täglich 23:15, Job `b9eb80891aa4`), `~/.hermes/scripts/health_weekly_report.py` (sonntags 18:00) und `~/.hermes/scripts/weekly_health_drive_backup.py` (verschlüsseltes Health/Hermes-Backup sonntags 23:55, Job `04918ca83019`). Alter fehlerhafter Inbox-Cron `e2150e5d908d` ist pausiert; neue Jobs: `2bf4d0a8bedb`, `e9b6fe32c177`. YAZIO-Sync schreibt idempotent in `ernaehrung` und `tagebuch`, prüft heute und gestern und bleibt still, wenn nichts geändert wurde. **Dashboard-Freshness-Pitfall:** Separate no-agent Syncs wie Apple Health (`bdc03626e17f`) und YAZIO (`b9eb80891aa4`) können Daten erfolgreich importieren, ohne dass `reports/health_dashboard.html` frisch gerendert ist. Bei Beschwerden wie „Dashboard letzte Daten vom …“ immer DB-Max-Daten (`apple_health_records.start_date`, `ernaehrung.datum`, `laborwerte.abnahme_datum`), Dashboard-`mtime` und Cron-Output vergleichen. Wenn Daten neuer als Dashboard sind, `python3.12 ~/.hermes/assets/Gesundheit/scripts/health_pipeline.py dashboard` ausführen und die jeweiligen Sync-Skripte so patchen, dass sie bei `inserted/changed > 0` danach das Dashboard regenerieren; heruntergeladene, aber bereits vollständig importierte Dateien allein müssen nicht neu rendern. Weekly Backup nutzt GPG AES256 mit Passphrase-Datei `~/.hermes/backup_keys/health_weekly_gpg_passphrase.txt`, Google-Drive-Ordner `Hermes_Health_Backups` (`1dlFpkKYXOCKaausFfVVnBK-qk3hFHA8T`), enthält Health-DB/Schema/Skripte, Hermes-Quick-Backup, Skills/Skripte und schliesst PDFs/Bilder/Rohdokumente aus. GitHub-Codebackup: privates Repo `https://github.com/Gamexgit/HealthManager`, lokale Arbeitskopie `~/.hermes/repos/HealthManager`, Initial-Commit `b65ab3cea044273033ff4e5185e78cf849dcd154`; enthält nur Code/Skripte/Doku/Schema ohne Daten, keine PDFs/DB/Credentials. GitHub Token/Repo-Link liegen in Google Sheet `Github_token` (`1-I7s9PazhYfYWrYQMwkSviJDk13a8qnAMRueAznD8Rs`) und dürfen nicht in Chat/Repo ausgegeben werden. ## Support Files - `references/secure-document-intake-and-medical-review.md` — sicherer lokaler Dokumentupload mit Quarantäne-/Magic-Byte-/Symlink-Gates, versionierter PDF-/OCR-Extraktion, medizinischem Kandidaten-Staging, Review-Queue, reviewed-first Suche und Copy-first V5-Release. - `references/guided-document-reconciliation-and-transfer.md` — geführte Entscheidungskategorien statt Inventarzähler, sichere Dubletten-/Wiederholungserkennung, DB-/XLSX-Abgleich, revisionsgebundene Übernahmevorschau, idempotenter Workertransfer, mobile UX und private Releasegates. - `references/drive-workflow.md` — Google Drive Befehle, Folder-IDs, Upload/Download-Workflow - `references/gog-email-attachments.md` — GOG Gmail Attachment-Download, Umbenennung langer Dateinamen, Dokumenten-Verarbeitung - `references/friday-db-schema-compat.md` — FRIDAY-Schema-Kompatibilität, Debugging-Checkliste, Wert-Konvertierung - `references/health-manager-pitfalls.md` — Häufige Bugs: Variable Shadowing, CHECK-Constraints, Watchdog-Management, FRIDAY-Kompatibilität - `references/document-classification.md` — Arztbericht vs. Laborbericht Klassifizierung, Quick-Decision-Tree - `references/labor-report-generation.md` — Laborbericht-Erstellung aus XLSX, Pivot-Tabellen, Kategorien-Struktur, `ermittlung_datum`-Pitfall - `references/adalimumab-vaccine-forum-research.md` — Patient-centered Adalimumab/Hyrimoz forum-research workflow: infection anecdotes, vaccine timing, critical-source synthesis, and practical clinician-question checklist - `references/doctor-report-vaccination-analysis.md` — Workflow für Arztbericht-Ablage plus statistische Schaden/Nutzen-Analyse von Impfempfehlungen vor/parallel zu Immunsuppression/TNF-Blockern - `references/impfausweis-hbv-review.md` — Impfausweis-Fotos archivieren, manuell transkribieren und HBV-Marker korrekt einordnen; wichtige Pitfalls: HIB ≠ Hepatitis B, HBsAg positiv ≠ geimpft, Anti-HBs positiv = Impfschutz/Immunität. - `references/lipid-lab-import-and-trend-review.md` — Labor-PDF-Import mit 2-Pass-Validierung, Dashboard-XLSX-Aktualisierung und lesbare Lipid-/Triglycerid-Trendanalysen - `references/ksb-multicolumn-lab-pdf-import.md` — KSB-Labor-PDFs mit mehreren Ergebnis-Spalten sicher importieren: pdfplumber-Spaltenprüfung, visuelle Zweitprüfung, `dokumente`/`laborwerte`-Eintrag, Referenz-XLSX/Dashboard-Update und Drive-Link. - `references/yazio-nutrition-dashboard-workflow.md` — YAZIO Backfill/Sync, normalisierte Nutrition-Tabellen, Histamin/SIGHi-Ampel, Meal Explorer Dashboard, Cron-Kompatibilität und Verifikationscheckliste. - `references/dashboard-v5-nutrition-cockpit-safe-migrations.md` — explizite idempotente Patient-Action-Migration vor echten Aktionen, SQLite-Backup-/Copy-/Restore-Gates, fail-closed Nährstoffnormalisierung und Missingness, Histamin-Zuordnungsindex, Nutrition-URL/History sowie fokussierte private Release-Smokes. - `references/local-nutrient-references-and-secure-dashboard-actions.md` — lokale versionierte BLV-/Public-Health-Snapshots, fail-closed Profil-/Lebensphasenauflösung, per-Nährstoff-Nenner, sichere Session/Origin/CSRF-Actions, post-Worker-Idempotenz, Browser-Katalog-Deduplizierung und private Releasegates. - `references/sprint0-safety-patterns.md` — wiederverwendbare Safety-Härtung für atomare Apple-Health-Imports, sichere Laborautomation/Arztberichte, GOG-Credentials, visuelle PDF-QA und Release-Gates. - `references/apple-health-analytics-v2-patterns.md` — sichere Apple-Health-Kanonisierung: Zürich-Lokaltage, direkte-vor-coarse Auflösung, Quellenpriorität, metric-aware Aggregation/Coverage, TDD und Runtime-Release-Gates. - `references/multimodal-health-correlation-safety.md` — sichere multimodale Hypothesenschicht mit Rohzeilen-vor-Parsing-Duplikatregeln, strikt parsebaren Labordaten, kalenderbewussten Teilblock-Permutationen, `n=0`-/Coverage-Vertrag, vollständigen Dashboard-Kalenderachsen, Defense-in-depth-Persistenzinvarianten, Legacy-sicheren Migrationen und unabhängigen Release-Gates. - `references/privacy-hardened-health-dashboard.md` — wiederverwendbares Dashboard-v4-Muster für vollständigen Renderer-Erhalt, lokale gepinnte Assets, nonce-basierte CSP, CSRF-geschützte Touch-Eingabe, Missingness-/Baseline-/Overlay-Safety, Accessibility-Browserchecks, side-effect-freie Produktions-Smokes, Worker-Recovery und Release-Gates. - `references/dashboard-v5-information-architecture-and-sighi-mapping.md` — task-orientierte Dashboard-v5-Informationsarchitektur, UX-Usability-Gates sowie sichere, provenienz- und lizenzbewusste SIGHi-/Produktmapping-Strategie. - `references/dashboard-v5-parallel-app-patterns.md` — sichere parallele Dashboard-App-Evolution mit versioniertem Bundle, read-only Provider, Worker-Aufteilung, DOM-Vertrag, synthetischen Fixtures und Browser-/Release-Gates. - `references/dashboard-v5-review-and-advanced-explorer-gates.md` — adversariale Medical-/Privacy-/UX-Reviewmuster: Kanonisierung-vor-Parsing, fail-closed DB-Injektion, Bundle-Budgets, reproduzierbare Browsermatrix und enge Post-Fix-Approvals. - `references/dashboard-v5-advanced-explorer-contract.md` — detaillierter Raw-/Index-/Scatter-/Lag-/Phasenvertrag und synthetische Verifikationsmuster. - `references/dashboard-v5-explorer-daily-weekly-patterns.md` — kanonische Registry-/Preset-Grenzen, sichere vollständige-Woche-Aggregation und Nullerhalt, cadence-konsistenter Scatter, chart-identische Tages-/Wochen-Ereignisachsen, fail-closed Lag-/Phasen-Scope, deterministische Fixtures/HTML sowie Mobile-/200-%-Text-Chart-Gates. - `references/private-mobile-health-capture.md` — sichere mobile Beschwerdeerfassung über private Action Queue: explizite DB-Ziele ohne Produktionsfallback, Defense-in-depth-Validierung, exakter HTTP-Origin, `strict-origin`, Einmal-Receipts, unveränderlicher Zürich-Tag, echte native Browser-POSTs und adversariale Release-Re-Reviews. - `references/parallel-health-dashboard-deployment.md` — sichere Preview-Veröffentlichung neben v4: getrennte Freigaben, sichere lokale Git-Authentisierung, Interpreter-/Transitivimport-Preflight, Staging-vor-Runtime, atomare Dateiersetzung mit verifiziertem Rollback, User-/Systemd- und tatsächliche Socket-Prüfung, Tailnet-/HTTP-Verifikationsgrenzen, explizite DB-Injektion sowie Route-/Hash-/DB-Gates. - `references/dashboard-v5-desktop-first-evolution.md` — Desktop-first Weiterentwicklung eines sicheren Health-Dashboard-Prototyps: Live-UI-Audit, read-only Produktionsmapping, fail-closed und medikationsspezifische Plan-/Stornosemantik, harte Zukunftsgrenze, gap-aware Long-Span-Charts, zeitlich exakte Ereignisanker mit zugänglichen Detailtexten, 200-%-Text-/Keyboard-Navigation, kanonische ASCII-Laborverträge, synthetische Browser-Sentinels, evidenzpflichtige Working-Tree-Reviews, Today-/Cockpit-Fallbacks und Linux-/iPhone-Release-Gates. - `references/dashboard-modernization-foundation.md` — Class-level Fundament für sensible Dashboardmodernisierung: Legacy→Ziel-Paritätsmatrix, Chart-Engine-ADR, lokal gepinnter und standardmäßig deaktivierter Synthetic-Prototyp, Canvas/ARIA/Datentabelle, Architekturmodule, gestufte Testpyramide und Delegations-/Releasegrenzen. - `references/dashboard-v5-central-day-routing-patterns.md` — serverautoritatives Zürich-`today`, zentraler Day-Router für Chart/Kalender/Deep-Link/History, Day-Contract-Missingness und Medikament-/Laborsemantik, begrenzte Kalenderaggregation sowie synthetische Mobile-/Browser-Release-Gates. - `references/sensitive-read-only-health-api-patterns.md` — evidenzgebundener Metrikkatalog und sichere read-only Gesundheitsdaten-API mit Bearer-/DB-Fail-closed-Gates, festen SQL-/Query-Allowlists, Source-/Response-Limits, Blutdruck-/Laborsemantik, Such-Redaction, synthetischen Slices und finalen RC-Reviews. - `references/dashboard-v5-patient-workflows-linked-explorer.md` — wiederverwendbarer V5-Vertrag für getrennte Browser-/API-Authentifizierung, sicheren Nutrition-Day, fehlertoleranten gekoppelten Multi-Grid-Explorer, Inbox-/Worker-Patientenaktionen, neutrale Arzt-Zusammenfassung und ein enges privates Releasegate. - `references/health-dashboard-cross-cutting-implementation-path-mapping.md` — read-only Methode für kleinste sprintübergreifende Implementierungspfade: sichtbare Panelbezeichnungen, ehrliche Ernährungsdurchschnitte samt Nenner, drei öffentliche Referenzkontexte, geplante versus tatsächliche Supplemente sowie allowlist-gesteuerte Arztbericht-Chartauswahl mit exakten Code-/Schema-/Testtouchpoints. - `references/dashboard-v5-temporal-association-explorer.md` — read-only Arbeitsbereich „Zusammenhänge“ mit allowlist-gesteuertem Spearman-/Ereignisvertrag, Zürich-Lags, URL-/History-Restore, gekoppelten ECharts/Scatter/Heatmap/Ereignisfenstern, sitzungsbezogener Arzt-Zusammenfassung und fokussiertem Real-Data-Smoke ohne Kausalitätsaussage. - `references/dashboard-v5-visual-explorer-and-doctor-summary.md` — visueller Multi-Metrik-Arbeitsbereich mit gekoppelten ECharts-Multi-Grids, expliziten Overlay-/Baselinegrenzen, Low-data-Zusammenhängen, sessionbasierter Grafikübernahme, A4-Druck, 390-px-/Accessibility-Pitfalls und engem privatem Release-Smoke. - `references/dashboard-v5-personal-observation-plans.md` — class-level Vertrag für persönliche Fragestellungen und N-of-1-Lernschleifen: additive/immutable Ergebnisversionen, kanonische Allowlist, Action-Inbox-Statusübergänge, Low-data-Regeln, echte mobile Drill-downs, ECharts-Pointertests sowie copy-first private Release-Smokes ohne Patientenaktion. - `references/trusted-health-reference-enrichment-and-reconciliation.md` — class-level Vertrag für getrennte Labor-/Baseline-/Ernährungsreferenzen, geplante versus tatsächliche Supplemente, BLV/YAZIO-Enrichment ohne Überschreiben, lokale Textlayer-/OCR-Pipeline, fail-closed Labor-XLSX-Reconciliation, fokussierte Browsergates und resumierbare Zwei-Commit-Private-Releases. - `references/labor-source-reconciliation-and-private-release.md` — class-level Workflow für read-only V4/Excel↔SQLite↔V5-Abgleich, kanonische Laborhistorien, getrennte Dokumentprovenienz, exakte Linkbackfills, synthetische Regressionen und private V5-only Releases bei byteidentischem V4. ## Google Drive Integration ### Drive-Ordner-Struktur - **Gesundheitsdaten Inbox** (Upload-Ort): `1HOJXzIjJaUUoLGZgJjAR5V6ZCsOBsGgE` - **Archiv** (Verarbeitete Dokumente): `1H2zXafzbaRobY8XDcPyRpZBE6mXeTcJe` ### Drive-Workflow: Neue Dokumente aus Google Drive Inbox verarbeiten 1. **Inbox prüfen:** `gog -a friday.uplink@gmail.com drive ls --parent --json` 2. **Neue Dateien identifizieren** (nicht im lokalen Archiv vorhanden) 3. **Download:** `gog -a friday.uplink@gmail.com drive download ` 4. **Lokale Kopie** nach `~/.hermes/assets/Gesundheit/inbox/` verschieben 5. **Dokument klassifizieren** (Arztbericht vs. Laborbericht) 6. **Text extrahieren** (PyMuPDF für PDFs, Camelot für Labor-Tabellen) 7. **Datenbank aktualisieren** (laborwerte, health_events, dokumente) 8. **Datei ins lokale Archiv** verschieben 9. **Datei ins Google Drive Archiv** hochladen: `gog -a friday.uplink@gmail.com drive upload --parent ` 10. **Datei aus Inbox löschen** (optional: `gog drive delete `) 11. **Benachrichtigung** an den User über die Erkenntnisse ### Pitfalls - **KSB-Labor-PDFs mit mehreren Datumsspalten:** PyMuPDF-Text kann Tabellenwerte über Spalten hinweg flatten/interleaven. Für Import eines konkreten Abnahmedatums zuerst `pdfplumber.extract_tables()` zur Spaltenzuordnung verwenden und danach die relevante PDF-Seite als Bild visuell gegenprüfen. Nach DB-Insert zusätzlich die aktive Referenz-XLSX aktualisieren, weil Dashboard v3 Labortrends aus `parse_reference_xlsx()` liest; dann `health_pipeline.py generate-lab-report` und `health_pipeline.py dashboard` ausführen. Details: `references/ksb-multicolumn-lab-pdf-import.md`. - **`gog gmail attachment --output `** — korrekter Befehl zum Herunterladen von E-Mail-Anhängen. Die Attachment-ID ist NICHT die Drive-Datei-ID. - **`--parent `** statt `--folder` Flag verwenden (Flag `--folder` existiert NICHT) - **`gog drive move`** verwendet `--parent `, NICHT `--to` oder `--id` - **`--json`** Flag für parsebare JSON-Ausgabe - Drive-Download speichert in `~/.config/gogcli/` mit GENERIERTEM Dateinamen — Datei muss manuell umbenannt und verschoben werden - **`gog drive download`** ohne Parameter zeigt nur Root-Ordner — immer `--parent` mit Folder-ID verwenden - OCR bei reinen Bild-PDFs (scanned): Tesseract PSM=6 für tabellarische Daten, aber viele Werte können im PDF selbst obscured sein — prüfen ob Werte lesbar bevor man OCR durchführt - Python-Pakete (fitz, pytesseract) liegen in `~/.local/lib/python3.12/site-packages`, NICHT im hermes-agent venv - FRIDAY wird NICHT mehr für Gesundheitsdaten verwendet — alles JARVIS - `backup_original/` enthält alle Originaldateien - Werte `'<5.0'` etc. müssen vor numerischen Operationen geparsed werden (`lstrip('<>=')`) - Datenbank-INSERTs prüfen CHECK-Constraints: `status` muss `'neu'`, `'eingearbeitet'` oder `'archiviert'` sein; `daten_typ` muss `'pdf'` oder `'image'` sein - Watchdog-Daemon unzuverlässig → manuelle Verarbeitung mit `health_manager.process_inbox_pdf()` bevorzugen - **`.xlsx` Dateien:** Mit `openpyxl` lesen, als Volltext in Datenbank speichern (keine Laborwerte!) - **Laborbericht-Erstellung / Provenienz:** Pivot-Übersichten dürfen aus der XLSX-Arbeitsmatrix erzeugt werden, aber die kanonische Quelle für Laborwerte und Referenzbereiche ist immer der eingescannte Original-Laborbericht des jeweiligen Untersuches. Die XLSX ist sekundär und kann Fehler enthalten; vor klinischer Nutzung oder Import-Korrekturen immer gegen den Originalscan validieren. `ermittlung_datum` in der DB ist OCR-/Importdatum, nicht tatsächliches Abnahmedatum. - Immer Dokumentendatum innerhalb des Dokuments extrahieren und im Text annotieren: `[DOKUMENTDATUM: YYYY-MM-DD]` - **STT für Sprachnachrichten:** faster-whisper mit `medium` Modell, Sprache `de`. Installation via `uv pip install`. Gateway restart nach Config-Änderungen. Schweizerdeutsch wird NICHT unterstützt. - **Tagebuch-Workflow:** User sendet Einträge per Telegram (#ernaehrung, #symptom, etc.). Unstrukturierte Eingabe — Agent extrahiert automatisch Datum, Kategorie, Inhalt.