Blog posts

Using CTGAN to synthesise fake patient data

Being the member of the Computational Oncology lab with no more than my A levels (which I never sat!) and an unconditional offer to study Computer Science at Imperial College London in October 2021 has been a great opportunity which I am extremely grateful for, albeit a bit daunting, sitting alongside everyone with their variety of PhDs.

A large issue in the medical world is that patient data is highly confidential and private, making getting our hands on this limited resource difficult. One potential solution to this problem is using a GAN (Generative Adversarial Network) called  CTGAN to generate realistic synthetic patient data, based off real, private patient data. The goal of a project that I have been working on  is to take in real tabular patient data, train a CTGAN model on the real data and have the model output synthetic data that preserves the correlations of the various columns in the real data. This model can generate as many synthetic patients as one desires, can undergo the same analysis techniques that researchers would use on real patient data, and the synthetic data can be made publicly available as no private data is accessible through the synthetic data.

There are many constraints that can be placed onto the GAN to make the synthetic data more realistic, as sometimes data needs to be constrained. As of right now, there are 4 constraints that can be placed on the model. First, there is the ‘Custom Formula’ constraint, which could be used to preserve the formula of ‘years taking prescription = age – age when prescription started’. Next, the ‘Greater Than’ constraint which would ensure that ‘age’ would always be greater than ‘age when prescription started’ and finally, the ‘Unique Combinations’ constraint which could be used to restrict ‘City’ to only be synthesised when the  appropriate Country column is generated alongside it. There is also a constraint called APII (Anonymising Personally Identifiable Information) which ensures that no private information is copied from the real data to synthetic data. APII works with many different confidential fields such as Name, Address, Country or Telephone Numbers by replacing these fields with pre-set, non-existent data entries from a large database called Faker Providers.

I have been working on adding a new constraint called ‘Custom ID’. This constraint applies when 2 columns are just encodings of each other, which occurs most frequently with ID columns. Without this constraint, the 100% correlation between a discrete column and its’ respective ID column would not be preserved. This is done by, first, comparing each of the columns against every other column in the data, if any encodings are found then the discrete column is preserved and the numeric ID column is removed. This is done because the ID column is an encoding of a discrete column, but will be identified by CTGAN as continuous, and will therefore model the column incorrectly. Once the ID column is removed, a lookup table will be created which links each value in the discrete column to their respective IDs. The CTGAN model is then trained on the data that does not contain the ID column. Finally, when sampling synthetic data, the ID is added backing into the synthetic data using the lookup table.

This solution has the advantage of running quickly, as the time complexity is not based on the number of rows in the real data. It is also easy to use, as it can be turned on and off with one input. Finally, my solution will identify all of the ID columns in the data and create lookup tables for each of them. One limitation of my solution would be that my Custom ID constraint would not detect 3 columns that are correlated (eg. ‘Gender’ ‘Gender Abbreviation’ and ‘Gender ID’) although this situation occurs rarely.

As I have the long-term goal of synthesising patient data, the synthetic data must be secure in the sense that it must not be possible to reverse engineer the real data from the synthetic. One test, available in SDGym, is the LogisticDetection metric which compiles both the real and synthetic data randomly and passes them to a discriminator which attempts to flag the incoming data with real and synthetic flags. This test showed that the data can be correctly identified as real or synthetic just over 50% of the time. However, when we are dealing with analysis on medical data, I feel there are still steps to be taken, to make the synthetic data more accurate before serious analysis on this synthetic data can begin.

Dipping my toes into the world of machine learning has been extremely fascinating and I have learned many new things, about both machine learning and coding more generally. I realise how important the complexity of my code is, because, if the code has a bad time complexity, the program could take days to run, which is not practical. Another lesson I learned the hard way is to not be afraid to restart. I completely rewrote my code after I finished a previous, working solution to the Custom ID constraint because the code was too complex and was taking hours to run. This allowed me to learn from my mistakes and reach a much better solution.

I now hope to train a CTGAN model on the GlioCova dataset which contains medical records of over 50000 cancer patients, and measure how well CTGAN performs on a large, relational database.

 

 

 

 

COVID and the return to Research

