Cycle tracking & fertility prediction (digital contraception)

Millions of women track their cycle in apps. A small subset of products goes further: they use temperature and cycle data to tell users on which days unprotected sex carries a pregnancy risk, and are regulated as medical devices (contraception) with clinical studies. The same models support conception planning and flag irregular cycles. The AI is statistically simple but the regulation, validation and especially the data protection of reproductive-health data are demanding, so the buy-or-certify decision matters more than the model choice.

Problem & value

• Today: calendar methods (rhythm), paper charts of basal body temperature (BBT), ovulation strips, or hormonal/barrier contraception. Calendar apps assume a regular cycle and are unreliable for women with variable cycles; manual BBT charting is tedious and error-prone (illness, alcohol, sleep shifts distort readings).
• AI value: personalised, probabilistic ovulation detection from noisy, sparse signals; automatic use of overnight wearable temperature (no morning routine); detection of anovulatory cycles; a hormone-free contraception option for users who cannot or do not want hormonal methods; and structured data for a doctor visit.
• Evidence: the leading product, Natural Cycles, obtained FDA De Novo authorisation (2018) as a contraceptive app and is CE-marked in the EU; its published studies report Pearl Index values for perfect and typical use [1][2]. Typical-use failure rates of fertility-awareness methods are materially higher than for LARC or the pill, because users have unprotected sex on predicted "safe" days and because of prediction error; consumers must be told this clearly. Figures differ by study and method; check the current labelling of a specific product rather than quoting headline numbers.

Variants

