Privacy, in plain language.

1. Scope and who is responsible

This Privacy Policy applies to the MED Diary iPhone and iPad app, Shared Access features, and the MED Diary website. In this policy, “MED Diary,” “we,” “us,” and “our” mean the developer and operator of MED Diary.

The policy does not replace the privacy terms of Apple, OpenAI, USDA FoodData Central, Open Food Facts, a caregiver you choose, or any other service you use independently. Links to those services are provided where useful.

2. Data on your device and optional encrypted backup

Your diary can include readings, medications and dose history, meals, appointments, health profiles, lab reports and results, insurance cards and documents, notes, goals, reminders, and app settings. These records stay in device-local storage and MED Diary does not require an account for local use. MED Diary does not mirror clinical records or health settings through CloudKit or iCloud key-value sync.

Backup & Sync is optional and part of MED Diary Premium. If you enable it with Sign in with Apple, MED Diary creates an encrypted mailbox and seals eligible records and files on your device with AES-256-GCM before upload. Our service stores opaque record envelopes, encrypted file chunks, a recovery envelope, and encrypted device labels. It does not receive a plaintext copy of the vault key and cannot read health values, notes, filenames, insurance documents, prescription images, or lab files. It can observe the Sync Identity, authentication events, device count, stable opaque identifiers, record-envelope sizes, each encrypted file's original byte size, request timing, and network metadata.

To help another enrolled device notice a mailbox change, the service may store that device's Apple push token in encrypted form and send a best-effort background signal through Apple Push Notification service. The notification contains no health information, record category, profile, value, count, mailbox identifier, or visible message; it only asks the app to perform its normal authenticated encrypted check. The service can observe token registration and delivery timing. Opening the app also checks for changes because Apple does not guarantee background delivery.

You may keep an optional continuity copy of the vault key in iCloud Keychain. The key is not placed in CloudKit or sent to MED Diary. Recovery is also available through a trusted device or your printable Recovery Key, which you can replace if it may have been exposed. Recovery-envelope replacement uses a root-derived capability whose one-way verifier is stored by the service; the capability cannot decrypt your diary. If every recovery method is lost, MED Diary cannot reset the key or decrypt the backup. See the illustrated Encrypted Backup & Sync overview for the shorter version.

The built-in Demo uses a separate local sample-data sandbox rather than your private diary. After about 24 hours, MED Diary offers to refresh the Alex sample. If you added eligible manual readings, you can move them to your primary profile first or postpone the refresh. Sample family profiles created inside Demo are memory-only and disappear on relaunch or when Demo refreshes.

If you enable App Lock, MED Diary stores a separate app passcode in this device's Keychain and can also ask iOS to authenticate with Face ID or Touch ID when you enable that option. MED Diary does not receive your biometric data.

3. Apple Health

With your permission, MED Diary can read supported health information from HealthKit, including blood pressure with its pulse (heart rate), blood glucose, weight, height, date of birth, biological sex, blood type, activity, and workouts, and can write supported readings back to Apple Health. You choose the categories in Apple's permission screen and can change them later in the Health app or iOS Settings.

Health information you import into your MED Diary log becomes part of the diary and follows the storage choices described above. We do not use HealthKit information for advertising, marketing, data brokering, or decisions about credit, employment, or insurance.

4. Optional AI features and food lookups

Outside the built-in demo, MED Diary's live AI features use the MED Diary server as a secure intermediary and OpenAI as an AI processing provider. Before the first live meal photo, text, or voice AI request, the app asks for explicit permission covering the information sent, both recipients, and possible retention. That permission applies to later meal AI requests until you withdraw it in Settings → Privacy & Security → AI Meal Analysis or until a material processing change requires MED Diary to ask again. Content is sent only after you deliberately start a live feature; the lab flow also requires a separate review and approval of the exact upload. The demo uses bundled inputs and canned results on your device; it does not upload those samples or consume live AI credits.

