Your data,
with clear, controllable boundaries.

During registration and sign-in, the identity service processes email address, internal user identifier, sign-in and two-factor authentication status, session, and security events. Email and user identifier are used for authentication, attributing records to the correct account, sync, and account security.

When you fill in your profile or confirm your own report, we process the name or preferred name you voluntarily provide, date of birth or age confirmation, and any physiological reference sex, height, and weight you may enter. These details are used for adult eligibility checks, displaying records, and selecting age- or reference-sex-related interpretive ranges when applicable evidence exists.

Health data includes the marker names, values, units, collection dates, laboratory reference intervals, source types or labels you confirm and save, plus confirmation and import metadata kept for traceability. Report import also sends technical metadata that does not include report content—for example file type, file byte size, page count, and parser version—to the server.

If you use “My model”, we also process the daily date and time zone, sleep duration and self-rated quality, energy, stress, actual exercise duration and intensity, whether you ate before sleep, vegetable servings, protein-containing meals, alcohol drinks, and optional notes you voluntarily enter. These records are used only for your recent personal baseline and transparent, recalculable descriptive statistics; they are marked by default as not for cross-user training or aggregation.

Hosting and security infrastructure may process ordinary network request information such as IP address, browser or device type, request time, access path, response status, and security logs. We use this information to deliver and protect the service, not for advertising profiles.

Parsing, checking and everything before saving happen on your device; raw file bytes, page images, full OCR text and PDF passwords are never sent to PearHealth servers or to third parties. With AI double-check on, only the de-identified results text and row coordinates is sent, for a second read and cross-check; photos and camera images have no path off the device.

Parsed results are checked on your device first (text-layer reports and high-confidence recognised rows); you confirm identity and date, then save in one step. Rows that do not pass the check are listed separately for you to decide. Only structured records you confirm and save enter the account cloud; canceling, closing, or a parse failure does not turn the source file into a cloud attachment.

Confirmed report observations on web and iOS are encrypted on the client with an account-specific data key before being written to the cloud vault. Records are isolated by account and use authenticated encryption to detect tampering of ciphertext or context. The server may decrypt on authenticated and authorized product read paths to complete sync, historical trends, interpretation, and account features.

Manual entry on web and iOS is sent through authenticated interfaces; plaintext exists only while that request is processed, and the server encrypts before writing to the health-record database. Historical records already written by older versions to an account-isolated plaintext table are still read for continuous display, but new report imports and manual entries no longer write plaintext copies to that table; historical migration and deletion will proceed only after an independent data-integrity review.

Account profile fields such as name, date of birth, reference sex, height, and weight must not be understood as anonymous data: they are associated with the user identifier and protected by authentication and database access controls. No internet service can promise absolute security; we use least privilege, account isolation, encryption in transit, encryption at rest, and security logs to reduce risk.

On iOS, you may choose item by item whether to allow PearHealth to read sleep, resting heart rate, heart-rate variability, respiratory rate, steps, active energy, workout records, or blood-glucose history from Apple Health / HealthKit. Access is read-only; PearHealth does not write data to HealthKit. Daily steps and active energy use HealthKit cumulative statistics; overlapping sleep wall-clock intervals from different readable sources are counted once, and conflicting stage labels are shown only as generic “Sleep”. These temporary summaries are not stored across launches or accounts, and are not uploaded to PearHealth, analytics, advertising, or research services.

Calendar connection is also your choice. Add-only mode requests write permission only and, after you tap, writes one wind-down event to the system’s default new-event calendar; that event may sync via its calendar provider. Full-access mode reads future calendar events on device, ignores canceled and free-marked events, and derives temporary conflict intervals only from busy, tentative, or unavailable events; PearHealth does not retain or upload event titles, notes, attendees, locations, URLs, or other event details. Closing or switching the connection clears temporary busy intervals inside the App.

In-app sleep and meal reminders use local notifications and do not require calendar permission. Remote connections to Oura, vendor remote CGM accounts, and other wearables are not currently enabled; blood-glucose history already in HealthKit is a different data path from remote vendor account connection.

We use the data above to authenticate accounts, save and sync records, show historical trends, generate educational interpretations based on rules and confirmed data, provide security support, and prevent abuse. PearHealth does not treat individual results as a diagnosis and does not replace a physician or emergency medical services.

Hosting, database, and authentication providers such as Vercel and Supabase process data necessary to provide the service on behalf of PearHealth. We do not sell personal or health data, do not provide data to data brokers, do not perform cross-app or cross-site tracking, and do not use health data to serve ads.

Research processing is off by default. Manual daily records in “My model” are fixed as not for training or aggregation; declining research does not reduce product features. Without separate, explicit, and revocable consent and applicable governance arrangements, we will not use account health records for research or general model training.

Optional research aggregation (off by default)

Cross-user research aggregation is off by default. Only after you explicitly opt in from your account does the client derive a de-identified summary from the decrypted vault session and submit it to storage separate from the vault. That choice does not let the server read vault plaintext or ciphertext.

A de-identified summary includes only a five-year birth-year bucket, sex at birth, nationality code, biomarker observations (catalogue id, value, canonical unit, reference interval, month), height and weight buckets, and month-granularity counts of check-ins, meals, and supplements. It does not include name, exact date of birth, exact dates, free text, original reports or images, device identifiers, or email addresses. Linkage uses a random research pseudonym (pseudonymisation, not anonymisation) so summaries can be deleted when you withdraw.

Use is limited to population statistics and product research. This consent binds PearHealth’s business-transfer successors. You may withdraw at any time; withdrawal deletes every research summary you have contributed. Without consent the pipeline is zero bytes.

You can view and export records within your account. Signing out clears the account session and account cache on the current device; local reminders can be turned off in the App or system settings. After export or sharing, the receiving location is controlled by you and its provider.

Daily records in “My model” can be deleted one by one or exported as local JSON. Single-item deletion clears both that event’s ciphertext and the encrypted response copy used for safe retry, and retains a deletion-block record without health content so stale requests cannot rewrite deleted data.

You can start deletion of your account and account cloud data in the App’s account settings. To prevent accidental deletion, deletion requires re-authentication and a second confirmation; after confirmation the request enters background processing and is not necessarily immediate. We retain related data only for as long as reasonably necessary to complete the request, comply with legal obligations, handle security incidents, or resolve disputes, and we do not promise a fixed retention period here that has not been verified.

Deleting a single report generates a server-only safe-retry credential used to avoid duplicate or partial deletion when a network response is lost. That credential includes account / report identifiers, a request digest, row count, and timestamp, and does not include marker values or report source content; the retry window is 24 hours, after which a scheduled service cleans it up in batches. Expiry means entry into the cleanup queue, not immediate deletion at that second.

After deletion is confirmed, the App signs out of the account and clears the local account cache. Copies you already voluntarily exported or handed to other services are not controlled by PearHealth account deletion.

A monitored privacy and support channel has not yet been published; that is a must-complete item before public release. For now, do not send reports, verification codes, PDF passwords, or other health materials via informal messages, public social accounts, or ordinary email; the Support page will be updated after formal channels are published.

When product data paths, permissions, or service providers change in material ways, we will update this page’s date and related explanations. Any new remote wearable connection, health-data use, or research feature must complete corresponding disclosure and authorization before it is enabled.