Ghosts of dead projects haunt the valley between health AI research and health AI implementation. These dead projects may have had state-of-the-art performance and exciting potential, but ultimately succumbed to real-world implementation barriers. Here I present a unified, comprehensive framework of barriers to health AI implementation, and I show how to transform them into the eight pillars of success.

I developed this framework based on my experiences as a physician, AI PhD, health AI founder/CEO, and now as an independent health AI consultant. If you’re an entrepreneur building a health AI company, or a researcher curious about the mysterious path from R&D to deployed system, then read on!

Root Barrier: Health AI is a new field, causing fragmentation and poor interdisciplinary understanding

In the next two sections I’ll discuss two root barriers that underlie and amplify the eight actionable barriers.

The first demonstrable healthcare AI was created in the 1970s. INTERNIST-1, created in 1971, was the first medical AI consultant. The first AI-enabled medical device was the PAPNET Testing System, approved in 1995. However, it wasn’t until 2017-2018 that the age of deep-learning-based healthcare AI emerged, when deep learning models achieved high performance on narrowly-defined medical diagnostic tasks on curated datasets, including identification of melanoma and
diabetic retinopathy. The first FDA approval for a clinical cloud-based deep learning model occurred in 2017, for the Arterys medical imaging platform. So even though researchers have been working on “health AI” for over 50 years, the modern age of deep-learning-based healthcare AI is only nine years old. It’s an elementary school student.

People may push back and say, “Are you implying that all the work before 2017 doesn’t count?” Certainly not. Some of the barriers I discuss in the rest of this article, like workflow barriers, were just as applicable in 1970 as they are today. But other barriers are unique to deep learning, and I’d argue that deep learning represents a significant enough technological breakthrough to mark 2017 as the start of a new kind of health AI.

Nine years is not long in the history of science or industry. The field of healthcare AI is fragmented, including people from many different backgrounds–AI technical experts, clinicians, and businesspeople. Many health AI professionals primarily trained in one field (AI, healthcare, or business) and learned about the “other fields” on the fly. The intersection of AI, healthcare, and business is also so incredibly vast that no single human could possibly learn everything in every field, which is why we need teams. Sometimes team struggle with poor interdisciplinary understanding and communication, which worsens all of the actionable barriers discussed later in this article. Promising teams can fail to recognize the actionable barriers exist, fail to recognize which barriers are manifesting in a specific projects, and fail to find solutions. There is no way to “solve” healthcare AI being a new field, because the only solution to that is allowing more time to pass, but interdisciplinary communication can be improved through continuous learning. There is always something new and exciting to explore in this rapidly-evolving field.

Root Barrier: Healthcare is inherently difficult

Healthcare is inherently complex and messy. Healthcare delivery requires numerous skills–intellectual, emotional, social, and physical–so despite the hype, we are not getting a “robot doctor” or “robot nurse” anytime soon. It may seem silly to list “it’s just hard” as a barrier, but I think it’s worth pointing out, because a common pitfall is trying to pretend healthcare is easy. Oversimplification and ignoring nuance and edge cases can kill a project, or a patient.

The eight addressable barriers to health AI implementation and how they become pillars of success

Now we’ll dive into the eight addressable barriers to health AI implementation, meaning the barriers that you can, and must, do something about if you want to stably deploy healthcare AI. If any one of these barriers is ignored, your initiative will fail, no matter how well you tackle the rest of the barriers.

The barriers are: choosing the wrong problem to solve, and problems with data, labels, modeling, workflow integration, sales and marketing, business models, and multiple axes of bias.

The pillars of success come from inverting the barriers: choosing the right problem to solve, and good data, labels, modeling, workflow integration, sales and marketing, business models, and fairness.

Actionable Barrier #1: Choosing the wrong problem to solve

The most fatal mistake for health AI implementation happens right at the beginning, at the idea phase, when you pick what problem to solve. There are numerous kinds of “bad problems”:

A problem nobody will pay to solve. The customer doesn’t feel enough pain from this problem, so they are not willing to pay for a solution. Or they do feel enough pain from it, but they are too budget-constrained and cannot afford to pay.

A problem that’s only hypothetical, artificially created based on a public dataset. E.g., predicting a patient’s age from a CT scan–in reality you’d just look up their age in the electronic health record, or ask the patient their age, or just forget their age and treat their medical problems.

A problem that is more profitable not to solve due to perverse reimbursement incentives (common in the U.S.). For example, a fee-for-service model involves the insurance company paying a health system to deliver care. With a fee-for-service model, it might be more profitable for patients to get a surgical complication requiring complex management, and so there is a perverse incentive not to adopt an AI system that does early detection of surgical complications. In a value-based care setting the incentives are more aligned: the health system loses money with the complication, so they’re financially incentivized to use AI for early detection and prevention.

A problem that does not need “AI” to be solved because there are equivalent or better solutions using traditional software engineering (e.g., workflow redesign, a new mobile app), or, there’s an entirely non-technical solution (e.g., hiring new staff, policy change).

A problem that’s too rare. It’s an edge case and its operational value is too low.

A problem that’s too broad. For example, as of this writing, “an AI that can completely replace a radiologist” is framed way too broadly to be solvable (or salable). More narrowly-defined problems, like using AI to catch strokes earlier, are better. You want a Goldilocks problem: not so rare that it never happens, but not so vast that you’ll never solve it.

A problem that’s selected primarily for research publication purposes. A problem that has a dataset available and a technically novel solution might be publishable in a journal, but that doesn’t make it deployable. Research has its own value that is separate from deployment. The main value of research is in showing what could be possible. We need research. It’s just important not to assume that “publication = deployment” or that “publishable = deployable” because they are totally different.

Pillar of Success #1: Choosing the right problem to solve

How do you choose the right problem to solve? Identify who your customer is. Who are the customers? They could be patients, clinicians or private practices, health systems, insurance companies, the government, pharma companies, etc. Do extensive customer discovery. Ask your potential customers to financially support development of the solution. Ensure it’s a real problem happening now, and happening often enough. Quantify the operational value of a solution and understand how and why you’d be reimbursed. Make sure the problem is as narrowly-scoped as possible. Ideally you start with the smallest possible slice that still has concrete value–this is your minimum viable product. And don’t worry about whether the problem/solution is “novel enough” to be publishable, because tons of novel things get published every day and never get deployed. If you want to implement health AI, it actually helps you if there’s existing research on the topic, because then you’re starting from something rather than nothing. In other words, sketch out the entire business case for solving that problem with AI before you even try to solve it. Implementation is fundamentally a business endeavor.

Brief aside about types of health AI

AI is an immense field that technically encompasses both rule-based expert systems and machine learning. Machine learning means learning from data without being explicitly programmed, and encompasses classical machine learning, deep learning, generative AI, and AI agents. The next three barriers do not apply to rule-based systems, but they do apply to machine learning, which is usually what people are thinking about when they say “health AI” anyways.

Actionable Barrier #2: Data problems

Data is the foundation of model performance. If your dataset is inadequate, no amount of modeling can miraculously pull your performance up to state-of-the-art. Data is also an important moat because it’s hard to steal. Problems with data that can derail your implementation:

The data is messy and hasn’t been cleaned. E.g., units are inconsistent, lab reference ranges don’t align, different protocols were used to collect the data at different sites, diagnosis codes use both ICD-9 and ICD-10, some of the images are JPG and some are DICOM, etc. Unaddressed or improperly-addressed messiness can destroy models.

The data has been cleaned incorrectly. There’s a mistake in the data cleaning that’s led to future information leakage or destruction of clinically important details or frank errors. De-identification has been too aggressive and has destroyed some needed context. Unstructured data has been parsed incorrectly. Clinical abbreviations have been misinterpreted. There’s a data dictionary or granularity mismatch between deployment sites that hasn’t been addressed.

The data is fragmented or incomplete. For half your patients you have variables A, B, and C, and for the other half you have variables D, E, and F, but you really want A, B, C, D, E, and F on everyone. Or some of your patients have complete data, but others don’t.