• Digital contraception (certified): medical-device app, optionally with a thermometer or wearable band; the strictest regulatory path.
• Conception planning: same fertile-window model, goal "get pregnant"; lower safety stakes.
• Cycle awareness / health insights: period prediction, symptom logging, no clinical claims (wellness category).
• Perimenopause and PCOS support: anomaly detection and symptom tracking; clinical claims again trigger device rules.
• Clinical/research: cohort studies using wearable-derived cycle data (e.g. Apple Women's Health Study); employer or insurer programmes (privacy-critical, see Risks).
• Wearable data side: see PERS-002; interpreting resulting lab/health records: PERS-014.

How it works

1. sensors (BBT thermometer / wearable night temperature, LH strips) + manual logs
2. data cleaning (sleep-window alignment, outlier removal, missing-data handling)
3. personal baseline model (temperature shift detection, e.g. biphasic pattern)
4. ovulation estimation + fertile-window probability (statistical / ML, personalised)
5. decision layer (conservative rules: uncertainty
6. "use protection" day)
7. user feedback (red/green day, explanation) + retrospective ovulation confirmation
8. anomaly flagging
9. "talk to a doctor" (no diagnosis)

• Models: mostly time-series / Bayesian / gradient-boosted models on small tabular data, not LLMs. The core algorithm must be deterministic, versioned and validated; it runs comfortably on a phone (edge-runtime), which also enables privacy-preserving on-device operation.
• Conservative design: a contraceptive tool should classify uncertain days as fertile. More red days is the safe error. Early cycles with little personal data get many red days.
• LLM layer (optional): explanations, chat about symptoms, doctor-report summaries. It must be separated from the validated prediction logic; an LLM must never compute or override fertility status.
• Human-in-the-loop: user confirms data entry; ovulation confirmation by test strips or ultrasound in doubtful cases; clinician for anomalies; regulator-reviewed labelling.

Data preparation

This is the most data-heavy of the four cases. Data comes from the user: daily temperature or wearable skin temperature, period dates, symptoms, ovulation tests, medication; for companies it also sits in app databases, wearable clouds and health platforms. Typical gaps: missed days, irregular measurement times, illness or alcohol distorting temperature, unreliable self-reports, few cycles per user, and different units across devices. Everything is a special category of data under Art. 9 GDPR. Preparation steps: (1) agree the legal basis and explicit consent (PREP-025); (2) clean time series: remove outliers, mark disturbed nights, align time zones; (3) pseudonymise user IDs and separate identity from health data (PREP-022); (4) restructure into tidy per-cycle tables with outcome labels such as confirmed ovulation (PREP-011, PREP-020); (5) build an evaluation set with clinicians and balanced for age, PCOS and irregular cycles (PREP-018); (6) collect user feedback on mispredictions (PREP-021). Rough share of effort: 50-60 percent of the project, because label quality limits accuracy. GUIDE-003 describes the readiness check, and PREP-005 covers exporting data from wearables and SaaS platforms.

Implementation paths

Which path for whom

• Private: Path A. Cycle prediction used for contraception can be a medical device, so a certified, EU-based app with transparent privacy terms is the safe choice; look for apps that process data on the device.
• Developer: Path B. Building on cloud APIs and EU-hosted infrastructure speeds up prototyping, but a product claiming contraception needs conformity assessment as a medical device.
• Enterprise: Path B. Insurers, employers' health programmes or femtech companies integrate prediction into their own platform with strict separation and pseudonymisation of health data.

Path A — Buy / use certified product (recommended)

• Contraceptive, certified: Natural Cycles (Sweden/Switzerland - EU-based; FDA-authorised, CE-marked, integrations with Oura and Apple Watch for temperature input); Daysy (Switzerland/EU market, CE-marked fertility tracker with thermometer). Check current certification scope and intended use in each country.
• Cycle tracking / wellness: Clue (Berlin, EU; position as privacy-conscious, EU-law based), Flo, Apple Health Cycle Tracking, Oura cycle insights, Garmin/Fitbit/Samsung cycle features. Intended use is mostly non-contraceptive; read the disclaimers.
• Choose A: always for private users and for any company that wants to offer this to customers without becoming a medical-device manufacturer (partner/white-label, or integrate data via APIs such as Oura API or Apple HealthKit with user consent).

Path B — Build on cloud APIs

• Wearable data via Oura API, Apple HealthKit (on device), Garmin Health API, Google Health Connect.
• Use an LLM API (EU regions or EU providers such as Mistral) only for the explanation/chat layer on pseudonymised data under a data-processing agreement, with health-data safeguards.
• A wellness-only app (period prediction, patterns) is feasible; do not market it as contraception unless it is certified.

Path C — Self-host (open source)

• Open-source trackers: Drip (Bloodyhealth, Berlin; local-only storage, symptothermal method implementation), plus self-built dashboards on Home Assistant or Open Wearables-style ingestion of exports.
• Stack: Python (statsmodels, scikit-learn, PyMC/Stan for Bayesian changepoint models), SQLite on device; small open-weight LLM (HW1 laptop/phone class, e.g. Llama, Qwen, Gemma small variants via llama.cpp/Ollama) for local explanations. See PERS-005.
• Not a medical device; for personal experimentation, education, research.

Path D — Custom training

Training your own ovulation models requires large, labelled cycle datasets with ground truth (LH surge, ultrasound, hormone assays) - typically collected in clinical studies. Realistic only for medical-device manufacturers, universities and wearable vendors. Plan a clinical validation study (Pearl Index, ovulation-detection accuracy) and a quality system (ISO 13485, IEC 62304) from the start.

State of the art (2026)

• Wearable temperature (ring/watch, distal skin temperature at night) now supports ovulation detection comparable in many studies to BBT, with less effort; peer-reviewed validation comparisons exist for Oura and Apple Watch-based detection (search PubMed for current studies). Accuracy drops with irregular cycles, shift work, illness, travel across time zones and postpartum/perimenopause.
• Personalised Bayesian/ML models over population priors are standard; large datasets of consenting users (millions of cycles) are the main competitive moat of the leading apps.
• Clinical evidence is mostly from company-sponsored, observational (non-randomised) studies; regulators and critics point out reporting, dropout and self-selection biases. Regulators (e.g. UK MHRA, Swedish authorities) have previously investigated unintended-pregnancy reports linked to fertility apps.
• LLM assistants add chat-style explanations and symptom Q&A; reliability for medical advice remains limited - hallucination and sycophancy risks.
• Limits: no method protects against STIs; typical-use effectiveness depends on behaviour; temperature signals are confounded; models are less validated for adolescents, PCOS, breastfeeding and perimenopause.

Shared resources & combinations

• Shared data pipelines with PERS-002 (wearable ingestion: Oura, HealthKit, Health Connect, time-series features) and PERS-005 (local AI on own hardware).
• Combinations: PERS-014 (explain lab and ultrasound results and ePA content), PERS-016 (use GDPR rights to export or delete data from cycle apps), PERS-017 (lifelogging; same sensitivity).
• Same time-series and anomaly-detection building blocks as other wearable/health monitoring use cases.

Effort, cost & KPIs

• Path A: minutes to set up; consumer subscriptions (typically tens of euros per year for premium plans - verify current prices).
• Path B/C (wellness app): weeks to a few months for a small team; cost drivers are data quality, privacy engineering and app-store compliance.
• Path D (certified device): many months to years and substantial budget (clinical study, QMS, notified body conformity assessment, post-market surveillance).
• KPIs: Pearl Index (perfect/typical use), ovulation-detection accuracy vs. LH/ultrasound, share of red days (usability vs. safety), cycle-prediction error in days, retention, number of reported unintended pregnancies, data-subject requests handled.

People & change

Involve management early because liability and regulation (medical device rules, AI Act high-risk classification) shape the whole project. Bring in the DPO and legal at the start, not at the end: Art. 9 GDPR special-category data makes a DPIA under Art. 35 mandatory in practice, plus processor agreements with every cloud and wearable vendor (GUIDE-005). IT security protects the health data and handles access rights (GUIDE-013). Works council: depends. A consumer product needs none; if an employer offers the tool in a wellness programme or analyses employee data, section 87(1) no. 6 BetrVG applies and the works council must also be informed under section 90(1) no. 3 (GUIDE-004); employers should never see individual data. AI literacy: Art. 4 AI Act asks providers and deployers to support staff's AI literacy, so train support and product teams on prediction uncertainty and wording (GUIDE-006). Pilot with a small opt-in group and clinical advisers, and plan the high-risk duties for Annex III cases from 2 Dec 2027 (GUIDE-014). Typical concerns are intimate data misuse and false security in contraception: use clear uncertainty messages, local processing, easy deletion and a human clinician route for abnormalities.

Risks, regulation & compliance

• EU MDR (Regulation 2017/745): software with a contraceptive or diagnostic intended purpose is a medical device, typically class IIa/IIb (rule 11, plus contraception-related rules), needing a notified body, clinical evaluation and post-market surveillance. A mere "cycle diary" without medical claims is not. Marketing language decides the classification [4].
• EU AI Act (Regulation 2024/1689): AI systems that are medical devices requiring third-party conformity assessment are high-risk under Art. 6(1)/Annex I (MDR); high-risk obligations for this Annex I route apply later than for Annex III systems (check the current timeline, including any "digital omnibus" changes). Wellness-only apps are minimal/limited risk. No Art. 5 prohibition applies, but inferring pregnancy or emotional state for employers or insurers would be a serious abuse and, in workplace settings, may conflict with Art. 5 (emotion inference) and employment law.
• GDPR: cycle data is health data (Art. 9) - explicit consent, DPIA, data minimisation, EU processing/hosting, strict controls on third-party SDKs and analytics. Enforcement precedent: the US FTC action against Flo Health (2021) over sharing health data with advertisers [5]; after the Dobbs decision (2022), concerns grew that data could be used against users in jurisdictions that criminalise abortion, so avoid US-jurisdiction exposure where possible, use on-device processing, end-to-end encryption and anonymous modes.
• Employer/insurer programmes: do not offer to employers or insurers identifiable data; aggregate only.
• Other risks: false sense of security, STI risk, accessibility for minors, discrimination, security breaches of intimate data.
• Mitigations: conservative decision logic, clear labelling, on-device processing, no advertising SDKs, deletion on request, independent privacy review (e.g. Mozilla's "Privacy Not Included" style audits).

Getting started

1. Decide the goal: awareness, conception or contraception; only certified products for the latter.
2. Check certification (CE/UKCA/FDA scope, notified body, Pearl Index in the labelling).
3. Inspect privacy: where data is stored, SDKs, anonymous mode, deletion and export options (use PERS-016).
4. For builders: start with a wellness-only prototype on exported wearable data and an on-device model, compared against LH-test ground truth; consult a regulatory expert before any medical claim.
5. Share cycle reports with a clinician in cases of irregularity; do not self-diagnose.

Sources

1. U.S. FDA - De Novo decision for Natural Cycles (DEN170052), 2018 - https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfpmn/denovo.cfm?id=DEN170052
2. Natural Cycles - clinical studies and regulatory information - https://www.naturalcycles.com/science
3. Harvard T.H. Chan School of Public Health - Apple Women's Health Study - https://www.hsph.harvard.edu/apple-womens-health-study/
4. Regulation (EU) 2017/745 (Medical Device Regulation) - https://eur-lex.europa.eu/eli/reg/2017/745/oj
5. U.S. FTC - Flo Health settlement over sharing of health data (2021) - search ftc.gov for "Flo Health" - https://www.ftc.gov/news-events/news/press-releases/2021/01/developer-popular-womens-fertility-tracking-app-settles-ftc-allegations-it-misled-consumers-about
6. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. Drip open-source period tracker - https://gitlab.com/bloodyhealth/drip
8. Oura API documentation - https://cloud.ouraring.com/docs