Lab report extraction

Your original lab report or photo stays on your device. Before upload, the app lets you cover names, dates of birth, account numbers, or other details and then creates a flattened PDF in which any redactions are burned in. You can inspect the exact PDF and must expressly approve it before it is sent.

The approved PDF, including any on-device redactions, is sent to the MED Diary server and then to OpenAI so the report can be converted into structured results for your review. MED Diary uses the PDF and AI response only to complete that request and does not intentionally retain either as an ongoing server-side health record. Hosting and web-server infrastructure may use short-lived request buffers or temporary storage while the request is processed. The result returns to the app; nothing is added to your diary until you confirm it.

Meal nutrition estimates and Speak Meal

When you ask for a nutrition estimate from text or an image, the meal description and any optional meal or Nutrition Facts photo you selected are sent through the MED Diary server to OpenAI. When you finish a Speak Meal recording, the temporary audio, the device locale, the nutrient fields you chose to track, and up to 24 food names selected on device from your reusable meal history as spelling hints are sent through the MED Diary server to OpenAI for transcription and estimation. The hints are request-scoped and do not give the service your full meal history. The temporary recording is deleted from the device after completion, failure, or cancellation.

MED Diary uses this content to return an editable estimate and does not save it as a readable server-side meal history. If the online request fails, the app may offer a transcript produced with Apple's Speech Recognition framework; recognition happens on device when supported and otherwise may use Apple's service. If you save the estimate or transcript, it becomes part of your diary on your device and is included in your sealed mailbox only when Backup & Sync is enabled.

Food database search and barcode lookup

Food search and packaged-food barcode lookup are optional alternatives to manual entry. The barcode itself is recognized by Apple's on-device scanner. MED Diary then sends the search words or barcode digits to the MED Diary server. Search words are forwarded to USDA FoodData Central. A barcode is checked with Open Food Facts and, when there is no match, USDA FoodData Central. These providers return public food and nutrition records under their own privacy terms. When Open Food Facts provides a public package image, the app can load that image directly for the review screen; the image request therefore reaches Open Food Facts from the device.

The MED Diary service treats a food-search result as current for 10 minutes to improve responsiveness. An expired search entry can remain in service memory until that search is repeated, the bounded cache is cleared, or the service restarts, but it is not linked to a user or profile. The service can also keep a shared cache of positive barcode results keyed by the public product code; a result is treated as current for 30 days, while an expired stored row may remain until it is refreshed or removed during service maintenance. That product cache contains the provider result, not a user, profile, device, or scan history. Entering a meal manually does not contact either food catalogue.

Provider handling

MED Diary asks OpenAI not to store the response as a saved API object, but that setting does not by itself eliminate OpenAI's separate abuse-monitoring logs. OpenAI says those logs may contain API input and output and are retained for up to 30 days by default, unless the production project has been approved for Modified Abuse Monitoring or Zero Data Retention. MED Diary does not claim either exception unless and until it is confirmed for the production project. OpenAI also states that API business data is not used to train its models by default. See OpenAI's API data-controls documentation for current details.

5. Premium purchases and free AI uses

Apple processes Premium purchases through the App Store. MED Diary receives StoreKit status and transaction identifiers needed to unlock Premium, restore purchases, and verify subscription access. We do not receive your full payment-card details.

To enforce lifetime free AI-use limits fairly across reinstalls and your devices, MED Diary creates a random app identifier and a separate high-entropy server credential. Neither contains your name, email address, or health record. Both are kept on your device, synchronized using iCloud key-value storage, and sent to the MED Diary server with metered AI requests. The server stores the random identifier, the feature name, use count, last-updated time, and a one-way SHA-256 hash of the credential; it does not store the credential itself. The credential proves that the app is allowed to read or delete the matching ledger.