The data is not diverse enough and does not match the deployment population. Data comes from only a single site, like one academic medical center, with no data from elsewhere for additional training or validation. It excludes community settings, rural settings, safety-net hospitals, pediatrics, geriatrics, pregnant women, disabled patients, non-English speakers, or uninsured patients that are part of your intended deployment population. If you train on a non-representative patient population, your model might get good test set performance but bad or dangerous real-world deployment performance.

Data doesn’t include enough rare examples. Of course by the definition of “rare” you’re going to have fewer examples of rare classes than common classes, but there can be a big performance difference between having only one rare example vs. having a couple hundred.

Missing data is not missing at random. E.g., missingness encodes clinical judgement or socioeconomic status.

Data encodes vendor-specific quirks. E.g., different CT scanners in different departments have different noise patterns. This can enable models to learn spurious correlations instead of real medical concepts.

The data is too hard to get and too small. It’s impossible to collect enough of the data you want, because it’s so hard to aggregate. Or perhaps it can’t be collected at all due to privacy concerns–e.g., you’d be hard-pressed to collect a dataset that’s derived from a doctor wearing a GoPro while they wander around the hospital.

Pillar of Success #2: Good data

How do you curate good data? Ensure that the data is cleaned by engineers who understand enough about the domain that they do it correctly. A clinician should be directly involved in important conceptual decisions about data cleaning to avoid inadvertently damaging the dataset. Sometimes with fragmented or incomplete data, imputation is an option, but this needs to be done carefully. The data should be collected based on where you intend to deploy your models, so that your training dataset matches your deployment dataset as closely as possible. If rare diseases or rare outcomes are important to your use case, be sure these are represented. Talk to clinicians about whether they’d expect non-random missingness. Explainability methods can help uncover if models are exploiting non-random missingness or vendor-specific quirks.

You need to be able to either collect or purchase enough data to train your models. Dataset size is a huge barrier in many health AI use cases because it’s hard to collect enough high-quality data. There’s no hard-and-fast rule about “how much data is enough” but a rough rule of thumb is: with a few hundred examples per class, the model may show signs of learning something, but it’s unlikely to perform well; 5,000 samples per class can yield more stable models with decent performance; and 10,000+ samples per class will enable more comprehensive modeling that takes better advantage of deep networks’ power and flexibility. But of course the amount of data you need depends on how hard the task is, how much the data varies within and between classes, and what performance you need to achieve. You can always do R&D with a smaller dataset just to see where your starting performance is, and grow your dataset from there (just don’t over-use your test set). Even if you only have a few thousand examples total when you’re getting started, everyone has to start somewhere. Be sure to distinguish between “research prototype” and something you’d actually deploy. Don’t deploy something that doesn’t work.

Actionable Barrier #3: Label problems

If you’re doing unsupervised learning, you don’t need labels. However, in my experience, supervised learning is much more common in healthcare, and so chances are you will need labels, and problems with your labels can derail your project. Label problems include:

No true ground truth actually exists. This could be because your problem is too broad: e.g., predicting if someone is “healthy” won’t work because how exactly have you defined “healthy”? Or a more insidious problem: predicting death. As it turns out, getting a ground truth for whether someone is alive or dead can be shockingly difficult because there is no centralized accurate registry with this information, and if somebody dies outside the hospital they can “live on” forever in the electronic health record (EHR), reaching absurd ages (is this 102-year-old who hasn’t been seen in three years still alive somewhere, or did she die?)

Labeling guidelines are undocumented or change over time. If the labeling guidelines are not clearly specified then different labelers might have different ideas of what constitutes class A vs class B, which will confuse the model. Insufficient documentation can also lead to random evolution of how labelers interpret the labels over time.

