What Emenla collects, which is almost nothing, and the one exception.

Emenla is a symptom diary for people living with endometriosis. This policy explains what happens to what you write in it.

The short version: your symptom record stays on your phone. Emenla has no analytics. Emenla needs an account to open, and that account holds your email address. Your symptoms, period dates, body map and notes never reach it.

Two features are exceptions and they are worth knowing before you use them: if you ask Nutrition to read a meal from a photograph, that photograph is sent to OpenAI to be read, and four nutrition figures come back and are stored against your account. And if you talk to the assistant, what you write to it is sent to OpenAI to be read so it can answer you, and when a question needs something current, like the weather, OpenAI may search the web for it. We do not store the photograph or your messages. Sections 1 and 4 set out exactly what happens; if you use neither, nothing about your body ever leaves your phone. A third feature involves your calendar and not us: if you let Emenla put a confirmed appointment into your calendar, it goes to the calendar app on your phone, or, if you choose Google Calendar, to Google's own page with its title and time, and a calendar can sync to iCloud or to Google and can be shared with other people. Nothing about it reaches us, and Emenla cannot read your calendar at all. If you choose to buy summary export, Apple and RevenueCat process that purchase, and they do not receive your symptom record either.

1. What we collect

Your symptom record stays on your phone. Two features are exceptions, the meal reading and the assistant, and both are described in full in section 4 rather than buried.

Emenla does not collect, receive, transmit or store your symptoms, your period dates, your body map, your notes, your cycle history, or the clinical terms the app works out from them. There is no server that holds any of it. That is not a promise about careful handling; we never have it.

What we do hold is your email address, four nutrition figures per meal you scan if you use the meal reading in Nutrition, a timestamp for each message you send the assistant (so we can keep a daily limit on it; not what you wrote), and any feedback you choose to write to us. That is the entire list.

The meal reading is the exception, and it involves a photograph leaving your phone. If you ask Emenla to read a meal from a photo, that photo is sent to OpenAI to be read, and four figures come back: energy, protein, carbohydrate and fat, with how confident the reading was. Those figures are stored, tied to your account. We do not store the photograph itself. On our side it exists for the length of one request and is not written to any database, any file store, or any log. Section 4 says what OpenAI may keep. Section 4 sets out the whole path, and section 7 explains why nutrition figures count as health data in law and what that obliges us to do.

The assistant is the second exception, and it involves your messages leaving your phone. If you write to the assistant and agree to the notice it shows before your first message, what you write is sent to OpenAI to be read so it can answer you, and a question that needs the web may be searched for. We do not store your messages. Section 4 sets out the whole path, including what a search is and what it is not allowed to carry.

Nothing else about your body goes anywhere. If you use neither the meal reading nor the assistant, nothing you record ever leaves your phone at all.

Emenla asks you to create an account before you can use it, with an email address, or through Apple or Google. What that account is for: it gives you a name to come back to, and it is what will make the Community section possible later.

The account does not sync, back up, restore or transmit your symptom record. Everything you record about your body is written to your phone and stays there whether you are signed in, signed out, or offline. The one thing the account carries beyond your address is the meal-reading figures described above, and only for meals you choose to scan.

If you sign in with Apple, Apple's Hide My Email will give us a relay address instead of your real one, and Emenla works exactly the same way with it.

The limited purchase information described in section 5a is handled by Apple and RevenueCat, and is not attached to an Emenla account.

2. What the app stores, and where

Everything you enter is written to a database inside the app's own private storage on your device, protected by your device's operating system and its encryption. That includes:

• Symptoms you log, their severity, and anything you write or dictate in your own words
• Period start and end dates you record
• Treatments, tests, appointment questions and anything you note about them
• What you did during a flare, and how you rated it
• Days you record as lost to symptoms
• Meals and any photographs you attach
• Your name, if you choose to give one, and your onboarding answers
• Your reminder preference

None of it leaves your device unless you deliberately export or share it, or use the meal reading. See section 4.

3. Voice, photographs and the camera

