When thinking about the future of health care, and specifically eye health, I naturally look at how else our lives are changing around us. We live in an era of mass data collection and instant personalization. Amazon, Spotify, Youtube, Google, and Facebook all collect things about me to predict what I want, and I'm generally pleased with the result.
It's odd to think that until recently, suggestions for these things came almost entirely from word of mouth. Advertising was annoying and unhelpful, and my social bubble limited my exposure to novel things. Today, automatic recommendations for what I want to read, watch, listen, or buy are well tailored to my habits and preferences. It's actually quite helpful, if not at least a little creepy.
Excitement about this magic has popularized a few technological buzzwords of the day: machine learning, AI, automation, and the most cringe-worthy: big data. Hidden behind the hype, however, is an honest chance to use some of the techniques most visible in the tech world to improve our health.
The key idea is this: what if we could predict and personalize health recommendations as well as spotify can build a playlist? How do we truly achieve personalized medicine?
The medical experts will say this: "Not so fast! Health data is notoriously complex, and it's hopeless to expect a machine to replace human intuition and understanding."
And I agree to a point. But there is one aspect of health that is ripe for disruption: screening.
What if we could establish a scalable way to screen for a certain type of condition? What if we could detect eye disease before someone begins to suffer from vision loss, and perhaps save vision?
OpenEye.io wants to do exactly that. As our first mission, we are building an open platform for scalable diabetic retinopathy screening. The solution spans hardware and software; it makes an untrained health worker capable of screening 95% of people for vision threatening disease.
We want to improve the identification of patients. In many instances early identification can be matched with simple treatment. The reason identification of patients is a hard problem is two-fold:
- It is difficult to acquire the medical data needed to make a diagnosis
- Once data is acquired an expert must interpret the data to map to treatment
Acquisition of medical data is limited by the lack of affordable screening tools and operators. In order to address acquisition, we seek to develop best practices for screening and technological solutions that improve efficiency. The key concept is to reduce cost through computation and eliminate the technical expertise required of the operator through interactive technologies.
Traditionally, trained experts are responsible for the interpretation of medical images. This is not scalable. For example, in India ophthalmologists only make up 1 in 100,000. New telemedicine platforms have attempted to address this problem through the creation of reading centers, but these are slow. Non-instant results means it is necessary to track down patients to provide their screening results. We solve this problem by building fast and automatic assessment algorithms driven by data.
At OpenEye.io we are building an AI platform that looks at color images of the retina, so called Fundus Photographs, to estimate the severity of Diabetic Retinopathy. We are developing cameras and automatic image interpretation that can be used to screen people instantly. By collaborating in an open community, our technologies can be deployed on commodity hardware to screen millions of people a day.
Algorithms that interpret fundus photographs to screen for diabetic retinopathy are not new. The academic community has released many papers in the last few decades, and there are a number of companies that provide screening as a service with various levels of automation built in. Google has announced a Diabetic Retinopathy screening project and Deepmind recently made headlines when it announced it was collaborating with the UK National Health Service to analyze millions of fundus photographs. Crucially, none of the commercial services are built openly. In a world where the best encryption techniques are open to ensure transparency, the same should be true when it comes to entrusting our medical data to others.
In the last year, there was a Kaggle competition that proved automated Diabetic Retinopathy screening was possible: the winners achieved accuracies on par with physicians. The top submissions to the competition released their code publicly, and despite the source code being online, it has not yet democratized diabetic retinopathy screening.
At OpenEye.io we are inspired by these efforts, and believe we can provide value through our basic principles:
- Our code is open source
- We provide a complete solution
- We use the latest techniques
Essentially, all code developed will be released to the world, open to continuing improvement and analysis. The solution we are building includes the screening code, as well as a full backend service and API designed to work on CPU based cloud compute services. Finally, our software is based on the cutting edge in Deep Learning, designed to be modular so the latest techniques can be applied as soon as the community invents them.
To conclude I will introduce the two repositories and what they do. The original demo was called Theia after the Greek titaness of vision, or the hypothesized planet that smashed into the Earth and formed the Moon. For this reason and the shortening of Diabetic Retinopathy to "DR," the server and API repository is called theiaDR. Realizing the phonetic similarity to the word theatre, naturally, the prediction server repository is called actDR.
The theiaDR codebase contains all the server and API logic, dataset, and model management. It takes user requests, such as image URIs, and sends the right data over a socket to an actDR predictor. Multiple actDR configured services can connect to a theiaDR server, so different predictions can be served simultaneously. Furthermore, images can be optionally cached and labeled in a database... all handled by theiaDR. Ideally, theiaDR will provide a consistent API and abstract away improvements and changes to our model.
The actDR codebase represents different models and their training environment. There is also a very lightweight service an actDR instance can offer to receive data from theiaDR and return predictions. By decoupling theiaDR and actDR, we don't have to worry about making actDR speak internet, and we can change it's underlying interface to theiaDR much faster.
In the coming weeks we hope to push code that generates state of the art results to our github, and we look forward to building a community together. Join the conversation at forum.openeye.io.