When I started my MSc in Computer Science and Artificial Intelligence at the University of York, I knew I wanted my dissertation to sit at the intersection of technology and healthcare. With a background in neuroscience and a current interest in medicine, I was particularly interested in exploring how artificial intelligence could be used to address real clinical problems.<\/p>\n\n\n\n
My dissertation focused on osteoporosis risk in post-menopausal women, asking whether machine learning could identify people at higher risk using information that is relatively simple and non-invasive to collect.<\/p>\n\n\n\n
Osteoporosis is a major cause of fragility fractures, particularly in post-menopausal women. Although bone mineral density can be measured accurately using DXA scanning, providing this type of assessment to everyone is resource-intensive.<\/p>\n\n\n\n
I therefore wanted to explore whether machine learning could help with the triage process: could we use information such as age, BMI, lifestyle factors and other health characteristics to identify people who may benefit from further assessment?<\/p>\n\n\n\n
For the project, I used data from the National Health and Nutrition Examination Survey (NHANES), combining demographic, examination and questionnaire data with DXA-derived bone mineral density measurements.<\/p>\n\n\n\n
I compared three different machine learning approaches: Logistic Regression, Random Forest and XGBoost.<\/p>\n\n\n\n
One of the biggest challenges I encountered was class imbalance. Most participants did not meet my osteoporosis-risk threshold, meaning that a model could appear to perform well while actually missing a large proportion of the people I was most interested in identifying.<\/p>\n\n\n\n
Rather than using synthetic data to artificially increase the minority class, I explored cost-sensitive learning, giving greater weight to missed osteoporosis cases.<\/p>\n\n\n\n
The results were particularly interesting. The baseline models had reasonably strong overall discrimination, but their ability to identify osteoporosis cases was poor. After cost-sensitive optimisation, the targeted Random Forest model achieved 100% recall, while maintaining a precision of 58.9% and an F1-score of 0.741. I also found that age and BMI consistently emerged as the most important predictors.<\/p>\n\n\n\n
Perhaps the most interesting finding was that the effect of training on a specific population depended on the machine learning architecture. Training Random Forest on the general population substantially reduced its ability to identify osteoporosis cases, whereas XGBoost maintained high sensitivity but became less precise. This suggested that demographic stratification is not necessarily a universal requirement, but rather something that needs to be considered alongside the architecture and intended use of a model.<\/p>\n\n\n\n
Of course, these results are exploratory. The dataset was enriched for people who had undergone DXA assessment, and the models would require external validation and calibration before they could ever be considered for clinical use.<\/p>\n\n\n\n
The biggest lesson I took away from the project is that a good machine learning project is not necessarily about building the most complicated model.<\/p>\n\n\n\n
It is very easy to become focused on algorithms, hyperparameters and performance scores. However, I found that some of the most important decisions happened before the model was even trained: choosing an appropriate dataset, defining the target carefully, understanding the limitations of the data and deciding which performance metric actually mattered for the problem. My supervisor\u2019s<\/a> constructive feedback made navigating these crucial analytical decisions significantly easier.<\/p>\n\n\n\n It is tempting to start with a technique you want to try. XGBoost, neural networks, deep learning, and so on, and then find a problem for it. I found it much more useful to start with the problem and ask what type of model and evaluation strategy actually made sense.<\/p>\n\n\n\n This was probably one of the most valuable parts of my dissertation. Understanding how the data had been collected, what was missing, how variables had been measured and who was represented in the dataset affected almost every subsequent decision.<\/p>\n\n\n\n A sophisticated model cannot compensate for poorly understood data.<\/p>\n<\/blockquote>\n\n\n\n My project really demonstrated how misleading a single metric can be. A model can have a strong AUC while still missing a large proportion of the cases you actually care about. Think carefully about what a false positive and false negative mean for your particular problem.<\/p>\n\n\n\n Save your code, datasets, model versions, outputs and decisions as you go. Don’t assume you’ll remember why you made a particular decision several months later, especially when you’re trying to write everything up at the end!<\/p>\n\n\n\n I initially thought I needed to finish the analysis before I could properly start writing. In reality, writing helped me identify gaps in my reasoning and clarify what I was actually trying to demonstrate. Your dissertation is not just a report of what you did; it is an argument for why what you did matters.<\/p>\n\n\n\n Completing the MSc has given me much more than experience with machine learning. It has taught me how to approach an unfamiliar problem, critically evaluate evidence, work with imperfect real-world data and think about the implications of applying technology in healthcare.<\/p>\n\n\n\n Coming from a neuroscience background and moving into computer science, I found the MSc challenging at times, but that combination of disciplines ultimately became one of the most valuable parts of the experience.<\/p>\n\n\n\n My biggest takeaway is simple: you don’t need to know everything before you start. You need to be willing to investigate, question your assumptions and keep refining the problem as you learn more.<\/p>\n<\/blockquote>\n\n\n\nMy advice for future students<\/strong>:<\/h2>\n\n\n\n
Choose your research question before choosing your model.<\/strong><\/h2>\n\n\n\n
Spend more time understanding your dataset than you think you need to.<\/strong><\/h2>\n\n\n\n
\n
Don’t rely on a single performance metric.<\/strong><\/h2>\n\n\n\n
Keep your project reproducible from the beginning.<\/strong><\/h2>\n\n\n\n
Start writing earlier than you think you need to.<\/strong><\/h2>\n\n\n\n
Looking back<\/strong><\/h2>\n\n\n\n
\n