The 14th of March marked the end of my redeployment to a support role in Intensive Care and the second interruption of my PhD due to the pandemic. Academic papers and lines of data were replaced by disembodied voices as I endeavoured to keep two wards worth of family members updated on their loved ones’ progress. With strict restrictions on visitation, this daily conversation was often the only insight into how their relatives were recovering, and in many cases, how they weren’t. Whether I’ll be due a third pandemic-related sabbatical is yet to be seen. In the past few weeks, I’ve personally witnessed the steady downtick of COVID-related admissions. Beds filled with ventilated patients are now replaced by those in need of ITU-level monitoring following delayed essential procedures. Things are no less busy, but the grip of COVID has loosened and at the very least, there is a measure of respite.

Today, I replace my ITU hat with the academic hat I hung up two months ago. My oncology hat continues to gather dust, awaiting its eventual turn. Being reminded of my time as a clinician, one of my motivations for delving into the world of code and computational solutions is in its ability to capture and manipulate data that is often overlooked in day-to-day practice. Medical data is costly, both in time and manpower. Request forms, going through the scanning process, having labs do bloodwork, waiting for a report to be generated, are all steps taken to produce what is often a singular data point, which subsequently is consigned to medical archives. As our technology advances, so too has the information we capture from investigations, as well as our ability to store and read it on a larger integrated scale. This could enable – the discovery of complex relationships that would otherwise not have fit onto a blackboard or spreadsheet. Pairing this with the zeitgeist that is the renewed interest in artificial intelligence, we now have the technology to realise complex manipulation of large datasets at a level previously unattainable; bursting open the barriers that previously held us back.

One venue of unused data lies in opportunistic imaging. Cross-sectional imaging such as Magnetic Resonance Imaging (MRI) or Computed Tomography (CT) are commonly used in cancer care. These scans reconstruct “slices” through the scanned body which clinicians can scroll through to visualise internal structures. In cancer, the main reason to do this is to evaluate how the cancer is responding to a treatment. Simply put, if a cancer is in the lung, the focus of imaging and attention will be in the lung. But scanning the chest for lung cancer patients invariably picks up other organs as well, including the heart, bones, muscle and fatty tissue present in all of us. Unless there is an obvious abnormality in these other organs (such as a grossly enlarged heart, or cancer deposits elsewhere in the chest), these other organs are barely commented on and become unused by-products. There is information to be gained by review of these other organs, but until now there have not been the tools to attempt to fully realize them.

In a landmark 2009 study, Prado et al. measured muscle mass in obese cancer patients using CT scans obtained routinely during their cancer management. Due to its correlation with total muscle mass, the muscle area was measured at the level of the third lumbar vertebrae. This was subsequently corrected for height to a skeletal muscle index. Prado et al. found a relationship between low muscle index and survival, creating the label of sarcopenic obesity with a diagnostic cut-off determined by optimum stratification (<Male 55/Female 39 cm2/m2). Sarcopenia was a new concept in cancer care at that point, previously having been used in mainly an aging context to define frailty associated with poor muscle and mass. In the frailty literature, where there is limited access to CT or MRI imaging, assessments were usually functional (such as defined set of exercises) or involved plain X-ray imaging of limbs for practicality, cost and radiation dose purposes.

For cancer sarcopenia, assessment of muscle index has been repeated by other groups in single-centre studies across a variety of tumour types and geographic locations. Even when correcting for sex and height, there are enough other uncorrected factors that the range of cut-offs for pathological sarcopenia is too wide to be of practical utility (29.6-41 cm2/m2 in women and 36-55.4 cm2/m2 in men). Another limitation lies in that tumour sites do not always share imaging practices. For instance, in the case of brain tumours, there is less of a need to look for extracranial disease and thus, no imaging is available at the level of the third lumbar vertebrae for analysis.

In the current age of personalised medicine, being able to create individualised risk profiles based on the incidental information gained from necessary clinical imaging would add utility to scan results without adding clinical effort. For my PhD, the goal is to overcome this challenge using transfer learning from an existing detailed dataset. We’ve had the fortune to secure access to the UK Biobank, a medical compendium of half a million UK participants. The biobank includes results of biometrics, genomics, blood tests, imaging as well as medical history. Such a rich dataset is ripe for machine learning tasks.

I have therefore been working to integrate several high-dimensional datasets, applying a convolutional neural network to the imaging aspect whilst a deep neural network to the non-imaging aspect. A dimensionality reduction technique such as autoencoder will subsequently have to be applied to generate a clinically workable model. Being a clinician primarily, I am able to bring clinical rationale to the model and intuit the origin of certain biases from my prototype pipelines. On the flip side, I have struggled to become fluent with the computational code necessary to tackle these problems, and often still feel like I am at the equivalent level of asking for directions to the bathroom back in my GCSE German days.