• Voice. If you dictate an entry, speech is transcribed using the speech recognition built into your device, configured to run on-device only. Your audio is not uploaded, and no recording is kept after the transcription.
• Photographs you attach. Photographs you attach to a meal, a test result, a letter or a prescription are copied into the app's private storage. They are not written back to your photo library, and "Delete everything" removes the copies. They are not uploaded anywhere, with the single exception in the next line.
• Photographs you ask us to read. If you use the meal reading in Nutrition, that one photograph is sent to OpenAI to be read, and we do not store it (sections 1 and 4). It is the only photograph that ever leaves your phone, it only happens when you tap to scan a meal, and the copy kept on your phone is unaffected.
• Choosing from your photos. If you allow photo access, Emenla reads your most recent photos so it can show them inside the app for you to pick from. Nothing is copied until you choose one, and nothing about the others is kept or read beyond what is needed to display them. If you allow access to selected photos only, that is what is shown. If you decline, the phone's own photo picker opens instead, which shows Emenla only the one photo you select.
• Camera and photo library access are requested only at the moment you choose to add a photo, and are used for nothing else.
• Calendar access is add-only. Emenla asks iOS for permission to add an event and not to read one, which is a separate, narrower permission that iOS grants on its own ("write-only" access). Nothing already in your calendar is visible to the app: not an event, not a title, not a time, not who else is on it. It is requested only when you ask for it, which means when you choose the calendar on your phone under Settings → Calendar or the first time you put an appointment into it, and it is used for nothing else. Choosing Google Calendar instead needs no permission from iOS at all. You can change it at any time in Settings › Apps › Emenla, and Settings → What Emenla can reach inside the app shows you what iOS has answered.

4. When information leaves your device, and how

Only when you choose, and only in ways you start:

• The doctor summary. When you create a summary, Emenla builds a PDF on your device and hands it to your operating system's share sheet. You choose what happens next: printing it, saving it, emailing it, sending it to a clinician. Once you hand it to another app or service, that app's own privacy policy applies, not ours.
• The data export. Settings offers an export of everything you have recorded, as a file. The same applies: where it goes next is your choice.

We are not a party to either. We do not receive a copy, and we are not notified that it happened.

• Creating or using an account. Your email address and the sign-in itself go to Supabase, which hosts the account for us on servers in Frankfurt, Germany. Nothing else goes with it.

If you sign in with Apple or Google, that company confirms your identity to us and learns that you signed in to Emenla, in the same way it would for any app you use it on. We receive an identifier and an email address from them, and nothing more: not your contacts, not your other apps, not anything about your health.

Apple's Hide My Email is fully supported. If you use it, Apple gives us a forwarding address instead of your real one and Emenla works exactly the same way. We never see the address behind it.

• Reading a meal from a photograph. This is the one feature that sends a picture of something about your body off your phone, and it only runs when you ask it to. Before the first photograph goes, the app shows you a notice in the same place saying where it goes and who reads it, with "Read the photo" and "Not now". If you choose "Not now", the meal is saved exactly as it would be otherwise and nothing is sent.

The photograph goes, over an encrypted connection, to a small program we run on Supabase in Frankfurt, Germany, which passes it to OpenAI to be read. OpenAI returns four figures (energy, protein, carbohydrate and fat) and how confident it was. Those figures are stored against your account in Frankfurt so the same meal reads the same way on another device. The meal's name, the time of day, your cycle day and everything else about the meal stay on your phone.

We do not store the photograph. It is not written to any database, any file store or any log on our side, and the copy on your phone is unaffected. OpenAI reads it as our processor, under a data processing agreement, and does not use it to train its models. Under OpenAI's own policy its abuse monitoring may keep a copy for up to 30 days before deleting it, and we cannot reach or read that copy.

We have a data processing agreement with OpenAI covering this. If you would rather no photograph ever left your phone, turn the meal reading off under Settings → What Emenla can reach, where it sits beside everything else the app may reach. Every other part of Nutrition, and all of the rest of the app, works without it.

• Talking to the assistant. Emenla has an assistant you can write or speak to about anything: how you are, endometriosis, an everyday question like the weather, or something to log. It only sends anything after you have agreed to a notice in the conversation that says where your messages go. If you choose "Not now", your messages are read on your phone instead and nothing is sent. Once you have agreed, you can take that agreement back at any time under Settings → What Emenla can reach.

When you write to it, your message goes, over an encrypted connection, to a small program we run on Supabase in Frankfurt, Germany, which passes it to OpenAI to be read and answered. With it go the last few messages of the same conversation, so the answer makes sense; your first name, if you have given one; the names of the symptoms in your list, so it can file what you say under one of them; your phone's date, time and time zone, so "Friday at 8pm" lands on the right day; and the country your phone's region is set to, so a question like the weather starts from the right place. That is your phone's settings, not your whereabouts: Emenla does not read where you are, and when a question needs a town, the assistant asks you which one. Your record is not sent: not your entries, your period dates, your body map or your notes.

