On building software for the healthcare market

Hard, complex, multidisciplinary yet exceptionally rewarding

Photo by Hush Naidoo on Unsplash

My professional software experience has for the most part been in the B2B sector, working products spanning video-conferencing, distributed file systems and SQL engines. My most recent experience at Kheiron is my first foray into AI and healthcare. In a previous article, I covered the differences between AI products and software ones. This article is concerned with the differences I observed in developing software for the healthcare sector. 

First a bit of context about the sector, mostly driven from my own impressions with empirical evidence when available.

The healthcare market is massive. In the US alone, this market is estimated to be a ~$3T market employing about 2.4 people. This market is inclusive of health providers, IT, payers, pharma and more. Source: MarketDataForecast

Healthcare is a very data rich market. In the healthcare industry, various sources for data include hospital records, medical records of patients, results of medical examinations, medical images, genomics and more. Next time you are at your doctor’s office pay attention to the amount of data being collected from you.

The market is relatively conservative and is viewed as a laggard, particularly in adopting new technology. Healthcare software systems and infrastructure is still predominantly provisioned on-premises with cloud not being the default. Although that dynamic is shifting due to COVID-19. Additionally, the update cycles for software products in hospitals is measured in years, not days or months like SaaS products. The software products tend to be clunky with user experience an afterthought.

UI of Epic EMR

Lack of standardization is another prevalent dynamic, especially with clinical workflows and data. This is a key point worth expounding on. A clinical workflow is the set of interrelated or interacting healthcare activities, which are performed for a subject of care. Many of these activities are coordinated through one or more hospital IT systems like EMRs, PACS, RIS and so forth. The interactions between these systems can differ, sometimes wildly, between hospitals. Additionally these systems might be fundamentally different between hospital sites. In software parlance, they lack a common API or schema.

“If you’ve seen one hospital IT system, then you’ve just seen one hospital IT system” CIO of major US hospital system

Unsurprisingly, healthcare is a highly regulated industry. Just take a look at the diagram below which maps the regulatory landscape of healthcare in the NHS. Equally important, this regulatory landscape differs by country. Source BMJ

The most obvious - and critical - implication to building software products in healthcare is understanding how these products fit in a clinical workflow. Consider a product like Mia, which at its heart is an AI model for breast cancer detection. One - wrong - way to build and deliver this product is to wrap the model with a simple API. The input to his API is a set of images - a mammogram - and the output a real number between 0 or 1. Simple, yet completely unusable from a healthcare perspective. The product has to fit into the hospital’s clinical workflow. 

Therefore, not only will you have to discover the value proposition for your products, but you will have to assess how they fit into a clinical workflow. That requires having the right clinical expertise embedded on your product development teams. Building multidisciplinary teams spanning software development, product management, regulatory & clinical is a must-have in healthcare software companies. At Kheiron our product development teams will oftentimes include members of the following teams: Product, Engineering & Machine Learning, DevOPs, Regulatory and Clinical. The latter can be MDs, radiographers or radiologists. They are a critical component of our software development process.

Additionally, because these workflows will differ between hospitals, you will have to adapt your product to work with each. Unlike software which can be built once and deployed ad infinitum without much customization (think Google Docs), each time a software product is deployed at hospital, a resulting customization might be required.  Therefore, investing in a services function early on in your company’s lifecycle is definitely worth pursuing. This function will facilitate the adoption of your products by handling a multitude of tasks like customizations, data extraction and training. Data extraction and model calibration becomes increasingly important for AI products. That’s something I covered in a previous article on “hill-climbing” in AI. A services function can drive these efforts and drive the incremental improvements of AI products as they roll out into production. I had also mentioned how I believe that AI companies must have a services function - see this previous article for more details.

The complex and varied regulatory landscape of healthcare implies that you will have to invest in building a regulatory function and including that as part of your software development process. You cannot assume that you can ship your product much like you do with non-healthcare software products. The CI/CD pipeline for software products in healthcare requires one additional hurdle: regulatory. 

The Regulatory function is not there just to help you navigate the myriad of regulations your products have to adhere to. Regulatory also works with the Clinical function to create and manage clinical trials. Any product - software or otherwise - that is in the clinical pathway, will very likely have to undergo a clinical trial. Trials are typically part of the regulatory process (e.g. FDA approval), but more importantly they are a must-have to prove the clinical efficacy and safety of your products. Healthcare customers won’t deploy products in the patient pathway without evidence (trials) and possibly retrospective and/or prospective studies on their own data. 

Building software products, or any products for that matter, in healthcare is hard. The regulatory landscape is complex. The skills needed to build these products are much wider than typical enterprise software. The sales cycles are measured in years. The industry is a laggard when it comes to adopting technology. Why in the world would anyone want to do this then? The answer is, because it is simply worth it.

Healthcare is a massive market, as we touched upon earlier. Products that tend to be adopted in this sector become increasingly sticky and command very high ARPUs. The conservative nature of this sector amplifies this effect as well. Healthcare is reticent to change, therefore getting you new products into a healthcare workflow is very hard. On the other hand, once you do, it becomes increasingly difficult to remove these products. There’s a reason Epic’s EMR UI looks clunky and from the 90s - there aren’t other viable alternatives. At least not yet. The potential financial benefits of having wide-spread adoption of your products in this space can be spectacular.

More importantly,  healthcare products can have a profound impact on the quality of our lives. Mia isn’t just an AI model; it’s an incredibly powerful clinical product that can help with the early detection of breast cancer. That’s profoundly impactful and can help save countless lives. 

---