Working in industrial research is usually very motivating but occasionally it is also frustrating. You’ve just done something really cool but you’re not allowed to tell anybody outside the company about it. Indeed, in a small company there might not be anybody inside of the company who can even appreciate it!
I have worked on roughly 4 really cool projects since leaving academia at the end of 2017. And apart from some basic mentions in my blog (e.g. here and here) most of what I have done has been known only to a few key stakeholders.
Since leaving Fosanis last September I have had a visiting researcher affiliation at the Digital Health Accelerator of the Berlin Institute of Health. I have used my time to mentor a cohort of teams attempting to spin out their ideas; to work on a causal inference project; and, to write a paper about the structural aspects of medical AI products. This week, along with my co-author Vince Madai, we submitted that paper.
What’s it about?
Our paper is a how-to for medical AI. To be honest, the paper though detailed is relatively easy to read and the four figures pretty much summarise what we are trying to say. We would like the four figures, in particular, to form the foundation of the AI in Medicine equivalent to the Business Model Canvas.
In a nutshell, medical AI suffers from a lack of understanding of good medico-regulatory practices on the part of the participants. This is not just another consumer AI product. Additionally, medical (and other) experts tend to bring too much bias to the table when it comes to product design. At some point they have to accept that there are people who are incredibly good at designing products and they would benefit from their help. If you don’t get these components working well together then you will struggle to bring a product to the market. We try to explain the requirements to bring a common understanding of the roadmap for all stakeholders.
We divide the product development path into three phases. Our focus here is on bringing a single AI product to market. The first-phase involves essentially demonstrating an ability to solve a real-world clinical need. The second-phase is about really building your product. This involves (re-)establishing the team, a lot of outreach to clinical partners, and much iteration on solutions. Finally, the third-phase is a regulatory phase. These products cannot come to market without some form of regulatory procedure. Once the product is on the market, we also have a section on post-market issues such as surveillance and updates.
The missing manuals
Like all articles, ours had to choose a particular path in order to construct a narrative. The topic which I would most have liked to include, but which would have made this an entirely different article, is the building of a platform rather than a single solution. The answer to this requires a similar level of thought and insight as that put into the single product path and so we did not have space for it.
It has been a pleasure to distill the past 2.5 years of my hard-won experience into a document which I think will be genuinely useful for people working in this field.