We do not store your messages. They are not written to any database, any file store or any log on our side. The only thing we write is a timestamp for each message, tied to your account, so we can keep a daily limit on the assistant; it does not say what you wrote. OpenAI reads your messages as our processor, under the same data processing agreement as the meal reading, and does not use them to train its models. Under OpenAI's own policy its abuse monitoring may keep a copy for up to 30 days before deleting it, and we cannot reach or read that copy.

When a question needs the web. For something current, like the weather or a shop's opening hours, OpenAI may search the web to answer, and the answer lists the pages it used; a page you open from that list opens in your browser, and Emenla does not see what you do there. A search is written by OpenAI's model from your message and sent by OpenAI to the search providers it works with, whose own retention rules then apply to it. That is not covered by the promise above that your messages are not kept, and no one at Emenla sees a search, before or after it is sent. So we do two things, and we do not claim more than they do. We tell the model never to put your name, your health, a symptom, a medicine or anything about your body into a search. And our server does not offer it the web at all for a message that mentions your health, a condition or one of your symptoms: that message is answered without searching. The number of searches is also limited each day.

Nothing the assistant suggests is saved on its own. If you tell it about a symptom, a meal or your period, it shows you a card, and only your tap on Save writes it, to your phone, like anything else you log. The assistant gives no diagnosis and no medical advice (section 12).

• Putting an appointment in your calendar. If you confirm an appointment in Emenla, the app can add it to a calendar you choose. Nothing about it reaches us. There are two ways, you pick one the first time, and you can change it under Settings → Calendar; Emenla remembers your choice on your phone only.

The calendar on your phone. Once you have allowed it, saving the appointment's card adds the event to your phone's default calendar, with the title, day and time the card showed you before you tapped Save. That default is set under iOS Settings › Apps › Calendar, and it may be an iCloud, Google or other account you have added to your phone. A title that mentions your body or your health is never added unseen: for that one, your calendar's own screen opens first with the details filled in, so you can change the title, choose which calendar it goes on, and tap Add yourself. If you close that screen, nothing is added. Emenla sends nothing over the internet for this; your phone's calendar does its own syncing.

Google Calendar's own page. If you choose Google Calendar, Emenla opens Google's new-event page, in your browser or in Google's app, with the title and the time filled in. Opening that page sends the title and the time to Google, because they are part of its address, and nothing else goes with them: no notes, no place, no one else invited. The event is added only when you tap Save on Google's page, under your own Google sign-in, and Emenla cannot see whether you did. Emenla does not sign in to your Google account and holds no password, token or account of yours with Google or any other calendar provider. If the title mentions your body or your health, Google is sent "Appointment" instead, and the card says so before you save.

What we cannot do is read it. Emenla asks iOS only for permission to add an event (section 3), so the app cannot see what is already in your calendar, cannot see the event afterwards, and cannot delete it, and it has no access to your Google Calendar at all. That last point is worth knowing: if you undo the appointment inside Emenla, our own copy of it goes, and the calendar entry stays. The app tells you so, and you can delete it in your calendar.

Where it can end up is up to your phone and your calendar, not us. A calendar may sync to iCloud, or to a Google account or another account, and some calendars are shared with other people. That is between you, your phone and whichever of those you use; we are not a party to it. The title of the event is the wording from your own appointment. We do not add your condition, a symptom or anything clinical to it, and the card shows you that wording, and lets you change it, before anything is saved.

If you would rather keep appointments inside Emenla only, choose Ask each time under Settings → Calendar, and every appointment gives you that option. The appointment is already saved in Emenla before your calendar is mentioned.

• Feedback you write to us. Settings has a page where you can tell us what is missing, confusing or broken. If you send something there, it goes to Supabase in Frankfurt, Germany, and it is visible only to you and to us.

What goes with it: what you wrote, your email address, and four things about your phone: the version of Emenla, the version of iOS, your iPhone model, and your language. That is the whole list, and the app shows you those four before you send.

Nothing from your record is attached, ever. Not an entry, not a symptom, not a date, not a photograph, not a summary. Emenla does not read your record when you write to us and there is nowhere on our side for any of it to go.

You are of course free to describe your own health in a message if that is what you want to tell us about; it is your message. We handle everything written there as sensitive on that basis. We never ask you to. You cannot delete a single message from inside the app: write to us and we will delete it, or delete your account, which deletes every message with it.

