Manish Jobanputra runs MOC Cancer Care & Research Centre, one of India's most scaled medical oncology networks with 30 centers, 60 full-time oncologists, approximately 30,000 patients a year, and a database of 400,000 patient records built over eight years. At Elevation Capital's Healthtech Roundtable, hosted in partnership with The Healthtech Collective and The AI Collective, Vishap Rana sat down with him to understand what it actually looks like to build and deploy AI in a live clinical setting. For anyone building AI products for healthcare service providers, Manish's account is one of the most grounded perspectives available on what works, what doesn't, and why.

Here is an excerpt from the conversation.

To start, can you help us understand the scale of the oncology care problem in India and what it means for how AI gets built and deployed?

Any honest conversation about AI in Indian clinical settings for oncology has to begin with the magnitude of the underlying problem, because the numbers shape everything: what can be automated, what cannot, and where the structural gaps are largest.

India registers approximately 1.5 million new cancer cases each year. The true burden of active patients can be considerably higher than reported estimates, somewhere between four and five million, once undercounted and subclinical cases are factored in. Treating this population falls on a workforce of roughly 2,000 to 2,200 medical oncologists nationwide.

The geographic distribution of this shortage makes it considerably more acute than the ratio alone suggests. Over a hundred medical oncologists practice in Bangalore. Travel two hundred kilometers in any direction from a metro, and the probability of finding even one drops sharply toward zero. Patients, many of whom require dozens of treatment sessions across months, bear the cost of that distance in time, money, and delayed diagnosis. The cancer burden is distributed across the country but the specialist concentration is not.

Before MOC could think about AI at all, what did it take to build the right foundation?

We started eight years ago with an advantage most incumbents lacked: web-based systems from inception rather than inherited desktop-era infrastructure. Even so, the early years involved patching together three or four different vendor solutions, one handling appointments and billing, another managing clinical records and inpatient care, none of which were designed to communicate with each other or to scale across dozens of centers.

The limitations surfaced at scale. With hundreds of concurrent users across multiple locations, the seams started to show. These vendors were building products for small clinics and had no interest in customizing for a more complex operator. That was a problem for us, where patients regularly move between centers and a doctor in one city needs to see everything recorded about that patient in another.

Our response was to build a proprietary EMR over four years, with a dedicated Bangalore-based technology team. The architecture was web-first from day one, designed for complete integration across the patient journey and, critically, for structured data capture on everything, including external reports processed through OCR and AI scanning. That database now holds approximately 400,000 patient records and underpins every AI application we are evaluating.

The lesson for founders building in this space: the quality of clinical AI output is almost entirely determined by the quality of structured data feeding it. An EMR capturing free text and scanned images in unstructured form creates a liability rather than a foundation for clinical intelligence.

Telemedicine, built on top of this infrastructure, has been the most direct way we have addressed the access gap. For cancer specifically, this goes well beyond a quick video call. Patients can upload their reports for a second opinion, consult one-on-one with a specialist over video, or have their case reviewed by a panel of doctors in a virtual tumor board. What this means in practice is that a patient in a smaller city no longer has to travel to Mumbai or Bangalore just to find out what they have and what their treatment options are. The distance problem, for the diagnostic and planning phase of care, largely dissolves. Where telemedicine cannot help is in the treatment itself. Surgery still requires an operating theater, radiation requires a bunker with a linear accelerator across 25 to 35 sessions, and chemotherapy requires an infusion center. The physical infrastructure for treatment has no remote equivalent.

You have actively piloted AI tools across the clinics. What has actually worked, and where have you hit walls?

Our experience with AI in the clinic has been more mixed than most vendor presentations suggest. Two areas in particular reveal how sharply the Indian clinical environment shapes what is actually feasible.

AI scribes, tools that convert spoken consultation notes into structured records, work well in dictation mode, where a physician speaks directly to the system after a consultation. The ambient listening variant, where the model records and structures conversation in real time, has proved considerably harder. An Indian outpatient department is rarely a controlled environment: multiple patients and three or more relatives in a room simultaneously, questions arriving from multiple directions, phone interruptions mid-consultation, and staff entering with urgent queries about entirely different patients. Models that handle multilingual switching within a single sentence, a common feature of Indian clinical speech, have largely solved the accuracy challenge. The remaining problem is that the AI cannot tell which conversation in the room is actually about the patient being seen. One solution we are testing: a microphone the doctor switches on at the start of a consultation and off at the end, so the AI only captures what's relevant.

Patient engagement AI, tools for post-chemotherapy monitoring, toxicity tracking, and routine query handling, present a different kind of problem. The tools themselves function adequately as standalone products. The failure point is workflow continuity: when patients interact with an engagement layer that sits outside the EMR, they assume they have communicated with their care team. The clinician, reviewing notes in the EMR, has seen nothing. The resulting expectation mismatch is exactly the kind of disruption that erodes physician trust in AI tools quickly. EMR integration is the minimum viable condition for clinical adoption here, rather than a refinement that can come later.

Where do you see the most meaningful opportunity for AI in your context?

The use case I see as most valuable is using our database of 400,000 patient records to find historical cases similar to the one a doctor is currently treating. Medical oncology is among the more protocol-driven specialties in medicine; treatment paths are relatively well-defined by stage and biology. That means our database almost certainly contains patients who looked a lot like the one sitting in front of the doctor today, and surfacing those cases and their outcomes could meaningfully inform the treatment decision.

The user experience design for this matters as much as the model. The system should ideally not confront physician judgment. It should surface potential discrepancies, visible on the EMR interface, clickable through to internal historical data and external literature, and entirely ignorable when the physician finds it irrelevant. A presence that exists for the clinician who seeks it, rather than one that asserts itself into the workflow. If an AI tool presents itself as correcting the doctor, the first time it gets something wrong, the doctor stops using it altogether.

The bigger risk, as AI gets more accurate, is that doctors stop paying attention. If the AI is right nine times in a row, the tenth time a doctor may approve its suggestion without really looking, which is precisely when an error slips through. The answer is building processes that keep doctors actively engaged even when the tool is performing well.

The same dynamic plays out in digital pathology, arguably the most technically advanced corner of clinical AI today. The scanning technology is mature, AI models built on top of it are showing genuine results, and several companies have already scaled working solutions, making it the clearest proof of concept for what AI-assisted clinical diagnosis can look like. Yet even here, a human pathologist reviewing the output remains essential. Models trained on clean, controlled data still struggle with the variability of real clinical settings, and regulators require safety to be demonstrated at population scale before autonomous operation is permitted. The ceiling on AI autonomy, in other words, is not primarily a model accuracy problem. It is a trust and verification problem, and that is what every part of this space is grappling with.

What would you tell founders building AI for clinical settings, based on what you've seen at MOC?

The opportunity is real, but it is being built under the real constraints of the field: a healthcare workforce stretched far beyond conventional ratios, clinical environments that defy controlled-setting assumptions, and a patient population distributed nowhere near the specialist concentration.

The founders who will build something durable here are those who start with the infrastructure such as structured data, workflow integration, and EMR continuity before they build the AI on top of it. That is a harder problem than deploying a capable model, and the one worth solving.

This blog draws on a fireside conversation between Manish Jobanputra of MOC Cancer Care and Vishap Rana at the Elevation Capital Healthtech Roundtable, May 2026.