Mealz — Privacy Policy — Patient application

Prepared
2026-11-07
Version
patient-privacy-2026-11-07-v1
Target URL
https://app.mealz.co.il/privacy

Operator, scope and contact

The contracting operator is Eitan Goren (איתן גורן), operating under the name Mealz, as an individual in Israel, not an incorporated company. The official contact method for service, privacy requests and notices is email only: eitangoren08@gmail.com. No physical business or residential address is published. Designating email as the contact method does not represent that every statutory disclosure or service requirement is satisfied for every type of transaction. This application policy is separate from the marketing website policy. Mealz is responsible for its processing to operate the service, accounts, authentication, security and support. Clinics are responsible for treatment decisions, independent clinical records and duties applicable to their own processing. Controller or processor roles follow the actual activities; this does not transfer all Mealz duties to a clinic or merge the entities.

Information in the patient system

Information may include UID, name and email from sign-in; language/time zone; entered weight/height, activity level, dietary preferences/restrictions and goals; meal images/descriptions, calorie/nutrient estimates, dates and favorites; measurements, activity and goals; dietitian connections, consent choices, reports and delivered feedback. These data can reveal health information even without an entered diagnosis. Sources include the user, AI analysis and the dietitian within authorized permissions. Users need not supply information unrelated to the feature they choose.

Processing purposes and user choices

Information supports accounts, authentication, professional eligibility review, invitations, nutrition logging, estimates and progress, professional review, delivery of approved feedback and goals, support, usage controls and abuse prevention. Providing nutrition-profile information and content is a user choice, but a feature cannot operate without the information it requires. Without an invitation and eligibility there is no independent onboarding; without sharing consent the connection does not authorize professional access. Terms, policy acknowledgment, AI consent and sharing consent do not replace each other. The operator remains responsible for the applicable legal basis and mandatory duties for each processing activity. The beta is restricted to adults aged 18 or above. Onboarding requires an explicit declaration that you are at least 18; without it the server rejects registration. This is self-declaration, not identity-document or birth-date verification. Minors may not join, including through a parent or guardian account.

Voluntary health submissions and permission-based sharing

You choose which blood-test results, body measurements, body-fat percentages, medical history and other health information to enter or upload. You should keep submissions accurate and current and avoid unnecessary disclosures. This choice does not relieve the Mealz operator of legal information-security, privacy or personal-data processing obligations. Uploading health information does not itself consent to sharing it with a dietitian. Professional access requires an invitation, separate permissions and sharing consent, which may be revoked subject to the limitations described in the sharing section.

Storage, separate systems and data flows

The patient application and clinic system use separate Firebase projects. Firebase Authentication manages sign-in accounts, Cloud Firestore holds structured data and Cloud Storage holds images/files according to the feature. Cloud Functions and App Hosting operate the interfaces. Similar identities or matching emails in the two systems do not automatically grant access. Professional reads use authenticated services that check clinic membership, eligibility, the patient connection and sharing authorization. A Mealz connection does not automatically copy the entire clinical file into the patient system.

AI provider, images, descriptions and search

Meal-analysis requests send OpenAI an image and/or description and the nutrition context passed by the code. Free text may include identifiers or health information entered by the user. The current path allows the AI provider to use web search, so queries derived from input may also be processed by its search services. Weekly-report AI receives selected nutrition evidence such as metrics, counts and changes; that path does not send images or dedicated patient identifiers. Requests use store:false. This is not a promise of zero retention, anonymity or absence of provider abuse-monitoring logs. Provider retention and processing depend on the applicable provider terms and account settings; store:false does not replace those arrangements.

Dietitian sharing, permissions and revocation

The patient selects permissions such as meals/images, summaries, measurements and goals through a separate invitation-and-consent flow. Connection identity, scope and timing are recorded; current code gives a sharing authorization a one-year expiry, subject to earlier revocation and eligibility. Professional goal creation/updates require separate approval in the interface. Revocation blocks new connection access, while cross-system synchronization may continue in the background. It does not erase personal history or copies already viewed or lawfully retained by the clinic. This policy does not substitute for that sharing authorization.