Excessive variation in labels between clinicians, without a scalable adjudication process. Excessive labeler disagreement and high inter-rater variability is very common in healthcare. There is variation across individuals and by experience level, specialty, and region. There are even variations within the same individual, based on how long they’ve been doing the labeling task and how tired they are. Some types of labeling are commonly known to have disagreement between labelers, such as histopathological tumor grading, diagnosis of certain mental health conditions, or interpreting fetal distress patterns during labor. If your dataset contains systematic unresolved differences in how labelers assigned labels, this can cap your model performance.

Labels encode bias: racism, sexism, ableism, ageism, etc. Labelers may have unconscious (or conscious) biases that they bring to their labeling task. Even if you extract your labels from the EHR, you need to check the labels for bias, since there are inequities and biases in the current practice of medicine.

Automatically-extracted labels encode other information. If you’re pulling labels out of the EHR, be aware that they could encode clinician convenience, staffing constraints, night shift vs day shift, time pressure, institutional policy or culture, defensive medicine/medicolegal protection, outdated clinical guidelines/historical practice, reimbursement/insurance/billing requirements, or resource availability.

Pillar of Success #3: Good labels

How do you collect good labels? First, make sure you’ve defined the problem well enough that your ground truth exists, and your labels are clear concepts that can be defined in writing and/or pictures. Create comprehensive labeling guidelines. Make it mandatory for your labelers to read and understand the labeling guidelines. Ensure the guidelines don’t change over time, or, if there’s a need for a change, make sure your labeling guidelines are versioned and this is tracked in your dataset. Quantify the inter-rater variability in your team of labelers. For example, give each labeler separate access to the same set of 200 examples, so that you have everyone independently label the same 200 examples. Then you can calculate statistics like Fleiss’s kappa, Krippendorff’s alpha, Jaccard similarity, or Cohen’s kappa to understand quantitatively how well your labelers agree. If agreement is poor, you may need to improve your labeling guidelines or labeler training. Since you’ll never get perfect agreement, you’ll need a well-defined adjudication process in which controversial examples are collaboratively addressed by your team of labelers to determine a final consensus label. To check for biases in your labels you can quantify the distribution of labels across demographic categories (e.g., genders, races) or categories of information you wouldn’t want encoded (e.g., night shift vs day shift), and see if there are systematic differences.

Actionable Barrier #4: Modeling problems

Now you have your dataset and your labels, so it’s time to dive into modeling. What can go wrong with modeling?

No modeling approach exists to solve the problem yet. If you’re a researcher this would be good news for you–because then you could devote several months or even a whole career to solving this previously-unsolvable problem. But for implementation on a timescale of “a few years” this would not be good news. An example: currently there is no modeling approach that lets a robot learn sufficient fine motor skills to reliably administer vaccines to any patient, and solving that is going to take more than 6 months of R&D.

Black box models learn spurious correlations instead of real clinical concepts. All neural networks are black-box models, because they are not inherently interpretable and they do not inherently explain their decisions. Black-box models can learn spurious correlations. An example of this kind of shortcut learning is models predicting boats in images through the presence of water–or, something I once observed, models predicting heart disease by looking at the body wall to check for obesity.

Black box model explanations are misleading. No explanation method can perfectly explain a neural network. Some explanation methods have issues. A few years ago I worked on a research project that showed that the popular model explanation method Grad-CAM sometimes produces misleading explanations, and I developed an alternative method HiResCAM with provable faithfulness.

The modeling approach fails to address temporal drift–in patient populations, clinical practice guidelines, coding standards, EHR templates, measurement devices, lab assays, or imaging protocols.

Model performance is measured using the wrong performance metrics. Performance metrics relevant for deployment are not necessarily the same as the performance metrics needed for journal publication. Take classification tasks as an example. There are many papers for healthcare classification tasks that report only threshold-independent performance metrics like AUC and AUPRC. This is fine for a research setting but in deployment you don’t actually care about how the model performs across all decision thresholds, you care about how the model performs for the specific decision threshold that you’re using when it’s deployed. Especially with highly imbalanced datasets it’s possible to have a high AUC or high AUPRC, and wretchedly bad performance at some specific decision threshold. The model could also be poorly calibrated meaning its output probabilities can’t really be interpreted as probabilities. Or the model could have good performance overall, but bad performance for a specific subgroup.