MED Diary also supplies the random app identifier to Apple as an App Store app-account token when you purchase Premium, and may send the current App Store transaction identifier to the MED Diary server so it can verify access with Apple. The app-account token and server credential have separate deletion rules described below.

6. Shared Access

Shared Access is optional and, like Backup & Sync, uses a Sign in with Apple identity only when you activate it. When you use it, Sign in with Apple gives the MED Diary server a stable Apple account identifier and, depending on your Apple choices, an email address that may be an Apple private-relay address. We may also store the display name you provide.

MED Diary and MED Diary Follow treat the same Apple Account as one Shared Access identity. Deleting that identity from either app removes every share it sent or accepted and the related encrypted relay records. It does not delete the private diary or cancel Premium.

The supported categories are vitals; current medications plus dose events/adherence; and individual lab results. Shared Access does not send lab-report PDFs, appointments, meals, profiles, or other diary content outside those categories.

To invite a caregiver, the server stores the caregiver's email address, your display name for the invite, the categories you chose to share, the invite status and code, and creation, acceptance, or revocation dates. The full invite generated by the app contains that code and a separate device-generated encryption key. The caregiver must sign in with the Apple email you invited; only the code, not the key, is sent to the MED Diary server when they accept.

Selected health-record content is encrypted on the sender's device with the key carried in the full invite. The server stores and relays only encrypted record envelopes. The caregiver's device keeps the key in its Keychain and decrypts the records there for a read-only view. MED Diary cannot read the values inside those envelopes. Because the invite contains the key, share it through a trusted channel and protect it like a password.

End-to-end encryption hides content, not all identity or activity. The server can see that a share exists; the selected category names; encrypted-record counts and stable record identifiers; when records are added, changed, or deleted; and when a caregiver checks for updates. Dose-event identifiers contain an opaque medication identifier, a calendar day index, and scheduled minutes. This can reveal patterns — for example, that a user updates glucose records frequently or has activity around a dose slot — without revealing the reading, medication name, or dose status inside the encrypted envelope.

Your caregiver can see whatever you choose to share after their device decrypts it. Updates occur when the apps run their sharing and refresh passes and may be delayed. Creating an invite, adding a category, or restarting a stopped share requires Premium. If Premium ends, an existing share continues those normal updates until you narrow or revoke it; those privacy-reducing actions remain available without Premium. Choose recipients carefully and revoke access if it is no longer appropriate. For a shorter visual overview, see How Shared Access protects records.

7. Server operations, website, and support

Security and request metadata

When your app or browser contacts our systems, the server and hosting provider receive normal network information such as IP address, request path, request ID, timestamp, upload size, response status, and processing duration. We use this information for rate limiting, security, reliability, and debugging. MED Diary's application logs do not persist raw client IP addresses, uploaded PDFs, meal descriptions, health values, or decrypted Shared Access records. Database-backed rate-limit counters store only one-way hashes derived from the user identifier and network address. They cover a one-minute window, are automatically pruned shortly after that window expires, and are removed for that user when their AI-use history is deleted. Hosting infrastructure may maintain its own security and access logs under the provider controls described below.

Website

The MED Diary website uses Plausible Analytics to understand aggregate traffic and improve the public site. It measures information such as the page visited, referral source, campaign parameters, country, device type, browser, and operating system. Plausible does not use cookies, local storage, or persistent identifiers, and does not track people across websites or devices. To estimate daily visitors, Plausible derives a daily identifier from network and browser information using a rotating salt; raw IP addresses and full user-agent values are not stored. Plausible processes website analytics on our behalf in the European Union. The analytics tag runs only on the public website and never receives MED Diary health records, app activity, account identifiers, or support-message content. We do not use website analytics for advertising. Hosting infrastructure may also keep basic request logs such as IP address, time, requested page, and browser information for security and delivery.

Support

If you email support, we receive your email address and whatever text, screenshots, diagnostic details, or attachments you choose to send. Please remove health information you do not want us to receive. We use support communications to answer you, investigate problems, prevent abuse, and improve the app.