Providers and administrative access

Google/Firebase provide infrastructure, authentication, storage and App Check using reCAPTCHA Enterprise; infrastructure providers may process network, browser and request information. OpenAI supplies the analysis described above. The current email path uses Gmail for invitations and includes the recipient address, professional/clinic names and invitation link; further clinical email/calendar uses depend on clinic features. The application’s platform-owner role administers applications, plans and beta access and does not itself grant unrestricted medical-record reads. Cloud-administrator access is separate from the application owner role and can enable infrastructure access; it must be limited to authorized operational needs and applicable confidentiality duties.

Processing outside Israel

Do not assume information is stored or processed only in Israel. Code configures server paths in me-west1 for the patient system and us-central1 for the clinic, and App Hosting in europe-west4; these do not establish the location of every dataset, backup or subprocessor. AI, email and authentication may involve other countries. These configured regions do not guarantee data residency. International processing remains subject to applicable legal requirements and provider arrangements. This policy makes no claim of GDPR, HIPAA or security-standard certification or a special provider agreement.

Retention and current implementation limits

There is no complete automatic deletion schedule for all cloud data after a fixed number of days. User records, meal journals/images, measurements, goal history, reports and feedback remain stored unless removed through supported functions or manual handling of a verified request. Beta, invitation or consent expiry is not data deletion. An upload ticket lasts one hour, but that does not mean its image is deleted after one hour. New invitations generally last seven days. Log, backup, acceptance-record and external-provider retention vary by system and provider; no uniform fixed retention period or complete erasure from every copy is promised. Requests follow the procedure below, subject to applicable rights and recordkeeping duties.

Device storage and technical information

The interface may retain sign-in state, language and browser preferences. Remember-device and draft-saving options exist; the local data cache has a code-defined lifetime of up to seven days, separate from cloud retention. This does not promise end-to-end encryption or complete removal from every browser layer. Avoid remembering health information on a shared device. AI usage records contain UID/professional association where relevant, operation, time, request ID, quota, outcome, available token usage and estimated cost. That usage-recording path excludes photos, meal content and medical records. Infrastructure providers may maintain additional logs.

Safeguards and their limits

Reviewed paths check authentication, roles/clinic membership, server-side consent and eligibility, relevant App Check protection and separation between projects. These do not guarantee prevention of all unauthorized access, human error or security incidents. The code does not establish end-to-end encryption, full anonymity, certification or incident-response deadlines. Report suspected unauthorized access or a privacy incident to the official contact email. The operator handles reports and provider escalation manually; this does not promise continuous monitoring or a fixed incident-response time. Do not publish or forward credentials or invitation links.

Access, correction, export and deletion requests

Review or update information where the interface supports it. For access, correction, export or deletion, email eitangoren08@gmail.com from the account email, describing the requested scope without passwords or unnecessary health documents. The operator verifies account control and the request scope before disclosure or changes, reviews applicable retention duties and technical/provider limits, and responds by email with the action taken or an explanation of limitations and any further information needed. These requests are handled manually; there is no complete self-service patient-account deletion or full-data export workflow and no guaranteed technical completion deadline. Mandatory statutory rights and deadlines remain applicable. Deleting a sign-in account alone does not erase all stored data. Separate clinical records must also be addressed with the clinic; Mealz remains responsible for its own processing duties. Sharing may be revoked in the application independently of a deletion request.

Versions, owner approval and separate acceptance records

Each document has a version and SHA-256 content digest. Publication for acceptance requires recorded platform-owner approval of the exact versions and digests, with an approval reference and timestamp. Platform-owner approval is not independent legal review or a compliance certification. Registration requires explicit Terms acceptance, Privacy Policy acknowledgment and an adult-eligibility declaration. Server records bind the account identity and creation time, audience, document versions/digests/URLs, language, acceptance timestamps and owner-approval evidence. Historical versions and acceptance records are preserved. These records do not grant patient-sharing or professional goal permissions. Checkboxes are not preselected. Material amendments are published as a new version, with renewed acceptance where required.