Pillar of Success #4: Good modeling

How do you build good models? Make sure the overarching problem you’ve selected is actually solvable with existing methods, if you want to deploy a solution anytime soon. If you have a choice between an inherently interpretable method like logistic regression and a black-box model like a neural network, choose the interpretable method. Especially for tabular data, neural networks do not always outperform simpler, more interpretable methods. If you must use a black-box model–e.g., you’re doing a task on images, video, audio, or other high-dimensional data–then definitely leverage appropriate explainability techniques with detailed clinician review of explanations to check that the model is using relevant aspects of the data when making its predictions. Measure real-world performance on an ongoing basis to catch performance degradation, and implement a retraining plan at a realistic cadence, with model versioning and an ability to roll back. Select appropriate performance metrics. For classification, you can pick a decision threshold by optimizing a metric like F1 score on the validation set, and then calculate accuracy, precision, recall, F1 score, or other threshold-dependent performance metrics relevant to your use case. Calculate calibration. If the model is not calibrated, then calibrate it, using a technique like temperature scaling. Analyze performance by subgroup (e.g., demographics, sites, shifts, clinicians, acuity levels, disease prevalence, season). Remember that “accuracy” is not the same as “clinical usefulness.” Prediction ≠ intervention ≠ outcome, so you should have a clear understanding of how the predictions will be used to determine interventions, and how those interventions can affect outcomes.

Actionable Barrier #5: Workflow integration problems

At this point you have great data, labels, and models. That’s still not enough for a successful deployment. This section considers clinical workflow integration, for health AI tools that are meant to tie in with an EHR or PACS system or other piece of enterprise software. Many of the concepts described in this section are also applicable to consumer-facing apps, because regardless of who your customer is, you’ll need a good user interface. What can go wrong with workflow integration?

Users hate the workflow integration. It can be very hard to figure out what kind of workflow integration users will like, but there are some common patterns that users reliably hate: extra clicks, extra logins, frequent context switching, the tool appearing at the wrong time or wrong place, excessive alerts and interruptions, high latency, predictions arriving after decisions are made, and lack of actionable recommendations. The user interface can be confusing, not mobile responsive, and non-customizable or excessively customizable in an overwhelming way. It can also be a problem if there’s no override process or mechanism for the user to disagree.

Workflow integrations are difficult due to EHR restrictions. The EHR can limit what user interfaces are possible, making it difficult to create a nice user interface. The user interface may be ugly, brittle, or break with API changes. The huge variation between EHRs means a new integration is needed for every EHR.

Behavior change is hard even if the workflow integration was designed well. Training may be inadequate or forgotten. Problems can also arise from lack of just-in-time help or lack of feedback channels. There may be under-use due to fear of liability, surveillance, replacement, or punishment for override.

Pillar of Success #5: Good workflow integration

How do you build a good workflow integration? For tools intended for private practices or health systems, EHR integration is mandatory. Never build a completely separate app or portal because you are asking too much of your user: you’re asking them to remember that your app exists, remember how to find it (icon or URL), remember their username and password, and remember how to use it. You’re also often asking them to manually key in information that already exists in their EHR which is often the straw that breaks the camel’s back. Pick your target customers carefully so that you have a limited number of EHRs to integrate with. Hire professional designers who are experts in user interfaces and user experience (UI/UX). Clinicians should be involved in the design process, early enough–not brought in at the very end. (Here I’m using the term “clinicians” assuming clinicians are your users, but you can drop in whoever your end user is.) The right clinicians should be consulted–e.g., the specialty relevant to the tool. Clinician collaborators must be educated to realize the technical possibilities when brainstorming what kind of integrations they might like. Extensive interactive user testing is necessary, with clinicians not involved in the design process, to determine if the workflow integration is truly intuitive. Create a formal training and onboarding process to teach clinicians how to interact with and benefit from the software, and ensure that they have a means to deliver feedback.