What never leaves, on any path, is your symptom record. Not your symptoms, your period dates, your body map, your notes, or the clinical terms the app works out from them. Not in the account, not in the sign-in, not in a background sync, and not in a crash report. There is no code in Emenla that sends any of it anywhere, and section 5b lists what else the app deliberately does not do.

The things you can send yourself are a message you write to us, what you write to the assistant, and an appointment you choose to put in your calendar, all described above. That is you choosing to send something, not the app sending your record.

5. Purchases and what Emenla does not do

5a. Optional summary-export purchase

Symptom logging is free. If you choose to purchase summary export, the app uses Apple In-App Purchase and RevenueCat to show the available plans, complete or restore the purchase, and check whether the device has access to summary export. RevenueCat receives an anonymous app-user identifier, purchase and subscription status, store transaction information, and technical information needed to operate the purchase service. It does not receive your symptoms, cycle dates, notes, photographs, PDF contents, name, or onboarding answers.

Apple and RevenueCat process this information under their own privacy terms. RevenueCat's public SDK key is included in the app only to identify Emenla's purchase project; it is not a secret key and cannot access RevenueCat's administrative account.

5b. What Emenla does not do

• No analytics or usage tracking of any kind
• No advertising, and no advertising identifiers
• No third-party trackers, marketing SDKs or social media SDKs. RevenueCat is used only for the optional purchase flow described above.
• No crash reporting service
• No remote configuration and no content fetched from a server
• No selling, sharing or disclosure of personal information. If you make an account we hold your email address, and we do not sell, share or disclose that either.
• No profiling, and no automated decision making

Emenla does not ask for permission to track you across other apps and websites, because it does not do so.

6. Notifications

If you turn on the daily reminder, it is scheduled locally on your device by the operating system. No push notification service is involved and no device token is created, so we cannot send you anything and cannot tell whether you use the app.

7. Your rights over your data

Almost none of your health record reaches us, so for almost all of it we cannot access, correct, export or delete anything on your behalf. You hold it directly. The exception is the meal-reading figures described in sections 1 and 4, and section 11 says how to reach us about those.

• Access and portability. Settings offers a full export: a single JSON file holding every record the app stores. Photographs you attached are referenced by their location on the device rather than embedded in that file; they stay in the app's private storage, and are removed when you delete.
• Correction. Every entry can be edited or deleted in the app.
• Withdrawing consent. Settings → What Emenla can reach lists everything the app may reach, sorted by whether it stays on the phone or leaves it, and holds the switch for each of the two things that leave: the assistant and the meal reading. Turning one off takes effect immediately and takes no more taps than turning it on did.
• Erasure. Settings offers a delete-everything option, behind a double confirmation. It erases every record the app holds, every photograph you attached, and any export file still sitting in the app's cache. The database file itself remains on the device, emptied.
• Deleting the app also removes its private storage, and with it everything you recorded.
• Deleting your account. The same delete-everything option in Settings deletes your Emenla account, your email address and every meal-reading figure along with everything else, from inside the app, without asking us. It deletes the account first: if it cannot reach the server, it stops and deletes nothing, so you are never left with an emptied phone and an account still on file.

For the personal data we do hold (your email address, your meal-reading figures and any feedback you send), the GDPR and the UK GDPR give you the right to access it, to correct it, to have it erased, to restrict how we use it, to object to our using it, and to take it with you. Write to us at the address in section 11 and we will answer within one month.

You also have the right to complain to a data protection authority. In Poland that is the President of the Personal Data Protection Office (Prezes Urzędu Ochrony Danych Osobowych, uodo.gov.pl). You may also complain in the country where you live or work.

The two halves of this policy sit under two different articles of the GDPR, and the distinction is the reason Emenla is built the way it is.

