EnAcuity
London
EnAcuity is a medical technology company spun out of Imperial College London and UCL. Keyhole surgery is carried out through a camera, and what the surgeon sees is much the same colour video you or I would. A good deal of what a surgeon needs to know is not visible in it. Whether a section of bowel still has a healthy blood supply, for instance, is largely judged by eye and by experience, and judging it wrong has serious consequences for the patient. Specialist cameras that measure blood supply directly do exist, but they are expensive and are not in most operating theatres. EnAcuity's approach is to recover the same information from the camera hospitals already own, in software, rather than asking them to buy new hardware. I spent six months there as a research engineer, working on that problem.
My project was to predict how much oxygen is reaching the tissue the surgeon is looking at, from ordinary colour video alone, and to establish how well that can ever be done. Most of the work turned out to concern trust rather than the model itself. I found several faults in how the training data was produced, including one where roughly a fifth of the measurements had been quietly altered as they were saved, making them impossible to learn from. I also took on the larger question of whether ordinary colour video simply does not carry enough information for this task, designed the experiment that answers it, and then had to revise my own conclusion when a senior colleague challenged the evidence behind it. Separately, I built and delivered two features into the surgical display software the company demonstrates with, both now in use by the team.
Machine learning and computer vision applied to video, plus building the data pipelines that feed a model, and checking that what comes out of them is really what you think it is. Designing controlled experiments, so a comparison measures the one thing it is meant to measure. Working with light and colour measurements and the physics underneath them. Day to day I worked on remote machines with high-end graphics cards, and on the specialist computer that runs the software in theatre, which meant writing interface code and automated tests as well as research code.
Explaining one result to very different people: researchers who want the method, senior staff who want the decision, and clinicians who want to know whether it changes what they do. Being trusted with a loosely defined problem end to end, and setting my own standards for when something counts as established rather than waiting to be told. Reporting results that do not hold up, including my own, since doing so early costs far less than defending them later. Balancing open-ended research against work with a fixed deadline, and judging which one can slip.