Actionable Barrier #6: Sales and marketing problems

Sales and marketing encompass the process of convincing your potential customer to try your product, pay for it, and keep paying for it. Even if you have the most amazing dataset, labels, modeling, and workflow integration, your health AI implementation can fall apart if you don’t have adequate sales and marketing. What can go wrong on the sales and marketing side?

Misleading marketing. Overhyping model capabilities and under-communicating limitations damages trust, especially in a safety-critical domain like healthcare.

Buzzword marketing. The marketing relies too much on buzzwords like “AI agents” without any explanation of clinical or operational mechanisms, which makes sophisticated buyers skeptical.

Unclear marketing with no proven ROI. It’s not clear what problem you’re solving, who you’re solving it for, what your solution does, or what the return on investment (ROI) will be. The customer pays X and they get __? The value proposition is too vague.

No proof points. Lack of case studies, endorsements, or published outcomes.

Marketing to the wrong stakeholders. E.g., you market to the C-suite or IT and close a deal, but completely fail to communicate with actual clinician end-users, leading to low adoption and eventual loss of the customer.

Sales/marketing misalignment. The marketing team generates leads that sales isn’t equipped to close.

Sales fails to get stable organizational buy-in. The sales team can’t identify a stable executive sponsor or internal champion, can’t keep up with leadership turnover, or doesn’t ensure clear budget ownership by a specific person, division, or department.

Sales timelines don’t account for lengthy, opaque, complex procurement. Especially when selling to health systems the sales process can take months.

Pillar of Success #6: Good sales and marketing

How do you achieve good sales and marketing? Health AI startups sometimes fixate on the “health” part and the “AI” part and only retroactively think about sales and marketing. Don’t do that. Sales and marketing are not afterthoughts, they are critical. Make sure someone with health tech sales/marketing expertise owns this part of the business. Good marketing is hard. Closing deals is hard. The marketing should be honest and specific, with clear ROI and compelling case studies. Different marketing materials are needed for different stakeholders–what a doctor cares about isn’t the same as what a CFO, compliance officer, or IT person cares about. Marketing and sales should be clearly aligned on the ideal customer profile. If the target customer is a large organization, allocate sufficient time for closing every deal. The ROI should be concrete and department-specific, with a laser-focused financial or workflow case for using the AI solution, built around actual numbers and ideally evidence from past deployments. You need proof to get customers but you need customers to get proof, which is a real chicken-and-egg problem. If you’re starting from 0, check out healthcare-focused accelerators like Mayo Clinic Platform Accelerate or the Cedars-Sinai Accelerator. Once you have customers, regularly remind them of the benefits they’re experiencing from your product–for example by sending a monthly or quarterly email with information about their usage and corresponding cost savings or revenue.

Actionable Barrier #7: Business model problems

All the way back at Barrier #1, I described how at the idea phase it’s important to flesh out the business case for the health AI implementation as thoroughly as possible. But there’s only so much you can do at the idea phase, and inevitably you will gather much more data about your problem space as you start building and selling within it. There are numerous potential problems with business models that can derail health AI implementations, all unified by one underlying theme–problems with the “stably making money part”:

No reimbursement pathway. The health AI solution doesn’t have a billing code. Or it did have a billing code, but then coding rules changed and it doesn’t anymore. The solution doesn’t measurably reduce costs or increase revenue. Due to misaligned incentives, it’s impossible to get paid for the innovation–e.g., a model that saves lives but not in a manner that saves money. It’s upsetting but true that especially in the U.S. healthcare system there isn’t always a clear path from “benefits a patient” to “saves or makes money.”

Scaling challenges. Not enough runway to set up sufficient scaling infrastructure: logging, error catching, advanced privacy and security practices, scalable software development practices, scalable sales and marketing. Compute gets too expensive. There are hidden operational or maintenance costs.

Regulatory and legal processes are slow and expensive. There are delays in deployment due to HIPAA compliance, contracting, FDA requirements, etc. Risk management blocks deployment. Model changes trigger re-approval.

