Policy version 1.37.12
Datenschutzerklärung / Privacy Policy
Last updated: 2026-08-11 · Stand: 2026-08-11
Diese Erklärung ist deutsch-englisch geführt. Jeder Abschnitt beginnt mit dem deutschen Text; die englische Übersetzung steht eingeklappt direkt darunter.
Inhalt / Contents
1. Overview
Deutsch — Überblick
HealthLog ist eine quelloffene, selbst-hostbare Anwendung zur persönlichen Gesundheitsprotokollierung. Der Quellcode wird unter der PolyForm Noncommercial License 1.0.0 auf github.com/MBombeck/HealthLog veröffentlicht. Diese Erklärung beschreibt, wie die Instanz, über die Sie diese Seite abrufen, und die zugehörige iOS-Anwendung HealthLog for iOS (Bundle-ID dev.healthlog.app) personenbezogene Daten verarbeiten.
Verantwortlicher im Sinne von Art. 4 Nr. 7 DSGVO ist der Betreiber dieser Instanz (Privatperson mit Sitz in Deutschland). Eigenständig betriebene, selbst-gehostete Instanzen unterliegen der Datenschutzerklärung ihres jeweiligen Betreibers; dieses Dokument gilt ausschließlich für diese Instanz.
Für Fragen oder Datenschutz-Anfragen siehe Abschnitt 11 (Kontakt).
English translation
HealthLog is an open-source, self-hostable personal-health- tracking application. Source code is published at github.com/MBombeck/HealthLog under the PolyForm Noncommercial License 1.0.0. This policy describes how the instance serving this page and the companion iOS application HealthLog for iOS (bundle identifier dev.healthlog.app) handle personal data.
The controller under Art. 4 (7) GDPR is the operator of this instance (an individual based in Germany). Self- hosted deployments controlled by a different operator are governed by that operator's own privacy policy; this document applies only to this instance.
For questions or data-subject requests, see section 11 (Contact).
2. Data we collect
Deutsch — Erhobene Daten
HealthLog speichert Beobachtungen, die der Nutzer selbst erfasst, sowie Gesundheitssignale, die der Nutzer ausdrücklich über eine Integration verbunden hat. Die folgenden Kategorien sind für den veröffentlichten Funktionsumfang abschließend.
2.1 Konto und Authentifizierung
- Anzeigename und E-Mail-Adresse; optional ein vom Nutzer ausgewähltes Profilbild.
- Passwort-Hash (Argon2id; das Klartext-Passwort wird zu keinem Zeitpunkt gespeichert oder protokolliert).
- Optional: WebAuthn- / Passkey-Anmeldedaten (öffentlicher Schlüssel, Credential-ID, Signaturzähler).
- Sitzungskennungen (HTTP-only-Cookie im Web; opake API- Token unter iOS, gespeichert im Geräte-Keychain).
- Profil-Metadaten: Sprache, Zeitzone, Geburtsdatum (optional), biologisches Geschlecht (optional), Körper- größe (optional) — zur Berechnung altersgerechter Zielbereiche und des BMI.
2.2 Manuell erfasste Gesundheitsdaten
Jeder in den App-Formularen eingegebene Wert, einschließ- lich Zeitstempel, optionaler Notiz und Metrik-Typ. Die vollständige Aufzählung der unterstützten Metriken steht im OpenAPI-Schema; die nutzerrelevante Teilmenge umfasst Körpergewicht, Körperfett, Körpertemperatur, BMI (abgeleitet), Blutdruck (systolisch / diastolisch) und Puls (gepaarte Messung), Blutzucker mit Kontext (nüchtern / postprandial / zufällig / vor dem Schlafengehen) und wählbarer Einheit (mg/dL oder mmol/L), Ruhepuls, HRV (SDNN), VO₂max, Sauerstoffsättigung, Schlafdauer inkl. Pro- Stadien-Aufschlüsselung (Wach / REM / Core / Tief), Schritte, gelaufene oder gerannte Distanz, Aktive-Energie, gestiegene Stockwerke, Lärmpegel (Umgebung und Kopfhörer), Tageslicht-Zeit, Stimmung (Skala 1–5) mit optionaler Freitext-Notiz sowie Workouts (Sportart, Dauer, Distanz und optional GPS-Route, ausschließlich wenn der Nutzer eine Route anhängt).
2.3 Apple Health (iOS-Anwendung) — Datenfluss
Wenn der Nutzer der iOS-Anwendung Lesezugriff auf Apple HealthKit erteilt, liest HealthLog Stichproben der unten aufgeführten Identifier. Apple Health verwaltet HealthKit-Daten auf dem Gerät und kann sie nach den Apple-Einstellungen des Nutzers über dessen Apple-Konto synchronisieren. Das ist Apple-seitiges HealthKit-Verhalten und keine iCloud- oder CloudKit-Speicherung durch HealthLog. Die iOS-Anwendung überträgt relevante Stichproben über HTTPS (TLS 1.3, Zertifikat-Pinning) an den HealthLog-Server (Endpunkt POST /api/measurements), damit die Web-Oberfläche dieselben Verläufe darstellen kann wie das iPhone. HealthLog synchronisiert dabei die unterstützte Standarddarstellung der Herzfrequenz für Trends und Workout-Kontext. Das interne Experiment für einen ungefilterten Roh-Herzfrequenzstrom ist in dieser öffentlichen Version nicht verfügbar und wird nicht beworben oder erhoben. Eine Weitergabe an einen KI-Anbieter erfolgt nur über die separat aktivierten und eingewilligten Pfade in Abschnitt 2.7.
HKQuantityTypeIdentifier:
bodyMassbodyFatPercentagebodyTemperaturebloodPressureSystolicbloodPressureDiastolicbloodGlucoseoxygenSaturationheartRaterestingHeartRateheartRateVariabilitySDNNvo2MaxstepCountactiveEnergyBurnedflightsClimbeddistanceWalkingRunningenvironmentalAudioExposureheadphoneAudioExposuretimeInDaylight(iOS 17+)
HKCategoryTypeIdentifier:
sleepAnalysis— mit voller Pro-Stadien-Granularität (Awake, REM, Core, Deep). Die Stadien werden serverseitig als separate Zeilen abgelegt, damit das Diagramm sie stapeln kann.
Schreibzugriff wird für eine Teilmenge angefordert (Körpermasse, Blutdruck systolisch / diastolisch, Blut- zucker), damit manuelle Einträge in der iOS-App zurück nach HealthKit fließen können. Der Nutzer steuert beide Richtungen über die Berechtigungsoberfläche der iOS- Health-App und kann jederzeit widerrufen.
2.4 Withings-Synchronisation (optional)
Verbindet der Nutzer ein Withings-Konto, speichert HealthLog die OAuth-Refresh- und -Access-Token (spalten- weise verschlüsselt) sowie die Withings-Nutzerkennung. Webhook-getriebene Folgesynchronisierungen ziehen Körper- gewicht, Fettanteil, fettfreie Masse, Muskelmasse, Knochenmasse, Wassergehalt, Magermasse, Hydration, Blutdruck (systolisch / diastolisch) und Puls, Blut- zucker, Körpertemperatur (Basal- und Hauttemperatur), Aktivitätssummen (Schritte, Distanz, aktive Kalorien), Schlafsitzungen mit Pro-Stadien-Segmenten (Awake / Light / Deep / REM) sowie SpO₂ und Herzfrequenzvariabilität, soweit vorhanden.
2.5 Medikamente
- Aktive Verordnungen: Wirkstoffname, Stärke, Verabreich- ungsweg, Einnahmeplan, Behandlungsklasse (Standard oder GLP-1).
- Einnahme-Ereignisse: geplante Zeit, tatsächliche Zeit, Status (eingenommen, ausgelassen, verpasst).
- Bei GLP-1-Therapien: Dosis-Änderungs-Historie, Injektions- Ereignisse mit optionaler Injektionsstelle und Pen- Kennung, Nebenwirkungs-Protokolle entlang einer fixen Taxonomie, Pen-und-Ampullen-Inventar mit 30-Tage-In- Use-Uhr.
2.6 Dokumente, Scans und lokale Texterkennung
Ein Profilbild sowie für den Dokumententresor ausdrücklich ausgewählte Fotos, Scans und PDFs werden zum HealthLog-Server hochgeladen und dem Konto zugeordnet. Beim Schnell-Erfassen von Medikamenten oder Laborwerten bleibt das Quellbild dagegen auf dem Gerät: Apple Vision erkennt Text lokal, und nur die vom Nutzer geprüften, bearbeiteten und bestätigten Zeilen werden an den Server gesendet. Das gilt nicht automatisch als Upload in den Dokumententresor.
2.7 KI-Pfade, Ziele und Einwilligung
Externe KI ist standardmäßig deaktiviert. Vor der ersten Übertragung nennt die App das konkrete Ziel und die Kategorien: die Frage oder Anweisung des Nutzers, Gesundheitskontext, jüngste Beobachtungen oder Aggregate, Zielbereiche und optional Medikamenten-, Labor- oder Dokumentkontext. Der Server normalisiert HealthKit-Daten; rohe HealthKit-Identifier und rohe Sample-IDs gehören nicht zum Coach-Snapshot.
- Server-verwaltet: Die Daten gehen zuerst an den konfigurierten HealthLog-Server und von dort an dessen eingerichtetes Anthropic-, OpenAI-, lokales, ChatGPT-OAuth- oder generisch OpenAI-kompatibles Ziel. Ein lokales oder generisches Ziel wird vom Betreiber festgelegt und kann einer eigenen Datenschutz- und Speicherrichtlinie unterliegen.
- Eigener Schlüssel (BYO): Das iPhone sendet direkt an OpenAI, Anthropic, Google Gemini oder einen vom Nutzer angegebenen HTTPS-Endpunkt mit OpenAI-kompatibler API. Der API-Schlüssel bleibt im iOS-Keychain und wird nicht an den HealthLog-Server gesendet.
- Auf dem Gerät: Apple Foundation Models und die lokale Texterkennung senden Bild, Prompt und Ergebnis an keinen Drittanbieter in der Cloud. Ein ausdrücklich gewählter Netzwerk-Endpunkt ist dagegen kein reiner On-Device-Pfad und wird vor Verwendung als Ziel angezeigt.
Bei Dokumenten können Vorschlag, Zusammenfassung und Index nach Einwilligung das gespeicherte Originalbild bzw. PDF oder den erkannten Text verarbeiten. Der Dokument-Chat sendet die Frage des Nutzers zusammen mit dem indexierten Kontext des gewählten Dokuments und streamt eine darauf gestützte Antwort zurück. Die Freigabe gilt nicht für andere Ziele. Unter Einstellungen → Assistent kann der Nutzer externe KI ausschalten oder den Anbieter wechseln; damit werden weitere Server-Anfragen blockiert. Beim BYO-Pfad entfernt der Widerruf zusätzlich Schlüssel und Freigabe für diesen Anbieter.
2.8 Einwilligungsnachweis (Consent Receipt)
Der Server hält für server-verwaltete KI einen kontogebundenen Einwilligungsnachweis mit Art, signiertem Zeitpunkt und Artefakt. Der aktuelle Status ist über GET /api/consent/ai/latest abrufbar. Ein Widerruf wird mit Zeitstempel festgehalten und blockiert zukünftige externe Verarbeitung. Diese Nachweise werden als Teil des Konto-Auditverlaufs aufbewahrt und bei der Konto-Löschung kaskadiert gelöscht; es gibt keinen belegten separaten festen Fünf-Jahres-Löschjob.
2.9 Geräte- und Integrations-Metadaten, Push
- Geräte-Kennung (zufällige UUID, clientseitig erzeugt und im iOS-Keychain gespeichert), übermittelt als
X-Device-Id-Header — für Mehrgeräte-Synchronisation und Miss- brauchsschutz. - Apple-Push-Notification-Service-(APNs)-Geräte-Token und Umgebung (sandbox / production), ausschließlich bei aktivierten Push-Benachrichtigungen.
- Telegram-Chat-Kennung — nur, wenn der Nutzer die optionale Telegram-Bot-Benachrichtigung verbunden hat.
2.10 Sicherheits- und Audit-Logs
- Authentifizierungs- und Konto-Ereignisse für Sicherheit, Missbrauchsschutz und Nachvollziehbarkeit. Die Instanz löscht Audit-Zeilen täglich nach ihrem konfigurierten Fenster; der Server-Standard beträgt 365 Tage und kann vom Betreiber geändert werden.
- Server- und Reverse-Proxy-Zugriffsprotokolle werden nur für Betrieb, Missbrauchsschutz und Fehlersuche benötigt und nach der aktiven Log-Rotation des Betreibers gelöscht. Diese Codebasis belegt kein festes 14-Tage-Fenster für die Produktions-Infrastruktur.
- Push-Zustellversuche aller aktivierten Kanäle enthalten Kanal, Ereignistyp, Ergebnis und Fehlerklasse, aber keinen Roh-Gesundheitswert. Ein täglicher Job löscht sie nach 90 Tagen.
2.11 Nicht erhobene Daten
- Keine Werbe-Identifier, Fingerprints oder anwendungs- übergreifenden Tracker.
- Keine Zahlungsdaten (es gibt keinen Bezahltarif).
- Keine fortlaufende Hintergrund-Standortermittlung — GPS-Routen nur, wenn der Nutzer sie einem Workout ausdrücklich beifügt.
- Keine Social-Network-Kennungen und kein Kontaktlisten- Abgleich.
- Keine clientseitigen Produkt-Analytics; die Instanz liefert kein Analytics-SDK aus.
English translation
HealthLog is designed to record observations the user enters themselves and to consume health signals the user has explicitly connected through a third-party integration. The categories below are exhaustive for the released feature set.
2.1 Account and authentication
- Display name and email address; optionally, a profile image selected by the user.
- Password hash (Argon2id; the plain-text password is never stored or logged).
- Optional WebAuthn / passkey credentials (public key, credential ID, sign counter).
- Session identifiers (HTTP-only cookie on the web; opaque API tokens on iOS, stored in the device Keychain).
- Profile metadata: locale, timezone, date of birth (optional), gender (optional, one of male, female or other), height (optional) — used to compute age-adjusted target ranges and BMI.
2.2 Manually entered health data
Any value entered through the in-app forms, including timestamp, optional note, and metric type: body weight, body-fat percentage, body temperature, BMI (derived), blood pressure (systolic / diastolic) and pulse rate as paired readings, blood glucose with context (fasting, postprandial, random, bedtime) and configurable unit (mg/dL or mmol/L), resting heart rate, heart-rate variability (SDNN), VO₂ max, oxygen saturation, sleep duration with per-stage breakdown (Awake / REM / Core / Deep), step count, distance walked or run, active-energy burned, flights climbed, environmental and headphone audio-exposure levels, time in daylight, mood (1-5 scale) with optional free-text note, and workout sessions (activity type, duration, distance, and an optional GPS route attached manually by the user).
2.3 Apple Health (iOS application) — data flow
When the user grants the iOS application read access to Apple HealthKit, HealthLog reads samples for the identifiers listed below. Apple Health manages HealthKit data on the device and may sync it through the user's Apple account according to Apple platform settings. That is Apple-managed HealthKit behaviour, not iCloud or CloudKit storage by HealthLog. The iOS application copies relevant samples to the HealthLog server over HTTPS (TLS 1.3, certificate pinning) via POST /api/measurements so the web surface can render the same trends as the iPhone. HealthLog syncs the supported default heart-rate representation used for trends and workout context. The internal unfiltered raw-heart-rate experiment is unavailable in this public build; it is neither advertised nor collected. Transit to an AI provider occurs only through the separately enabled and consented paths in section 2.7.
HKQuantityTypeIdentifier:
bodyMassbodyFatPercentagebodyTemperaturebloodPressureSystolicbloodPressureDiastolicbloodGlucoseoxygenSaturationheartRaterestingHeartRateheartRateVariabilitySDNNvo2MaxstepCountactiveEnergyBurnedflightsClimbeddistanceWalkingRunningenvironmentalAudioExposureheadphoneAudioExposuretimeInDaylight(iOS 17+)
HKCategoryTypeIdentifier:
sleepAnalysis— with full per-stage granularity (Awake, REM, Core, Deep). Stages are stored server-side as separate rows so the chart can stack them.
Write access is requested for a subset (body mass, blood- pressure systolic / diastolic, blood glucose) so that manual entries made inside the iOS app can flow back into HealthKit. The user controls both directions in the iOS Health app's permission surface and may revoke at any time.
2.4 Withings sync (optional)
When the user connects a Withings account, HealthLog stores the OAuth refresh and access tokens (encrypted at the column level) and the user's Withings identifier. Subsequent webhook-driven syncs pull body weight, fat ratio, fat-free mass, muscle mass, bone mass, water mass, lean mass, hydration, blood pressure (systolic / diastolic) and pulse, blood glucose readings, body temperature (basal and skin), activity totals (steps, distance, active calories), sleep sessions with per-stage segments (Awake / Light / Deep / REM), and SpO₂ + HRV where available.
2.5 Medications
- Active prescriptions: drug name, strength, route, schedule, treatment-class flag (standard or GLP-1).
- Intake events: scheduled time, actual time, status (taken, skipped, missed).
- For GLP-1 treatments: dose-change history, injection events with optional injection site and pen identifier, side-effect logs against a fixed taxonomy, pen-and-vial inventory with a 30-day in-use clock.
2.6 Documents, scans, and local text recognition
A profile image and photos, scans, or PDFs explicitly selected for the document vault are uploaded to the HealthLog server and linked to the account. Medication and lab quick-entry work differently: Apple Vision recognises text on the device, the source image is not uploaded, and only rows the user reviews, edits, and confirms are sent to the server. Quick entry does not automatically save the source image in the document vault.
2.7 AI paths, destinations, and consent
External AI is off by default. Before the first transmission, the app identifies the destination and categories: the user's question or instruction, health context, recent observations or aggregates, target ranges, and optional medication, lab, or document context. The server normalises HealthKit data; raw HealthKit identifiers and raw sample IDs are not part of a Coach snapshot.
- Server-managed:data first reaches the configured HealthLog server and is then sent to that server's configured Anthropic, OpenAI, local, ChatGPT OAuth, or generic OpenAI-compatible destination. A local or generic destination is chosen by the operator and may have its own privacy and retention policy.
- Bring your own key (BYO): the iPhone sends directly to OpenAI, Anthropic, Google Gemini, or a user-specified HTTPS OpenAI-compatible endpoint. The API key remains in the iOS Keychain and is not sent to the HealthLog server.
- On device: Apple Foundation Models and local text recognition do not send the image, prompt, or result to a third-party cloud provider. An explicitly selected network endpoint is not an on-device path and is identified before use.
For documents, suggest, summary, and index operations may process the stored original image or PDF, or recognised text, after consent. Per-document chat sends the user's question with indexed context from the selected document and streams a grounded answer back. Consent does not transfer to a different destination. The user can disable external AI or change the provider under Settings → Assistant; this blocks future server requests. For BYO, revocation also removes that provider's key and grant.
2.8 Consent receipt persistence
For server-managed AI, the server keeps an account-bound consent receipt with its kind, signed time, and artefact. The current state is available through GET /api/consent/ai/latest. Withdrawal is timestamped and blocks future external processing. Receipts remain part of the account audit trail and are cascade-deleted with the account; no separate fixed five-year cleanup job is evidenced by the server source.
2.9 Device and integration metadata, push
- A device identifier (random UUID generated client- side, stored in the iOS Keychain) sent as the
X-Device-Idrequest header — used for multi-device sync and abuse prevention. - Apple Push Notification service (APNs) device token and environment flag (sandbox / production), recorded only when the user enables push notifications.
- Telegram chat identifier — only when the user has explicitly connected the optional Telegram-bot notifier.
2.10 Security and audit
- Authentication and account events used for security, abuse prevention, and accountability. The instance removes audit rows daily according to its configured window; the server default is 365 days and the operator may change it.
- Server and reverse-proxy access logs are needed only for operations, abuse prevention, and debugging, and are removed under the operator's active log-rotation policy. This source tree does not evidence a fixed 14-day production window.
- Push-delivery attempts for every enabled channel store the channel, event type, result, and error class, but no raw health value. A daily job removes them after 90 days.
2.11 Data we do not collect
- No third-party advertising identifiers, fingerprints, or cross-app tracking.
- No payment information (the application has no paid tier).
- No precise background location (workouts only carry GPS when the user attaches a route).
- No social-network identifiers or contact-list scrapes.
- No third-party product analytics. The instance does not ship a client-side analytics SDK.
3. Why we collect each category
Deutsch — Zwecke der Verarbeitung
- Authentifizierungsdaten — Identifikation des Nutzers und Sicherung der Sitzung. Rechtsgrundlage: Art. 6 Abs. 1 lit. b DSGVO (Vertrags- erfüllung).
- Gesundheitsdaten — Darstellung von Verläufen, Berechnung der Zielwerte- Treue, Erzeugung des Coach-Snapshots auf Abruf. Rechts- grundlage: Art. 9 Abs. 2 lit. a DSGVO (ausdrückliche Einwilligung für Daten besonderer Kategorien).
- Coach-Snapshots — Erzeugung personalisierter schriftlicher Rückmeldungen. Das Bündel wird nur für die Dauer der Anfrage an den konfigurierten KI-Anbieter übertragen.
- Geräte-Daten — Push-Benachrichtigungen, Missbrauchsschutz, Mehrgeräte- Sitzungshygiene.
- Audit-Logs — Sicherheits-Forensik und Rate-Limit. Rechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse am sicheren Betrieb).
- Produkt-Analytics — werden nicht erhoben.
English translation
- Authentication data — identifying the user and securing the session. Legal basis: GDPR Art. 6 (1) (b) performance of contract.
- Health data — displaying trends, computing target adherence, generating the Coach context bundle when the user invokes it. Legal basis: GDPR Art. 9 (2) (a) explicit consent for special-category data.
- Coach context bundles — generating personalised written feedback. The bundle is transmitted to the configured AI provider for the duration of the request only.
- Device data — push notifications, abuse prevention, multi-device session hygiene.
- Audit logs — security-event tracing and rate-limiting. Legal basis: GDPR Art. 6 (1) (f) legitimate interest in operating the service securely.
- Product analytics — none collected.
4. Third-party sub-processors
Deutsch — Auftragsverarbeiter und Drittanbieter
Folgende benannte Anbieter können personenbezogene Daten für aktivierte Funktionen verarbeiten. Zusätzlich kann ein Betreiber oder BYO-Nutzer einen lokalen oder generischen HTTPS-Endpunkt mit OpenAI-kompatibler API festlegen. Für ein solches nutzer- oder betreiberdefiniertes Ziel gelten dessen eigene Angaben zu Verantwortlichkeit, Ort und Speicherdauer; deshalb ist die Liste nicht als abschließend für frei konfigurierbare Ziele zu verstehen.
Die englische Übersetzung enthält die detaillierte Auflistung pro Anbieter mit Rolle, übermittelten Daten, Speicherort und Link zur Datenschutzerklärung.
English translation
The named providers below may process personal data for enabled features. An operator or BYO user may also configure a local or generic HTTPS endpoint with an OpenAI-compatible API. That user- or operator-specified destination is governed by its own controller, location, and retention terms, so this list is not exhaustive for freely configurable destinations.
Anthropic, PBC
Rolle. KI-Coach- und Insights-Anbieter, wenn der Nutzer Anthropic Claude in den Einstellungen wählt.
Übermittelte Daten. Coach-Snapshot-Bündel (Gesundheits-Kontext) für die Dauer der Anfrage.
Speicherort. USA. Die Speicherdauer richtet sich nach dem für den verwendeten Anthropic-Zugang geltenden Vertrag und der verlinkten aktuellen Richtlinie.
Role. AI Coach and Insights provider when the user selects Anthropic Claude in settings.
Data transferred. Coach snapshot bundle (health-data context) for the duration of the request.
Storage. United States. Retention follows the contract and current linked policy applicable to the Anthropic access in use.
OpenAI, L.L.C.
Rolle. Alternativer KI-Coach- und Insights-Anbieter, wenn der Nutzer ein OpenAI-Modell wählt.
Übermittelte Daten. Coach-Snapshot-Bündel, gleiche Struktur wie bei Anthropic.
Speicherort. USA. Die Speicherdauer richtet sich nach dem für den verwendeten OpenAI- oder ChatGPT-OAuth-Zugang geltenden Vertrag und der verlinkten aktuellen Richtlinie.
Role. Alternative AI Coach and Insights provider when the user selects an OpenAI model in settings.
Data transferred. Coach snapshot bundle, same shape as the Anthropic variant.
Storage. United States. Retention follows the contract and current linked policy applicable to the OpenAI or ChatGPT OAuth access in use.
Google LLC
Rolle. Optionales direktes BYO-Ziel, wenn der Nutzer Google Gemini mit eigenem Schlüssel auswählt.
Übermittelte Daten. Nutzerfrage sowie der vor der Übertragung angezeigte Gesundheits-, Medikamenten-, Labor- oder Dokumentkontext.
Speicherort. Vom gewählten Google-Dienst abhängig. Speicherdauer und Region richten sich nach dem Gemini-Zugang des Nutzers und der verlinkten aktuellen Richtlinie.
Role. Optional direct BYO destination when the user selects Google Gemini with their own key.
Data transferred. User prompt and the health, medication, lab, or document context disclosed before transmission.
Storage. Depends on the selected Google service. Retention and region follow the user's Gemini access and the current linked policy.
Withings SAS
Rolle. Wearable-Synchronisation, wenn der Nutzer ein Withings-Konto verbindet.
Übermittelte Daten. OAuth-Refresh- und -Access-Token, Withings-Nutzerkennung, Webhook-Benachrichtigungen über neue Messungen.
Speicherort. Frankreich (Europäische Union).
Role. Wearable-device data sync when the user connects a Withings account.
Data transferred. OAuth refresh and access tokens, Withings user identifier, webhook notifications about new measurements.
Storage. France (European Union).
Apple, Inc.
Rolle. HealthKit (lokal auf dem Gerät) und Apple Push Notification service (APNs, bei aktivierten Benachrichtigungen).
Übermittelte Daten. HealthKit-Zugriff bleibt lokal. APNs empfängt Geräte-Token, Bundle-ID und Notification-Payload.
Speicherort. Apple verwaltet HealthKit-Daten nach den Apple-Konto- und Health-Einstellungen des Nutzers. Das ist keine iCloud- oder CloudKit-Speicherung durch HealthLog.
Role. Apple-managed HealthKit on the device and Apple Push Notification service (APNs) when notifications are enabled.
Data transferred. HealthKit access is local to the device. APNs receives a device token, the application bundle identifier, and the notification payload.
Storage. Apple manages HealthKit data under the user's Apple-account and Health settings. This is not iCloud or CloudKit storage by HealthLog.
Telegram FZ-LLC
Rolle. Optionaler Benachrichtigungskanal, wenn der Nutzer die Telegram-Bot-Integration verbindet.
Übermittelte Daten. Telegram-Chat-Kennung und Notification-Payload.
Speicherort. Vereinigte Arabische Emirate / globale Telegram-Infrastruktur.
Role. Optional notification channel when the user enables the Telegram-bot integration.
Data transferred. Telegram chat identifier and the notification payload.
Storage. United Arab Emirates / Telegram global infrastructure.
GitHub, Inc.
Rolle. Hosting des Open-Source-Repositories und Issue-Tracker als Support-Kanal.
Übermittelte Daten. Issue-Inhalte und freiwillige Anhänge. Bitte keine personenbezogenen Daten in öffentlichen Issues posten; nach der ersten Antwort wird ein privater Kanal angeboten.
Speicherort. USA.
Role. Hosting of the open-source repository and the issue tracker used as the support channel.
Data transferred. Issue contents and any voluntary attachments. Avoid posting personal data in public issues; the operator offers a private channel after the first response.
Storage. United States.
Cloudflare, Inc.
Rolle. Autoritative DNS-Auflösung für die Domain dieser Instanz. Die Anwendung selbst steht nicht hinter dem Cloudflare-Proxy.
Übermittelte Daten. Quell-IP und User-Agent zum Zeitpunkt der Auflösung.
Speicherort. USA; globales Anycast-Netz von Cloudflare.
Role. Authoritative DNS for this instance's domain. The application itself is not behind the Cloudflare proxy; only the DNS resolution path is.
Data transferred. Source IP address and user-agent at resolution time.
Storage. United States; Cloudflare's standard global anycast network.
Hetzner Online GmbH
Rolle. Hardware-Hoster für Anwendungsserver und PostgreSQL-Datenbank.
Übermittelte Daten. Festplatten- und Netzwerkverkehr zwischen den vom Betreiber kontrollierten virtuellen Maschinen und dem öffentlichen Internet.
Speicherort. Deutschland (Europäische Union). Sämtliche HealthLog-Anwendungsdaten liegen auf Hetzner-Infrastruktur unter deutscher Gerichtsbarkeit.
Role. Hardware host for the application server and the PostgreSQL database.
Data transferred. Disk and network traffic between the operator-controlled virtual machines and the public internet.
Storage. Germany (European Union). All HealthLog application data lives on Hetzner-hosted infrastructure under German jurisdiction.
5. Data storage and retention
Deutsch — Speicherung, Speicherdauer und Verschlüsselung
- Serverstandort — primäre Datenhaltung in einer PostgreSQL-Datenbank auf Hetzner-Infrastruktur in Deutschland; die Anwendung wird vom Betreiber als Privatperson in Deutschland verant- wortet. Außer den unter Abschnitt 4 genannten Anbietern ist keine weitere Drittspeicherung beteiligt.
- Verschlüsselung im Transit — TLS 1.3 mit HSTS auf allen öffentlichen Endpunkten; die iOS-Anwendung pinnt zusätzlich das TLS-Zertifikat.
- Verschlüsselung im Ruhezustand — verschlüsselte Festplatten; sensible Spalten (Auth- Token, Integrations-Secrets) zusätzlich auf Spaltenebene mit einem separaten Schlüssel verschlüsselt.
- Backups — sofern der Betreiber die optionale Off-Host-Sicherung aktiviert, werden tägliche Konto-Exporte mit einem separaten AES-256-GCM-Schlüssel in einen S3-kompatiblen Objektspeicher geschrieben. Die Aufbewahrung wird vom Betreiber und der kanonischen Bucket-Lifecycle-Regel festgelegt; die Codebasis kann die aktuell eingesetzte Produktionsregel nicht belegen.
- Gesundheitsdaten — kontobezogene Messungen bleiben bis zur Nutzerlöschung oder Konto-Löschung erhalten, soweit kein typbezogener Verdichtungsjob greift. Rohe dichte Herzfrequenz-, HRV- und Sauerstoffsättigungs-Stichproben werden nach 90 Tagen zu stündlichen Mittelwerten verdichtet; Tages-Rollups bewahren Mittelwert und Extremwerte. Es gibt keinen belegten globalen Fünf-Jahres-Löschjob für alle Messungen.
- Betriebs- und Einwilligungsdaten — Audit-Logs werden täglich nach dem konfigurierten Fenster gelöscht (Server-Standard: 365 Tage). Push-Zustellversuche werden täglich nach 90 Tagen gelöscht. Server- und Reverse-Proxy-Logs folgen der aktiven Log-Rotation des Betreibers. Einwilligungsnachweise bleiben im Konto-Auditverlauf bis zur Konto-Löschung. Für externe KI-Anfragen gilt die Richtlinie des vor der Übertragung genannten Anbieters oder Endpunktbetreibers.
- Kein HealthLog-iCloud-Speicher — HealthLog speichert Server-Datenbank, lokale Gesundheits- caches, Offline-Outbox, ECG- und Workout-Payloads, KI-Transkript-Cache, Medikamentenplaner-Datenbank sowie Widget- und Watch-Snapshots weder in iCloud noch in CloudKit. Lokale gesundheitsbezogene Speicher liegen in geschütztem App- oder App-Group-Speicher, deaktivieren CloudKit soweit anwendbar und sind ausdrücklich vom Geräte-Backup ausgeschlossen. Eine mögliche Apple-Health-Synchronisation ist davon getrennt und wird allein von Apple verwaltet.
- Löschung — der Endpunkt zur Konto-Löschung läuft kaskadiert durch jede nutzer-skopierte Tabelle: Gesundheitsmessungen, Sitzungen, Audit-Log, Integrations-Token, Push- Abonnements, Erfolge, hochgeladene Dateien. Die Löschung erfolgt sofort im aktiven Serverbestand; neue Backups enthalten das Konto danach nicht mehr, ältere Sicherungskopien laufen nach der aktiven Bucket-Lifecycle-Regel des Betreibers aus.
English translation
- Server location — primary store is PostgreSQL on Hetzner-hosted hardware in Germany; the application is operated by the controller as an individual based in Germany. No third- party hosting beyond the providers listed in section 4.
- Encryption in transit — TLS 1.3 with HSTS on every public endpoint; the iOS application additionally pins the TLS certificate.
- Encryption at rest — disk-level encryption plus column-level encryption with a separate key for sensitive columns (auth tokens, integration secrets).
- Backups — when the operator enables optional off-host backup, daily account exports are encrypted under a separate AES-256-GCM key and written to an S3-compatible object store. Retention is set by the operator and the canonical bucket lifecycle rule; the source tree cannot prove the currently deployed production rule.
- Health data — account-linked measurements remain until the user deletes them or the account, unless a type-specific consolidation job applies. Raw dense heart-rate, HRV, and oxygen-saturation samples consolidate into hourly means after 90 days; daily rollups preserve the mean and extremes. No global five-year deletion job for all measurements is evidenced by the server.
- Operational and consent data — audit logs are pruned daily under the configured window (server default: 365 days). Push-delivery attempts are pruned daily after 90 days. Server and reverse-proxy logs follow the operator's active log rotation. Consent receipts remain in the account audit trail until account deletion. External-AI requests follow the policy of the provider or endpoint operator identified before transmission.
- No HealthLog iCloud storage — HealthLog does not store its server database, local health caches, offline outbox, ECG or workout payloads, AI transcript cache, medication-reminder scheduler database, or widget and Watch health snapshots in iCloud or CloudKit. Local health-bearing stores use protected app or application-group storage, disable CloudKit where applicable, and are explicitly excluded from device backup. Apple Health may separately sync HealthKit data under Apple's platform controls; that is Apple-managed behaviour, not HealthLog cloud storage.
- Deletion— the account-deletion endpoint cascades through every user-scoped table: health observations, sessions, audit log, integration tokens, push subscriptions, achievements, uploaded files. Deletion is immediate in the active server store. New backups then omit the account; older backup copies age out under the operator's active bucket lifecycle rule.
6. Your rights (GDPR Art. 15-22, DSGVO)
Deutsch — Ihre Rechte (DSGVO Art. 15–22)
- Auskunftsrecht (Art. 15) — jeder gespeicherte Wert ist über die Historie in der App erreichbar. Ein konsolidierter JSON-Export liegt unter Einstellungen → Daten & Export.
- Recht auf Berichtigung (Art. 16) — jeder Eintrag bietet eine Bearbeiten- und Löschen- Aktion in der App.
- Recht auf Löschung (Art. 17) — Einstellungen → Konto → Konto löschen. Nach erfolgreicher Server-Löschung entfernt die App sofort alle kontogebundenen lokalen Daten. Bei einem Konto mit MFA kann die App zur authentifizierten Web-Kontoseite weiterleiten, damit der Nutzer den erforderlichen frischen Identitätsnachweis erbringt; nach Rückkehr erkennt die App die bestätigte Löschung und führt dieselbe lokale Bereinigung aus. Die Server-Aktion kaskadiert über alle nutzer-skopierten Tabellen via
User.delete+onDelete: Cascade. Neue Sicherungen enthalten das gelöschte Konto nicht; ältere Kopien laufen nach der aktiven Bucket-Lifecycle-Regel aus. - Recht auf Einschränkung (Art. 18) — administrative Sperre per Datenschutz-Anfrage (siehe Abschnitt 11).
- Recht auf Datenübertragbarkeit (Art. 20) — der JSON-Export unter Einstellungen → Daten & Export liefert den vollständigen Datensatz in maschinenlesbarem Format.
- Widerspruch und automatisierte Entscheidungen (Art. 21–22) — der KI-Coach trifft keine automatisierten Entscheid- ungen im Sinne von Art. 22 DSGVO. Er erzeugt Texte zum Nachlesen; ohne ausdrückliche Bestätigung wird keine Aktion ausgeführt. Siehe Abschnitt 7 zur Medizinpro- dukte-Grenze.
- Beschwerderecht — beim Bundesbeauftragten für den Datenschutz und die Informationsfreiheit (BfDI) oder bei der für den gewöhnlichen Aufenthaltsort der betroffenen Person zuständigen Aufsichtsbehörde.
English translation
- Right of access (Art. 15) — every stored value is reachable through the in-app history surfaces. A consolidated JSON export is offered under Settings → Data & export.
- Right to rectification (Art. 16) — every record carries an in-app edit and delete action.
- Right to erasure (Art. 17) — Settings → Account → Delete account. After successful server deletion, the app immediately removes all local account-bound data. For an MFA-enrolled account, the app may hand off to the authenticated web account page for the required fresh identity check; on return it detects confirmed deletion and performs the same local cleanup. The server action cascades through every user-scoped table via
User.delete+onDelete: Cascade. New backups omit the deleted account; older copies age out under the active bucket lifecycle rule. - Right to restriction of processing (Art. 18) — request an administrative suspension via the contact channel in section 11.
- Right to data portability (Art. 20) — the JSON export under Settings → Data & export returns the full record set in a structured, machine-readable format.
- Right to object / automated decision-making (Art. 21- 22) — the AI Coach does not make automated decisions in the Art. 22 sense. It generates written suggestions for the user to read; no action is taken without explicit confirmation. See section 7 for the medical-device boundary.
- Right to lodge a complaint — with the Federal Commissioner for Data Protection and Freedom of Information (BfDI) for the German federal level, or with the data-protection authority of the user's habitual residence.
7. Medical-device boundary (EU MDR 2017/745, MDCG 2021-24)
Deutsch — Medizinprodukte-Grenze (EU-MDR 2017/745, MDCG 2021-24)
HealthLog ist kein Medizinprodukt im Sinne der EU-Verordnung 2017/745 (MDR). Die Anwendung erfasst und visualisiert Beobachtungen, die der Nutzer selbst eingegeben hat; sie diagnostiziert, behandelt, verordnet oder überwacht keine spezifische medizinische Erkrankung.
Die KI-Coach-Oberfläche ist durch zwei ausdrückliche Grundregeln im System-Prompt eingegrenzt: sie empfiehlt keine GLP-1-Dosen (GROUND RULE 9) und erzeugt keine wirkstoff-bezogenen Schätzungen (GROUND RULE 15). Der GLP-1-Research-Mode ist eine reine Visualisierung, die erst nach einer versionierten Bestätigung freigeschaltet wird, die dem Nutzer die MDR-Grenze ausdrücklich nennt. Keine dieser Oberflächen gibt klinische Empfehlungen aus.
Für medizinische Beratung muss eine approbierte ärztliche Fachkraft konsultiert werden. HealthLog soll diese Beratung unterstützen, indem es selbst erfasste Daten aufbereitet — nicht ersetzen.
English translation
HealthLog is not a medical device within the meaning of EU Regulation 2017/745 (MDR). The application records and displays observations the user has entered; it does not diagnose, treat, prescribe, or monitor a specific medical condition.
The AI Coach surface is constrained by two explicit ground rules in its system prompt: it does not recommend GLP-1 doses (GROUND RULE 9), and it does not produce drug-level estimates (GROUND RULE 15). The GLP-1 Research Mode chart is a display-only visualisation gated behind a versioned acknowledgment that cites the MDR boundary to the user before unlocking. None of these surfaces issue clinical recommendations.
For medical advice the user must consult a licensed clinician. HealthLog is intended to support that conversation by surfacing self-tracked data — not to replace it.
8. Apple App Store privacy categories
Deutsch — Apple-App-Store-Datenschutzkategorien
Die Privacy-Nutrition-Labels der iOS-Anwendung in App Store Connect ordnen sich folgenden Kategorien zu (jeweils linked to the user, zur App-Funktion und, soweit angegeben, Konto-Verwaltung):
- Gesundheit & Fitness.
- Sensible Informationen (Blutdruck, Blutzucker, Medikamente).
- Name — Anzeigename für Profil und Berichte; App-Funktion und Konto-Verwaltung.
- Kontakt-Informationen (E-Mail-Adresse) — Konto-Verwaltung.
- Nutzer-Inhalte (Notizen, Prompts und Fragen, geprüfter OCR- und Dokumenttext).
- Fotos oder Videos (Profilbild sowie ausdrücklich hochgeladene Dokumentfotos/-scans; Schnell-Erfassungsbilder bleiben auf dem Gerät).
- Kennungen (Geräte- und Nutzer-Kennung).
- Diagnose, Nutzung, Browsing, Suche, Andere — nicht erhoben.
- Standort — nicht erhoben, außer bei einer optional vom Nutzer angehängten GPS-Workout-Route.
Tracking: Nein. HealthLog verwendet keine Werbung, kein anwendungsübergreifendes Tracking, keine Werbemessung und kein Drittanbieter-Analytics-SDK. Optionale KI-Anbieter erhalten Daten nur für die vom Nutzer ausgelöste App-Funktion, nicht für Werbung oder Tracking.
English translation
The iOS application's Privacy Nutrition Labels in App Store Connect map to the following categories (each linked to the user, used for app functionality and, where stated, account management):
- Health & Fitness.
- Sensitive Info (blood pressure, glucose, medications).
- Name — display name for the profile and reports; app functionality and account management.
- Contact Info (email address) — account management.
- User Content (notes, prompts and questions, reviewed OCR and document text).
- Photos or Videos (profile image and explicitly uploaded document photos or scans; quick-entry images stay on the device).
- Identifiers (device identifier, user identifier).
- Diagnostics, Usage Data, Browsing History, Search History, Other Data — not collected.
- Location — not collected, except for an optional GPS route the user attaches manually to a workout.
Tracking: No. HealthLog uses no advertising, cross-app tracking, advertising measurement, or third-party analytics SDK. Optional AI providers receive data only for the app function the user invokes, not for advertising or tracking.
9. Children
Deutsch — Kinder
HealthLog richtet sich nicht an Kinder unter 16 Jahren. Die Anwendung sollte nicht ohne nachweisbare elterliche Aufsicht von Personen unter 16 Jahren verwendet werden. Der Betreiber erhebt wissentlich keine personenbezogenen Daten von Kindern unter 16 Jahren; sollte dies auffallen, werden die Daten umgehend gelöscht.
English translation
HealthLog is not directed at children under the age of 16. The application should not be used by anyone under 16 without verifiable parental supervision. The operator does not knowingly collect personal data from children under 16; if such data is discovered, it will be deleted on detection.
10. Changes to this policy
Deutsch — Änderungen dieser Erklärung
Diese Erklärung trägt oben einen Versionsstempel. Materielle Änderungen werden in den In-App-Versionshinweisen und im Open-Source-Changelog zusammengefasst. Die veröffentlichte Policy-Version ist an die Anwendungsversion gebunden, mit der sie eingeführt wurde.
English translation
This document is version-stamped at the top. Material changes will be summarised in the in-app release notes and on the open-source changelog. The published policy version is bound to the application release version that introduced it.
11. Contact
Deutsch — Kontakt
Verantwortlicher und Ansprechpartner für DSGVO-Anfragen ist der Betreiber dieser Instanz, eine Privatperson mit Sitz in Deutschland (vollständige Postanschrift wird Antragstellern auf Anfrage über den unten genannten Kanal mitgeteilt; sie ist nicht öffentlich aufgeführt, um gezielte Belästigung zu verhindern — eine Klarstellung, die die deutschen DPAs in ihren Hinweisen zu Impressums- Pflichten ausdrücklich zulassen, sofern eine elektronische Erreichbarkeit besteht).
E-Mail (Betreiber): mbombeck@gmail.com. Bitte das E-Mail-Betreff mit "HealthLog DSGVO — <Auskunft | Löschung | Übertragbarkeit>" kennzeichnen. Erste Antwort innerhalb von 30 Tagen gemäß Art. 12 Abs. 3 DSGVO.
Alternativ via GitHub: öffentliches Issue unter github.com/MBombeck/HealthLog/issues mit Titel GDPR — <Access | Erasure | Portability> request — bitte keine personenbezogenen Daten im öffentlichen Issue posten; ein privater Kanal wird in der ersten Antwort angeboten.
English translation
The controller and point of contact for GDPR enquiries is the operator of this instance, an individual based in Germany (the full postal address is disclosed to requesters via the channel below upon request; it is not publicly listed to prevent targeted harassment — a practice explicitly tolerated by German data-protection authorities provided an electronic contact route is available).
Email (operator): mbombeck@gmail.com. Subject line: "HealthLog GDPR — <Access | Erasure | Portability>". First reply within 30 days per Art. 12 (3) GDPR.
Alternative via GitHub: public issue at github.com/MBombeck/HealthLog/issues titled GDPR — <Access | Erasure | Portability> request — please do not include personal data in the public issue; a private channel will be offered in the first response.