Inspiration
Low Birth Weight is a condition when a child is born with an initial weight of less than 5.5 pounds or approximately 2.5kg. Such a condition often requires specialist equipment setup in a time-sensitive manner. If it possible to predict if a child is likely to have low-birth weight then equipment can be prepared beforehand. We also wanted out application to be accessible to all, even though which do not have access to an ultrasound machine. As such, our machine learning model would have to be able to make predictions based on antenatal datapoints which are accessible to all, not just those with access to ultrasound technology.
What it does
Our application, CTM (Call The Midwife), takes a series of antental datapoints, such as birthing parent's age, gestation weeks, plurality and biological sex and predicts the weight of the child. As such, the predicted weight can be categorised into underweight or overweight.
How we built it
We decided we wanted to use Google Cloud Platform's Big DataLab to gain access to the CDC's natality dataset, a collection of every birth in the USA from 1969 to 2008; containing over 137 million entries. We built a Deep Neural Network regressor in Python which was able to accurately find the correlation between the antenatal datapoints and the birth weight. This numeral output can then be categorised into underweight or overweight.
We chose to use Python for our model as this is a technology that the team were most familiar with. Our web application application is built in Node.js and Svelte. Our machine learning model is called within Node, which uses Express.js to pass the results to the front-end.
Challenges we ran into
Royal Hackaway V5 was the first hackathon for all members of the team and as such, the fast pace dynamic presented both pressure to perform but equal levels of excitement.
In addition, building web applications is something that we had little experience in as a team. This meant we had to do lots of on-the-fly learning from online videos, tutorials and documentation. We found lots of things that most would, assumably, find easy (such as disabling entry fields given certain conditions) to be particularly difficult. We are proud that we were able to build a working solution in the end.
We found that building two seperate models, while timely and more complex, provided us with better results. This is because one model can predict with ultrasound data, the other can predict without.
ChartJs, the package we chose for our graph, presented a lot of issues in Svelte and Node. As both Node and Svelte were new to the team, imbedding another packaging within was an additional layer of complexity neither of us had experience in. The package didn't work as the documentation outlined, so we ended up Tweeting and emailing the original developer out of desperation. They never replied... it was a sad moment :( In the end, we ended up finding a guide on how to force a re-render of the chart to display changes; quite the 'hacky-hack' solution if you ask us.
Accomplishments that we're proud of
As this is our first Hackathon, we are collectively very proud of what we have achieved in such a short time. Our model is accurate, providing accuracy levels of approximately 94%, with a clean and clear front-end.
We wanted an application which was accessible and made no assumptions about the environment it would be deployed in. As such, we are confident that our model is still able to predict the birth weight with a good level of accuracy even without ultrasound based data-points, such as biological sex or plurality.
We set out to build a model which could, ultimately, save lives if deployed in the right situation. While we appreciate our model is far from perfect and certainly has areas for improvement, we are confident that it achieves our ultimate aim of predicting if a child would suffer from Low Birth Weight. We are both proud of what we have built.
What we learned
As previously mentioned, we both feel we have learnt a huge amount at our first hackathon. From ML, Svelte and Node to the intricacies of childbirth and social-economic situations around the world.
While our dataset provided a large amount of data, as suggested by one of the Hackathon organisers, we also looked into additional datapoints, such as weather calamities in a given area, and how this might influence child birth. We quickly realised how complex this could become and were aware of 'scope creep' with additional issues, such as difficulties for a user to enter this information easily, and how this might reduce the usability of our application.
Since Royal Hackaway V5, we both feel we want to engage in more hackathons in the future. Incorrectly, be both thought hackathons would be competitive environments and, while there was undoubtable a little competition, others were more than happy to help and support each other. We are both grateful for the support, gudiance and welcoming environment we have recieved at Royal Hackaway V5.
What's next for Call-The-Midwife
There are lots of things which could be improved with Call-The-Midwife. The main area for improvement that we believe would add to the application is SMS functionality.
While Royal Hackaway V5 has a specific challenge to imbed Twillo functionality into our application, we didn't feel we had the time to implement such a feature, given the learning curve for all members involved.
Our application aims to be accessible to all, so building a mainly web focused application may be a large barrier to entry. As such, it would be good if Midwives, or similar, could text antinatal data-points to a specific number and receive the prediction back. This would be much more accessible, given the proliferation of 3G/4G technologies in developing nations.

Log in or sign up for Devpost to join the conversation.