When you explicitly submit an in-app support report, it can include a random incident reference and the technical details shown for review, such as app and iOS versions, device model, network type and constraints, request identifiers, status and error codes, server host, transfer sizes, and duration. The PDF, filename, extracted lab values, diary content, and credentials are never attached. You separately choose whether to include your Anonymous Support ID. In-app support reports are deleted after 30 days.

When you submit an in-app support report, our email delivery provider (currently Resend) may process the case reference and an operational summary containing the feature and occurrence time, app and device versions, request identifiers and server host, upload stage and duration, status and error codes, transfer sizes, network status and constraints, and an automated likely-failure classification. If you provide a reply email, Resend also processes that address to send an acknowledgment and allow replies. The user-entered message, Anonymous Support ID, locale and time zone, PDF, filename, lab values, diary content, and credentials are not included in automated email bodies. Email replies and other support communications may be retained as reasonably needed to answer and resolve the communication.

8. When information is disclosed

We do not sell personal information or health information. We do not use it for targeted advertising. Information is disclosed only as needed for the service or when the law requires it:

• Apple: iCloud, HealthKit, StoreKit, Sign in with Apple, and operating-system services you choose to use.
• OpenAI: the approved lab PDF, including any on-device redactions, or the meal description, optional photo, Speak Meal audio and transcript, locale, requested nutrient fields, and request-scoped familiar-food spelling hints needed for the AI request.
• USDA FoodData Central and Open Food Facts: food search words or packaged-food barcode digits needed for the lookup. Open Food Facts is checked first for barcodes; USDA remains a fallback. A public package-image request can also be sent directly from the device to Open Food Facts when the review screen displays that image.
• Infrastructure providers: providers such as Fly.io that host and protect the MED Diary server and process data only to provide that infrastructure.
• Plausible Analytics: aggregate public-website traffic and campaign measurement, processed without cookies or persistent cross-site identifiers and never including MED Diary health records or app activity.
• People you choose: a caregiver receives the records you select through Shared Access; recipients of exports or reports receive what you send them.
• Safety and law: where reasonably necessary to comply with law, protect rights and security, investigate fraud or abuse, or respond to a valid legal process.
• Business change: as part of a merger, financing, acquisition, or sale, subject to appropriate confidentiality and continued notice of how data is handled.

9. Retention and deletion

