alex/temperature-based-fertility-prediction-thesis
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

further work on introduction

Browse Source
This commit is contained in:
Alex Blank
2025-08-04 15:05:48 +00:00
parent 18c4f3eba9
commit b63dcfcc9b
14 changed files with 2377 additions and 2441 deletions
Download Patch File Download Diff File Expand all files Collapse all files
thesis/sections/methodology.tex
+68 -79
View File
@@ -4,22 +4,18 @@
\section{Methodology}\label{sec:methodology}
While prior studies have demonstrated the promise of physiological signals for ovulation detection and phase classification,
many are limited by small sample sizes, rigid inclusion criteria, or non-transparent methodologies.
Temperature has emerged as a potentially predictive signal, but existing work often lacks scalability or generalizability.
This study extends previous approaches by leveraging a large, heterogeneous real-world dataset of high-resolution core body temperature
readings to develop and evaluate machine learning models for real-time ovulation prediction.
In addition to model development, special emphasis is placed on evaluating performance across irregular cycles and assessing
the predictive value of low-noise, high-resolution temperature data.
The following section outlines the methodology used, including data preprocessing,
feature extraction, input encoding, and model architectures.
% why did I select tft over other methods -> include examples of time series and why I belief a complex model could help
% you did I apply it
% implementation details
Despite promising results in earlier studies, ovulation prediction remains constrained by small datasets,
assumptions of cycle regularity, and opaque modeling approaches.
To address these limitations, we develop a data-driven framework based on a large,
heterogeneous dataset of real-world menstrual cycles.
Our approach emphasizes model transparency, adaptability to irregular patterns, and the predictive utility of
high-resolution core body temperature measurements.
This section outlines the methodology used, including preprocessing, labeling, feature extraction, and model architectures.
\subsection{Data Preprocessing}\label{subsec:data_preprocessing}
This section outlines the preprocessing steps applied to the raw temperature data,
including cycle filtering and retrospective ovulation labeling.
These steps ensure that only clean, complete, and labeled cycles are used for model training.
\subsubsection{Data Filtering}\label{subsubsec:data_filtering}
@@ -53,15 +49,15 @@ The algorithm operates in two stages:
\end{enumerate}
This retrospective labeling provides a practical and scalable proxy for ground truth, enabling training and evaluation across a large, real-world dataset,
especially, as temperature is at least an excellent retrospective marker for ovulation.
particularly given that temperature is a well-established retrospective marker of ovulation.
In internal evaluations, the estimated ovulation day fell within a \(\pm\)2-day window of the expert reference in approximately 86\% of labeled cycles.
These labels serve as the supervisory signal for model training and evaluation.
We acknowledge the limitations of this method: ambiguous or noisy temperature patterns—due to illness, dropout,
or sensor error—can lead to mislabeled examples, which may propagate to downstream models.
We acknowledge the limitations of this method: ambiguous or noisy temperature patterns, due to illness, dropout,
or sensor error, may result in noisy labels, which can affect downstream model performance.
However, label quality is continuously reviewed and may be refined iteratively as model performance improves.
The specific usage of ovulation labels in feature construction is described in the next section.
The next section details how these labels are incorporated into feature representations and model training.
\subsection{Feature Engineering}\label{subsec:feature_engineering}
@@ -70,8 +66,8 @@ The features used as model inputs have been divided into three categories:
\item \textbf{Static features} - Characteristics, that remain constant across a user's cycle, such as age, height, or average ovulation day
\item \textbf{Known features} — Inputs known a priori at each time step, such as time of day or calendar-based variables.
\item \textbf{Observable features} — Inputs available at the current time step, including raw and derived temperature values.
\item \textbf{Target features} — Outputs the model is trained to predict, such as the fertility probability.
\end{itemize}
The target variables predicted by the model—like ovulation status or fertility probability—are described separately.
Each feature type can handle categorical and continuous features.
This allows for mixed inputs, such as scalar measurements and class labels, within the same category.
@@ -84,48 +80,44 @@ may process each feature group differently depending on their architectural desi
Static features are the features that do not change over the course of a cycle.
They might even be static for all cycles from a specific user, such as age, height and weight.
Static features provide user-specific context that helps the model learn individualized cycle patterns beyond what temperature alone can reveal.
The static features are supposed to create contextual information about the cycle and the user that each model can then
use to learn patterns based not only on the temperature data, but also on this context.
%\begin{table}[htbp]
% \centering
% \begin{tabular}{l>{\raggedright\arraybackslash}p{0.65\linewidth}}
% \toprule
% \textbf{Feature} & \textbf{Description} \\
% \midrule
% User age & Age in years; mean imputed if missing \\
% User height & Height in centimeters; mean imputed if missing \\
% User weight & Weight in kilograms; mean imputed if missing \\
% Average cycle length & Mean length of all previous cycles for this user \\
% Cycle length SD & Standard deviation of previous cycle lengths \\
% Average ovulation day & Mean day of ovulation from previous cycles \\
% Ovulation SD & Standard deviation of ovulation day of previous cycles \\
% Ovulatory fraction & Proportion of prior cycles classified as ovulatory \\
% Cycle count & Number of previous completed cycles available \\
% Avg. pre-ovulation temperature & Mean temperature in the follicular phase of previous cycles \\
% Avg. post-ovulation temperature & Mean temperature in the luteal phase of previous cycles \\
% \bottomrule
% \end{tabular}
% \caption{Static features used as model inputs}
% \label{tab:static_features}
%\end{table}
%Table~\ref{tab:static_features} shows all static features and their descriptions.
\begin{table}[htbp]
\centering
\begin{tabular}{l>{\raggedright\arraybackslash}p{0.65\linewidth}}
\toprule
\textbf{Feature} & \textbf{Description} \\
\midrule
User age & Age in years; mean imputed if missing \\
User height & Height in centimeters; mean imputed if missing \\
User weight & Weight in kilograms; mean imputed if missing \\
Average cycle length & Mean length of all previous cycles for this user \\
Cycle length SD & Standard deviation of previous cycle lengths \\
Average ovulation day & Mean day of ovulation from previous cycles \\
Ovulation SD & Standard deviation of ovulation day of previous cycles \\
Ovulatory fraction & Proportion of prior cycles classified as ovulatory \\
Cycle count & Number of previous completed cycles available \\
Avg. pre-ovulation temperature & Mean temperature in the follicular phase of previous cycles \\
Avg. post-ovulation temperature & Mean temperature in the luteal phase of previous cycles \\
\bottomrule
\end{tabular}
\caption{Static features used as model inputs}
\label{tab:static_features}
\end{table}
Table~\ref{tab:static_features} shows all static features and their descriptions.
Prior research by \citeauthor{li_menstrual_2023} has shown that menstrual cycle characteristics vary significantly with age and BMI~\cite{li_menstrual_2023}.
Including such information is therefore expected to improve predictive performance.
In addition, summary statistics from previous cycles—such as ovulation timing, temperature levels, or the fraction of ovulatory cycles—provide useful individual context.
These features help the model learn subject-specific variability and better estimate the likelihood and timing of ovulation in the current cycle.
Table~\ref{tab:feature_overview} shows the full list of static input features.
All historical features are computed using only data available prior to the current cycle, ensuring no data leakage and supporting robust, user-adaptive learning.
%
The idea here is to provide as much context information to the models as possible to help them predict the ovulation.
\subsubsection{Known Features}\label{subsubsec:known_features}
In the context of this study, known features correspond to time-dependent inputs.
These help the model place each observation in temporal context:
Known features encode temporal context that is available at each time step and independent of physiological measurements.
These help the model interpret observations in relation to time-based structure, including circadian and behavioral rhythms.
\begin{itemize}
\item \textbf{Time since cycle start} — Provides the model with a relative position within the menstrual cycle.
@@ -172,11 +164,9 @@ They represent real-time physiological signals from which the model must infer o
\item \textbf{Rolling Window Temperature Maximum} — The maximum temperature within a 1-day window, capturing transient peaks or elevated plateaus.
\end{itemize}
These derived features are intended to reduce model complexity by providing smoothed or extremal summaries of the raw signal.
The \textit{rolling average} allows the model to capture broader trends without having to learn temporal aggregation from scratch.
The \textit{rolling minimum} and \textit{maximum} support the detection of boundary behavior (e.g., temperature shifts, sustained elevation, extreme values)
without requiring explicit memory or aggregation.
These derived features summarize local trends or extrema in the temperature signal, reducing the burden on the model to learn such patterns from raw data.
Special care was taken, so that the sliding window can only look backwards, so that no data leakage can happen.
We extend each windowed feature at the beginning with the starting value, so that the window can be calculated for the first real value already.
The 1-day window length reflects the expected circadian cycle and strikes a balance between temporal sensitivity and signal stability.
Figure~\ref{fig:methodology_observable_features} illustrates the behavior of all observable features within a single cycle.
@@ -260,7 +250,8 @@ a \textit{robust scaler} was used for distributions with outliers, and a \textit
\subsubsection{Time-Series Input Representation}
\label{subsubsec:time_series_input_representation}
Due to the high temporal resolution of the temperature data (288 measurements per day), raw input sequences can become prohibitively long for most model types.
The high temporal resolution of the temperature data, 288 measurements per day, results in very long input sequences
that are impractical for most deep learning models to process directly.
To manage input size and evaluate the impact of temporal resolution on predictive performance, a parameterized resampling strategy is applied.
Consecutive time steps are aggregated into bins of configurable size, and each bin is reduced to a single value using a feature-specific aggregation function.
@@ -274,17 +265,17 @@ The effect of different sampling resolutions and aggregation strategies is evalu
To simulate real-time prediction rather than retrospective analysis, a sliding-window approach is employed.
This allows the model to make predictions based only on data available up to a specific point in the cycle.
Each cycle is split into overlapping input windows, where each window includes data from the cycle start up to a defined time step.
The window length is fixed and configurable.
As the cycle progresses, the window slides forward, allowing the model to incorporate increasing historical context over time.
To simulate real-time prediction, each cycle is split into overlapping,
fixed-length input windows that capture all available data up to a given time step.
As the cycle progresses, these windows slide forward, allowing the model to update its prediction based on growing historical context.
For the model types used in this study, each window produces a single output vector.
By default, this corresponds to the predicted target values at the final time step of the window, though this can be offset depending on configuration.
By default, this corresponds to the predicted target values at the final time step of the window,
though this can be offset to predict targets several steps into the future, depending on configuration.
While the architecture could be extended to produce output sequences (e.g., one prediction per input step), this study focuses on single-vector outputs.
This setup enables temporally resolved predictions at different stages of the cycle and supports analysis of how predictive accuracy evolves with increasing context.
Depending on the configuration, downsampling and windowing can be skipped to allow the raw data to be processed by the models themselves.
This is used primarily in the convolutional flavours of the models, to allow them to learn the best way of reducing the input complexity based on the data itself.
This setup mimics a real-time setting, enabling the model to generate predictions dynamically as new data arrives during the cycle.
For convolutional architectures, downsampling and windowing can be disabled entirely, allowing the model to learn temporal compression directly from the raw input.
\begin{figure}[htbp]
\centering
@@ -296,18 +287,16 @@ This is used primarily in the convolutional flavours of the models, to allow the
\label{fig:methodology_padding_example}
\end{figure}
Fixed-length input windows would normally prevent early-cycle predictions when insufficient data is available.
To address this, left-padding is applied using masked values.
In this study, predictions are enabled once at least four days of data are available.
A padding value of 0.0 is used for all features, and the padding length is adjusted accordingly.
This design ensures that the model learns to ignore tokens consisting entirely of padding.
The feature \textit{hours since start}, which encodes the time elapsed since cycle onset, is also set to 0.0 for all padded tokens—
explicitly indicating that these entries contain no usable information.
Because fixed-length windows require a minimum amount of input data, early-cycle predictions would normally be impossible.
To address this, left-padding is applied with masked tokens until sufficient real data is available—enabled here from day four onward.
Padding values are set to 0.0 across all features.
Since the feature \emph{hours since start} is also set to 0.0 for padded steps it is reinforced, that the section is not relevant
for the prediction as no information is present.
Figure~\ref{fig:methodology_padding_example} shows an example of such padding during early-cycle input preparation.
This input strategy supports efficient, temporally-aware learning and allows us to evaluate how predictive accuracy evolves over time within each cycle.
\subsection{Model Architecture and Selection}\label{subsec:model_architecture_and_selection}
The primary objective of this study is to find models that accurately predict the features introduced in~\ref{fig:methodology_target_features},
@@ -565,11 +554,9 @@ Due to the heterogeneity of both the models and the trainings, a dynamic batch s
the batch size dynamically during training to optimize the resource usage.
The learning rate was scaled linearly with the batch size to allow for equivalent convergence behaviour~\cite{goyal_accurate_2018}
The batch size was capped at 2048 to avoid OOM errors during data preparation.
%TODO sources, for square rule
\subsection{Evaluation}\label{subsec:evaluation}
% TODO: review
To meaningfully compare model performance, we define a set of metrics that capture both overall accuracy and behavior at key points in the prediction sequence.
This includes metrics for different temporal segments, enabling a more detailed understanding of model strengths and limitations.
@@ -698,7 +685,7 @@ Additionally, ovulation must occur no later than cycle day 150, as later values
biologically atypical cases that fall outside the scope of this study.
\subsubsection{Use Case Evaluation}
We further evaluate the two distinct use cases introduced in Section~\ref{subsubsec:use_cases_of_ovulation_prediction}.
We further evaluate the two distinct use cases introduced in Section~\ref{subsubsec:practical_use_cases}.
For this purpose, two specialized evaluation algorithms were developed,
enabling comparability between models and providing interpretable performance metrics for each scenario.
@@ -721,9 +708,11 @@ A day-specific probability of intercourse is computed for each user based on age
We assume, that the users don't have any health-related or non-health-related issues affecting fertility.
If a user's age is unknown, it is randomly drawn from the overall dataset distribution.
Only users with at least one continuous year of data are included.
To get a representative result, we use 500 randomly selected user years.
Each day of data for a full year is categorized by the algorithm into one of the following outcomes:
Each day of data for a full year we count the following states by the algorithm:
\begin{itemize}
\item \emph{Sex}: Intercourse occurred.
\item \emph{No Sex}: no intercourse occurred.
\item \emph{Correct Denial}: fertility prediction correctly indicated abstinence during a fertile period.
\item \emph{Incorrect Denial}: fertility prediction incorrectly indicated abstinence during an infertile period.
@@ -753,16 +742,16 @@ Figure~\ref{fig:methodology_use_case_pregnancy_decision_diagram} illustrates the
The fertility threshold is adjustable and is explored further in Section~\ref{subsec:use_case_evaluation_results}.
Since sexual intercourse frequency differs slightly for couples trying to conceive~\cite{gaskins_predictors_2018},
we assume an average frequency of six times per month.
We derive a daily probability of intercourse based on remaining fertile days predicted for the month,
ensuring that intercourse frequency averages out to this monthly rate.
We assume no health-related fertility impairments for comparative simplicity,
though we acknowledge that real-world fertility is influenced by numerous complex factors.
Similar to the contraception scenario, only users with at least one continuous year of data are considered.
For representative results, we use 500 randomly selected user years.
Each day in a full year is classified into one of the following categories:
For each day in a full year we count occurrences of the following states:
\begin{itemize}
\item \emph{No Sex}: Day predicted as fertile, but no intercourse occurred.
\item \emph{Sex}: Intercourse occurred
\item \emph{No Sex}: No intercourse
\item \emph{Pregnancy}: Correct fertile prediction, intercourse occurred, resulting in pregnancy.
\item \emph{No Pregnancy}: Correct fertile prediction, intercourse occurred, but no pregnancy occurred.
\item \emph{Incorrect Deferral}: Incorrect non-fertile prediction, actual fertility was above threshold.