In becoming a hybrid scientist, I’ve long since acknowledged that I will not be the best coder in the room. I am still climbing the steep learning curve of computer languages and code writing, grateful for this opportunity to realise my potential in this field. Machine learning is ever encroaching on not just our daily lives but in our clinical practice, usually for the better. I imagine that as early adopters turn into the early majority, those of us who have chosen to embrace this technology will be in a position to better develop and understand the tools that will benefit our future patients. After all, soon we will not just be collaborating with each other but also with Dr Siri and Dr Alexa.

BrainWear

Sleep walking into clinical data science

If I’ve learned one thing over the last five months in the Computational Oncology lab, it is that real world data is a whole different ball game.

As a fresh-out-of-undergrad master’s student, with a background in cognitive neuroscience and biological sciences, a data science project wasn’t entirely in my toolkit. My programming skills was a working knowledge of Java and online courses in Python and Machine Learning picked up over the summer. With MRes project choices, I found myself with a unique opportunity to gain experience in a lab, working with highly experienced researchers, clinicians and students. I figured a project in the Computational Oncology lab would be a challenge – but what better way to learn how to analyse large datasets or apply machine learning methods than immerse myself in a project.

For the past 5 months, I have been working under Dr Seema Dadhania on a project from the ongoing BrainWear clinical study. Specifically, I was tasked with analysing sleep in patients with High Grade Gliomas, a malignant primary brain tumour. Sleep disturbance is one of the most commonly experienced symptoms for patients with High Grade Gliomas. In fact, in a 2018 study by Garg et al, it was found that disrupted sleeping behaviours were three times more prevalent in patients with primary brain tumours than healthy controls, and was linked to decreased quality of life. Despite how pervasive and burdening sleep problems can be in brain tumour patients, research remains scarce and the studies that have been done use self-reported measures such as the EORTC-QLQ C30 and MDASI-BT, questionnaires which assess quality of life or severity of symptoms. These measures run the risk of subjectivity – patients may quantify difficulty with sleep in different ways which skews the translatability of findings to real life. With the collection of longitudinal accelerometer data, BrainWear gives the opportunity to objectively understand sleep patterns and changes that occur with treatment.

(more…)

Patients and research

Where do patients fit in research?

How to brilliantly take over from Dr Seema Dadhania’s blog post when I am definitely not someone to keep diaries (like Anne Frank or Carrie Brashaw)?

Some suggest writing about yourself; others, on your research. Well, that is a shame because there is nothing sufficiently interesting about me to make it public, and my research is scattered over so many projects and obligations that they would be difficult to summarise in 900 words. Then, the idea came to me after a patient and public involvement meeting organised and chaired by the talented Miss Lillie Pakzad-Shahabi: how do patients have an influence on my work? do I work for clinical staff or patients in the National Health Service (NHS)?

(more…)

BrainWear

BrainWear – correlating wearable data with clinical outcomes in brain tumour patients

A New Year turns, and with it brings my very first blog post for the Computational Oncology Group, in poll position on Matt Williams highly anticipated ‘2021 blog rota’… I am the chosen one.  I will use this opportunity to share with you some highlights and lessons from my PhD thus far, which I hope gives you an insight into my work within the lab and with our patients, for whom we strive to deliver.