• What you record about your body is health information, a special category of personal data under Article 9. For your symptoms, period dates, body map, notes and the clinical terms derived from them, we are not a controller, because we never receive them. Your rights over that half are exercised through the app rather than by contacting us, and it is built that way on purpose: Article 9 data carries obligations a server attracts the moment it holds any, and the simplest way to meet them completely is not to hold it.
• The meal-reading figures are the one place we hold Article 9 data, and we count them as exactly that rather than pretending four numbers are something lesser. We are a controller of them. Our lawful basis is your explicit consent under Article 9(2)(a), given through the notice the app shows before the first photograph is read; you can withdraw it at any time under Settings → What Emenla can reach, and deleting your account deletes every figure with it. OpenAI is our processor for the reading itself, under a data processing agreement; section 4 says what it may keep and for how long.
• Messages you send the assistant are processed as Article 9 data too, because what you tell it about your body is health data whatever form it takes. We process them only for the length of one request and do not store them. Our lawful basis is your explicit consent under Article 9(2)(a), given through the notice the assistant shows before your first message; you can withdraw it at any time under Settings → What Emenla can reach, or by choosing "Not now" when you are asked. OpenAI is our processor for reading and answering them. A web search it runs for a question that carries none of your health (section 4) is sent on to a search provider under that provider's own terms.
• Your email address is ordinary personal data under Article 6. Here too we are a controller. Our lawful basis is the contract between us: the account is how you get into the app and how you get back into it. You can see it, correct it by changing it, or delete it in the app at any time, and section 11 says how to reach us if you would rather ask a person.

Supabase acts as our processor for the account, the meal-reading figures and the assistant's daily-limit timestamps, under a data processing agreement, on servers in the EU. OpenAI acts as our processor for the meal reading and for the assistant. Google is not our processor for calendars: if you choose Google Calendar for an appointment, the title and time go to Google from its own page, under your own Google account, and we receive nothing back (section 4).

8. Children

You must be 13 or older to use Emenla, which matches its App Store age rating, and anyone under 18 needs the agreement of a parent or guardian. Endometriosis symptoms often begin in adolescence, and we did not want to shut younger people out of a record of their own symptoms; everything recorded stays on the device on the same terms as for anyone else.

The meal reading and the assistant need a parent's or guardian's consent below 16. They are the two features that rely on consent to process health information, and 16 is the age Polish law sets for giving that consent yourself.

9. Security

Your entries live in the app's private storage, which the operating system isolates from other apps and protects with device encryption when your device has a passcode set. We strongly recommend using a device passcode, Face ID or Touch ID. Emenla also has its own App lock, off by default, which asks iOS to check Face ID, Touch ID or your passcode when you come back to the app. iOS does the checking on the device; Emenla only learns whether it passed, and never receives biometric data. Because Emenla holds no copy of your data, anyone with unlocked physical access to your device can read what is in the app.

If you create an account with an email and a password, that password is never stored anywhere in readable form: not on your device and not by us. Signing in with Apple or Google means there is no Emenla password at all, which is the safer of the two and why those come first on the screen.

What we hold is deliberately small. An attacker who got through us would reach a list of email addresses and, for people who use the meal reading, rows of four nutrition figures. That is all there is. Your symptoms, your period dates, your body map, your notes and your photographs are not in it and never have been, because they are not on any server of ours.

Every row we hold is protected by row-level security, meaning the database itself refuses to return one account's rows to another account, rather than relying on the app to ask the right question.

10. Changes to this policy

If this policy changes, the updated version will be posted here with a new date at the top. If Emenla adds anything that sends health information off your phone, it will be described here plainly before it is available, and it will be something you turn on, never something already on.

11. Contact

Emenla is made and operated in Poland. The controller of the personal data this policy describes can be reached at the address below.

Questions about this policy or about Emenla, and requests under any of the rights in section 7:

hello@emenla.com

12. Medical disclaimer

Emenla is not a medical device and does not provide medical advice, diagnosis or treatment. It documents and organises what you record and helps you present it. It never interprets your symptoms and never suggests what they mean. Always speak to a qualified healthcare professional about your health.

13. This website

This policy also covers emenla.com, which is built to make the same promise the app makes.

• No traffic measurement. There is no analytics script on the site, first-party or otherwise.
• No cookies, and so no cookie banner, because there is nothing to consent to. No embedded videos from other sites, no social buttons, no advertising pixels, no reCAPTCHA and no session recording.
• Fonts and video are served from the site's own domain, so your browser does not contact a font provider or a video platform.
• No forms. There is no sign-up field, no waitlist and no newsletter, so the site holds no addresses. If a form is ever added, this section will say which service receives what you type, what it is used for and how to have it removed, before the form goes live.
• Hosting. The site is hosted by Cloudflare. Like every web host, Cloudflare processes your IP address in order to deliver the page, and may keep short-lived server logs under its own terms.
• Email. Mail sent to hello@emenla.com is delivered to us through Cloudflare Email Routing. We keep a message for as long as we need to answer you and deal with what you asked, and delete it sooner if you ask.
• Links to other sites. Citations link to organisations such as the World Health Organization, ESHRE, NICE, ACOG and PubMed, whose pages have their own privacy terms.