Insufficient fundraising. Money runs out before all parts of the business model can be satisfactorily stabilized, including the sales/marketing and the tech.

Excessive fundraising. Raising too much too soon can inflate valuations and make it impossible to fundraise later.

Pillar of Success #7: A good business model

How do you design a good business model? On a regular, scheduled basis, e.g., once a quarter, set aside time to think about the business model. Make sure there is a clear reimbursement pathway. Understand how you want to handle scaling–bootstrapped companies can choose to scale more slowly while VC-funded companies must scale rapidly. Engage regulatory consultants early on to ensure enough budget for the timeline and requirements. Fundraise from appropriate sources–not every startup should be or needs to be VC-funded, but some ideas need to be VC-funded to have any hope of breaking through. If relevant, apply for grants like NIH or NSF SBIR grants.

Actionable Barrier #8: Multiple axes of bias

The healthcare AI field includes multiple axes of bias that can damage health AI implementation in different ways:

Bias against implementation research vs “technical novelty.” “Hard problems” are sometimes narrowly defined as “modeling problems.” Implementation failures due to social, cultural, or business reasons can be dismissed as “soft.” There is under-investment in implementation science.

Language bias. Some health AI is biased towards the English language.

Western healthcare bias. Some health AI is biased towards Western healthcare assumptions, treats global health as an edge case, or doesn’t account for cultural variation.

Bias against safety. “Move fast and break things” tech culture is inappropriate in clinical AI. Ethics and safety are sometimes treated as branding. People can be penalized or fired for raising safety concerns.

Underrepresentation of many groups. Health AI in the U.S. suffers from underrepresentation of women, people of color and people of the global majority, caregivers, people of lower socioeconomic status, and people who trained at non-elite institutions. These groups are underrepresented as employees, as leaders, on panels, and as grant recipients. Technical cultures can be hostile or dismissive to members of these groups, including tolerating or minimizing harassment, misattributing credit, requiring a disproportionately high bar for credibility, or frequently questioning technical expertise. A homogeneous health AI workforce leads to blind spots in problem selection (narrowing what health AI applications are sought after, funded, or prioritized) and blind spots in data interpretation, label design, workflow design, and patient experiences. Conferences can be inaccessible financially or geographically, or to caregivers of children and the elderly. Speaking up about these issues can be considered “unprofessional.”

Bias against simple models and rule-based systems. Trend-chasing and fixation on buzzwords means everyone wants an “AI agent” even if what they really need is a well-implemented simple model or rule-based system. Funding rewards technical novelty over reliability, deployability, and safety. Prestige can be tied to model complexity. Target customers can assume something is better if it’s an “AI agent” even in situations where an AI agent is a completely inappropriate solution from a modeling standpoint.

Pillar of Success #8: Fairness

How do you achieve fairness across these different axes? It’s important to recognize that implementation research is just as important as technical research and that advances on both fronts are necessary for stable, successful deployment of health AI. Health AI solutions must be built with the deployment population in mind, and should include the appropriate languages, healthcare assumptions, and cultural nuances. Safety must be central, and not an afterthought. Companies should ensure they recruit candidates from different backgrounds and create welcoming work environments where everyone is respected. Simple models should not be automatically dismissed. The modeling strategy must be appropriate for the problem being solved. Sometimes a rule-based system is the right solution (e.g., many forms of automated lab test interpretation). Other times, a custom deep learning model may be appropriate (e.g., a narrowly defined image interpretation task). In some cases an “AI agent” might be necessary (e.g., a voice agent for scheduling appointments) but one should never assume that something is “better” because it “sounds fancier” or is more complicated. Many times in health AI, simpler is better.

But what about My Favorite Barrier? Why isn’t it on your list?

