The purpose of the previous 2 articles was to pull back the curtain and expose the tremendous opportunity in medical imaging from a diagnostic as well as a systemic perspective. There is plenty of room to improve and the articles are available here: Part 1 Clinical and Part 2 Workflow.
This article will focus on places to start, including clinical data and publicly available resources as well as 3 things to keep in mind as you plan your project.
Particularly after reading how the system can be so inefficient, it can be daunting to know where to look to find an ally. By having a clinical expert on your team, you can navigate the process more smoothly to answer important questions. As we work to get to 1000 algorithms, I recommend that you find a clinical cofounder to help build your platform. Of course the big name academic and industry players are going to work on lots of problems to solve, however tech entrepreneurs like you can increase your chances of making a difference if you understand the context of the problem you’d like to solve.
As you are working on new solutions, keep in mind that there are trillions of data points in thousands of locations that are ready to be collected, cleaned and leveraged to gain some insight. They are currently spread out in many places, one in particular is electronic medical records.
Once you have a clinical expert on your team, they can help you determine where to start with all of this data to incorporate it in an imaging algorithm. Let’s say there is a 1.2 cm nodule in the lung on a CT scan. What difference does it make if this is found on the scan of a patient who is 17 years old with leg pain or 68 years old long time smoker? The difference is significant. Metastasis from bone cancer in a young patient can look very similar to lung cancer in an older patient. The addition of this reasonably straightforward clinical data can be very helpful. Here is a specific example of a recent lung cancer study, with clinical information and outcomes.
Data availability is a common limiting factor and when there are open resources it can get crowded. Chest x rays and CT scans are examples. In 2018 there was a Kaggle competition to evaluate pulmonary nodules and many chest CT scans were available to the participants. About the same time the NIH released 100,000 chest images, now available through a google site.
In addition, there is a list of 146 conditions with guidance from the American College of Radiology (ACR) which is a perfectly reasonable place to start.
There are pros and cons to this publicly available data. It is nice to find a foothold and a place to start but there will be more competition. It is up to you and your clinical team to determine where you would like to fit in that spectrum. Remembering article one, there are 10,000 clinical questions to answer and chest x rays and CT scans answer many, but there are lots and lots of others.
There are a few other things to keep in mind. I’ll talk about 3 here: solvable, helpful and commercially viable.
The problem surrounding the medical condition you wish to address needs to be technically solvable, meaning the ML engineers and data scientists have access to the data, be able to craft the algorithm and determine everything else to find the solution. If the clinical or imaging data is not usable or easily accessible, even the best idea won’t get off the ground at this time. Your technical teammates will be able to provide this insight, probably pretty early.
A new platform must be significantly clinically helpful, meaning there is an improvement in the clinical workflow and, ideally, outcome for a patient with the problem you are solving.
As an example, if someone was going to convince you to switch from your current email provider to a new one, how much better would it have to be to overcome the pain of switching? This is very important as we have seen many IT solutions in the healthcare industry and by the time we are trained and using a new system, the juice was not worth the squeeze. So a new email provider would, at a minimum, not create work for you, and on top of that be really, really great. A clinical cofounder is the person to guide this process.
Measuring outcomes can mean many things. Are the patients with a certain condition recovering faster with your new platform or is the condition prevented altogether? This is much different in medicine as compared with consumer technology as this claim must be supported by research. Your clinical co-founder can explain this in detail but in short, you will need a sound hypothesis, an academic center, regulatory clearance, time and money. This research will be the foundation for FDA evaluation, discussed in Article 5.
Finally this needs to be financially viable for you to grow as a company. Your addressable market will be shaped from the clinical question discussed above and you will create your teams assets and liabilities to present to customers or investors. Projecting realistic financial outcome is complex but you can at the very least educate yourself on the technical landscape of potential integration.
After your market research, you may find value in collaborating with health data platforms such as electronic health record. Radiologists’ workstations run on a PACS software which are regulated on many levels, so understanding how your software integrates is essential to selling your product directly to radiology groups, if this is your plan.
You and your team can research PACS vendors to identify strategic opportunities. Browser search: Radiology PACS AI integration or something similar will likely get you started. In addition, there are AI app stores who have been building networks to serve the 30,000 US radiologists and you may find a useful market there. Yet another option is to work with the CT or MRI or other scanner directly. Unless you are building an entirely new system, the take home point here is you should understand what the sockets looks like before you make the plug.
In the next article I will outline a specific clinical scenario, pulmonary embolism, and how you can work so solve a relevant problem, what data would be needed and potential market.