BrainWear (ISRCTN34351424 https://doi.org/10.1186/ISRCTN34351424) is a clinical study collecting wearable data in the form of a wrist worn Axivity AX3 accelerometer from patients with primary and secondary brain tumours. It is the brainchild of one of our very own patients who wanted to share his wearable data with us whilst having treatment as an additional monitoring tool. One of the strengths in traversing both a computational and clinical PhD is learning that patients are an invaluable source of knowledge and have undoubtedly helped shape the research we do and the questions we ask from our data. Our first BrainWear patient was recruited in October 2018 and we have since recruited 60+ patients, with some providing > 1 year of accelerometer data and for the first time we will be able to objectively understand how daily activity changes with surgery, chemoradiotherapy and at the point of disease progression. In its essence, BrainWear is a feasibility study and asks the simple questions: is it possible for brain tumour patients to wear a wrist worn device whilst having treatment? do they find it acceptable? Is longitudinal data collection possible? But as we delve deeper into this first of its kind dataset, there are layers of information about patient physical activity levels, sleep pattern, gait (walking style) and quality of life in simple accelerometer data. The passive nature of the data (collected without interference from neither patient nor clinician) represents the patient objectively, and it is this aspect of the data and its correlation with existing clinical parameters which I have found so attractive. Our work is now to understand how these data change over time and with disease activity but more interestingly whether there are any early indicators to identify ill health i.e., disease progression or hospitalisation. Can this data be used to explain, influence and/or predict health-related outcomes and in turn be translated into a digital biomarker to guide clinical decision making?

Accelerometery data captured at a sampling frequency of 100Hz (100 readings per second) rapidly expands in size and requires powerful data analysis and manipulation tools, for which I have utilised Pandas built on top of Python 3, and the watchful eye of our lab data analyst.   Whilst keen to explore how we can use machine learning (ML) methods as a predictive method of worsening disease particularly around gait and sleep in those patients with high grade gliomas, I am currently taking some time to understand the more traditional statistical methods of longitudinal data analysis utilising mixed effects models. A recent systematic review by Christodoulou et al showed no performance benefit of machine learning over logistic regression for clinical predictive models in low dimensional data. I believe one of the strengths in training clinicians to manipulate and analyse data computationally is our ability to understand the clinical impact of the question being asked from the data, and when relaying our findings to the clinical community, it is important that our methods are robust and represent the more traditional statistical approaches as well as novel ML methods. We have however taken the opportunity to capitalise on the ease of access to accelerometer data with our MSc students, and developed support vector machine classifiers for identifying pure walking bouts and extend on existing work done using neural networks to classify clean walking and gait characteristics. The UK Biobank and the work done by Aiden Doherty’s team in processing and publishing findings on just under 100,000 participants 7-day accelerometery readings have given us the opportunity to compare patients with high grade glioma to healthy UK biobank participants. This will allow us to understand in greater depth how patients with brain tumours are impacted by their disease.

Digital remote health monitoring is becoming more mainstream in clinical and trials settings, fuelled by rapid development in sensor technology and in trying to provide increasingly patient centred care, particularly in the era of COVID-19. Correctly utilising these devices and data has the potential to provide a method of monitoring the patient in motion rather than the episodic snapshot we currently see and in turn improve our clinical decision making and patient outcomes.  In that spirit, in my next blog post I hope to update you on some preliminary analysis from our high grade glioma patient subset of BrainWear, and will discuss how I am going to tackle the non-trivial task of incorporating wearable data into clinical decision making models.

An Introduction

An Introduction to Computational Oncology

…..and – why a Blog?

 

These starter posts are always hard, so…..this blog is the companion to the lab website. But that is static, and tells you who is who, and what papers we have published, but doesn’t let you talk about the work we are doing now, or the software we build that doesn’t get “published” (but is released), or the stuff that never get published, or the stuff that is published but is complicated and would benefit from some explanation.

Hence a blog

It is also a way to force us all to write something, more regularly than just papers and grant submissions. I am a great believer that writing IS research: the process of writing involves shaping your thoughts, deciding what you think is true from you have evidence for, deciding how to structure an argument, and working out how to present that to an audience. I think that sounds like research.

It is also a good way to let others know what else we are doing; across Imperial, and more widely. It can be difficult from reading just published work to decide what people are really interested in. It also gives an opportunity for everyone in the lab to contribute – not just to writing, but also reviewing, editing and disseminating that work.

It also lets us rehost some older content that appeared on the (currently defunct) Computational Medicine blog that I ran with Caroline Morton: some of that content is still available, but before it vanishes, we will repost it here (who can fail to be interested in my take on why Jane Austen has some lessons for how we think about the deployment of AI-based systems in healthcare). Which leads us to the question of what Computational Oncology is.

Broadly, we define it as the mathematical and computational approaches to clinical problems in cancer. Our basic unit of analysis is the patient, rather than genetic data (as in bioinformatics) or populations (as in epidemiology), but we look to apply computational approaches. We do this because computational approaches let us do things we can’t normally do: it lets us scale up, it lets us collect things we can’t normally collect, it lets us monitor in a way that we can’t normally do, and extract previously hidden information from routinely acquired data.

This is a vague definition, and is as much a set of things it isn’t as what it is, but it has coherence, and we are beginning to see how our projects link together, linking work on automated imaging interpretation with patients who are enrolled in a clinical trial (more of this later). It also misses some of the most important things about our work: the focus on patient-centred work, the Patient & Public Involvement work we do, and the fact that a lot of the work is based around brain tumours.

We will update this every couple of weeks, as people post about updates of their work, and if you are interested, feel free to drop us a line: matthew.williams -at- imperial.ac.uk