What about legal or regulatory barriers? I argue that regulatory barriers are actually subcategories of business barriers and technical barriers. Why? Because there are two main ways that regulation can derail a health AI initiative: (a) regulatory approval takes too long and the company runs out of runway (in which case, having more money would have solved the problem and this is a subcategory of Barrier #7); or (b) regulatory approval is denied because the technology is not good enough (in which case, better data or labels or modeling, Barriers #2/3/4, would have solved the problem).

What about limited clinical validation / limited real-world validation? Why might a model have limited clinical validation? Again, this is really part of other barriers. For a retrospective study, validation could be limited because data is hard to get (data problems, Barrier #2). For a prospective study, validation could be limited because you can’t convince clinical sites to let you validate it (bad sales/marketing, Barrier #6) or because you can’t afford the cost of proper prospective clinical validation (money, Barrier #7). Or perhaps, you do complete a prospective study and the results are bad because your technology is bad–that’s a technical issue, related to data, labels, or modeling (Barriers #2/3/4).

What about ethical barriers? If someone is refusing to adopt your AI technology on ethical grounds there are two possibilities: (1) Your AI tech actually is unethical. In that case, please just stop. (2) Your AI tech is ethical, but you’ve presented it in a way that makes it seem unethical. This is a sales/marketing problem (Barrier #6). (Aside: The sad reality is that ethics are rarely a barrier to having a profitable business. Just look at the weapons industry–it sells products to kill people, and it’s highly profitable. One would like to think that healthcare is Nobler and Above All That, but there are plenty of cases where people have perverse incentives to create bad healthcare AI for business reasons. Once someone approached me asking if I’d like to be part of a project that would predict “patient ability to pay” so that patients who were unlikely to be able to pay would be funneled to cheaper, worse care. I declined the project because it was ethically repulsive, but I imagine they simply turned around and hired someone else.)

What about trust as a barrier? Again, there are two possibilities: (1) Your models are trustworthy, but people don’t trust them. This could be because you have a bad workflow integration (Barrier #5), or you’re not using the right marketing language to describe what your models do and why they deserve trust in a way your target audience understands (Barrier #6). Or (2) Your models are not trustworthy and people are correct not to trust them–because you have technical problems (Barriers #2/3/4), and you need to solve those before you deserve anyone’s trust. Or perhaps your models are trustworthy only in one narrow setting–say, English-speaking high-income urban areas–and you haven’t realized that deployments beyond those areas require adaptation (Barriers #2 and #8).

What about privacy and security risks? This is a data handling problem (Barrier #2) and a workflow problem (Barrier #5).

Failure modes

There are many failure modes for health AI, including limited or no adoption; poor overall performance; bias (which can be thought of as poor performance for a specific subgroup); safety issues including patient harm; and running out of money. I address many of these in the sections above. Sometimes multiple failure modes occur simultaneously.

Who solves each barrier?

Healthcare AI implementation is inherently interdisciplinary. Successful health AI implementation requires technical, clinical, and business expertise, and teams should be assembled with people who can handle each of these domains. Both domain-specific and interdisciplinary knowledge are critical. Everyone can brainstorm initial ideas. Any selected idea should be pressure-tested from as many angles as possible. Pivots are okay–they are a natural result of “learning by doing.” An engineer can solve data, labeling, and modeling problems, often working with a clinician. Clinicians can provide expert labels and workflow insights. A user interface designer working with end users can solve workflow problems. Sales and marketing experts can identify and acquire customers. Businesspeople can refine the details of the business model and influence company culture.

Successful health AI implementation

It’s important to remember that for the 80% of health AI initiatives that fail, there are 20% that succeed–and knowing the eight pillars of success discussed in this article is an important step towards becoming part of that 20%. With a great idea, and good data, labels, modeling, workflow integration, sales and marketing, business models, and fairness, as well as with a bit of luck, you may create the next big breakthrough innovation in the health AI space. Feel free to reach out if you’d like to work with me–I help companies of all sizes with their AI strategy and implementation as an independent consultant.

As an independent researcher (MD + AI PhD + 7 yrs prior founder/CEO experience), I build and evaluate cutting-edge healthcare AI for startups. Contact me to learn more.

Want to be the first to hear about my articles bridging healthcare, artificial intelligence, and business—and get a free list of my favorite health AI resources? Sign up here.