• Your diary and encrypted mailbox: local records stay on your devices until you delete them. If Backup & Sync is enabled, opaque encrypted records and deletion tombstones remain so a fresh device can reconstruct the diary; that encrypted record history is retained until account deletion. Superseded encrypted file chunks may be deleted earlier, based on liveness lists your device publishes, without the server reading any content. Delete My Data removes every real profile and its clinical records and stored files, including insurance cards and documents, app and profile settings, the family-profile registry, App Lock credential, MED Diary notifications, temporary health-data files, vault keys, encrypted replication state, the server mailbox and recovery envelope, and registered Apple push tokens. An offline second device may retain its local copy until you erase it on that device.
• AI request content: the MED Diary server does not keep the uploaded report, meal description/photo, Speak Meal audio, transcript, personalization hints, or full AI result as an ongoing record after completing the request. OpenAI's own limited retention may apply as described above.
• Food lookups: search results are treated as current for 10 minutes, although expired entries can stay in the bounded in-memory cache until refreshed, cleared, or the service restarts. Positive barcode results are treated as current for 30 days; expired stored rows may remain until refreshed or removed during service maintenance. Neither cache is linked to a user, profile, device, or scan history. Hosting request logs may still contain the request path as described above.
• AI-use ledger and credential: the server's random-identifier ledger, credential verifier, and per-feature counts remain active to preserve lifetime free-use limits until you explicitly erase them. When a ledger may exist, Delete My Data sends an authenticated deletion request for it. If the request fails, deletion is shown as incomplete and the credential is kept so you can retry. Once server deletion succeeds—or no ledger exists—the server holds no identifier, verifier, counts, or timestamps for that ledger, and MED Diary clears the old server credential from the device and iCloud. Synchronized deletion state prevents a stale device from restoring it. Using live AI later creates a fresh credential and an empty ledger.
• App Store app-account token: Delete My Data asks StoreKit whether MED Diary has verified purchase history. When StoreKit reports a verified transaction, the random app identifier used as that transaction's app-account token remains on your device and in iCloud solely so MED Diary can continue to verify the purchase. When StoreKit reports no verified purchase history, MED Diary deletes the old identifier from the device and iCloud. This token is separate from the server credential, which is always cleared, and contains no name, contact details, or health record.
• Shared Access: active account, invitation, and share records remain while needed to provide sharing. Revoking a share deletes its encrypted record payloads immediately; its metadata becomes eligible for deletion after 30 days and is removed by the daily cleanup. Expired pending invitations and expired refresh tokens are also purged by a daily cleanup after they expire. Deleting the Shared Access account removes its Sign in with Apple identity, tokens, shares, and encrypted records and revokes the server's Apple authorization.
• Website analytics: aggregate Plausible Analytics data is kept only as long as reasonably needed to understand and improve the public site and can be deleted earlier when no longer needed.
• Logs and support: in-app support reports are deleted after 30 days. Email support and security logs are kept only as long as reasonably needed for security, troubleshooting, legal obligations, and resolving the communication, subject to infrastructure backup and log rotation.

Delete My Data does not remove Apple Health records or cancel an App Store subscription. Uninstalling the app also does not cancel a subscription. Manage those separately through Apple.

10. Your choices and privacy rights

• Use the ordinary diary without creating a MED Diary account.
• Enable or leave off encrypted Backup & Sync, and choose whether its continuity key may use iCloud Keychain.
• After a legacy installation converts to local-only storage, delete the retained pre-migration iCloud copy from Backup & Sync settings.
• Grant or withdraw Apple Health permissions in iOS Settings.
• Choose whether to use AI, Speak Meal, food search, or barcode lookup; enter the same information manually instead; redact lab details; inspect a lab upload; and decline before sending.
• Select Shared Access categories, revoke a caregiver, or delete the Shared Access account.
• Export your complete underlying diary and use Delete My Data to erase all real profiles and deletable local app data across MED Diary devices signed in to the same Apple Account, the server-side AI-use ledger and credential, and—when signed in—the Shared Access account data. The App Store app-account token remains only when StoreKit reports verified purchase history, as described above.
• Manage or cancel Premium in your Apple subscription settings.

Depending on where you live, you may have rights to request access, correction, deletion, restriction, portability, or objection for personal data held by our server, and to complain to a privacy regulator. Email support@meddiary.app. We may need information to verify that the request relates to you. MED Diary cannot retrieve readable diary content from your device or decrypt your sealed mailbox on your behalf.

11. Security, children, transfers, and changes

Security

We use platform protections, encrypted network connections, access controls, rate limits, short-lived server sessions, authenticated client-side encryption for Backup & Sync, and separate end-to-end encryption for Shared Access content. No storage or transmission method is perfectly secure. Protect your devices, Apple Account, Recovery Key, full Shared Access invites and keys, and exported files, and contact us if you believe something has gone wrong.

Children

MED Diary is not directed to children under 13. A parent or legal guardian who uses MED Diary to track a dependent's information is responsible for doing so lawfully and appropriately. If you believe a child submitted server-held personal data without appropriate permission, contact us.

International processing

Our service providers may process data in countries other than your own. Those countries may have different data-protection laws. We use provider contracts and safeguards appropriate to the service and applicable law.

Policy changes

We may update this policy as MED Diary changes. We will change the date above and, when a change is material, provide a prominent notice in the app, on the website, or both before it takes effect where required.