The Excitement vs The Reality
Every few weeks, a HealthTech startup approaches us wanting to add "AI" to their product. They've seen the demos, they've read the case studies, and they want to ship AI-powered diagnosis or treatment recommendations. Our first question is always the same: "Have you talked to a regulatory consultant?" The answer is almost always no.
Here's the thing — in healthcare, your AI feature might legally be classified as a medical device. And if it is, you're looking at months (sometimes years) of regulatory approval before you can go live. We've learned this through painful experience on three HealthTech projects, and we want to save you the same pain.
When AI Becomes a "Medical Device"
In India, the Central Drugs Standard Control Organisation (CDSCO) is starting to regulate Software as a Medical Device (SaMD). If your AI system makes diagnostic decisions, recommends treatments, or predicts clinical outcomes, it likely falls under SaMD classification. The regulatory framework is still evolving (India is roughly 3-4 years behind the FDA on this), but that doesn't mean you can ignore it. We've seen companies get very uncomfortable letters from regulators.
The FDA's framework is clearer: they classify AI/ML-based SaMD into Class I, II, or III based on risk. A wellness app that tracks steps? Not a medical device. An AI that reads chest X-rays and flags potential pneumonia? Class II medical device, requires 510(k) clearance. An AI that recommends chemotherapy dosages? Class III, requires pre-market approval. If your HealthTech client serves US patients (many Indian HealthTech companies do), you need to think about this from day one.
Data Privacy Is More Complex Than You Think
India's Digital Personal Data Protection Act (DPDP) 2023 has specific provisions for health data, which is classified as sensitive personal data. You need explicit consent for processing, purpose limitation (you can't use data collected for diagnosis to train a marketing model), and data localization (health data of Indian citizens must be stored in India). We've had to re-architect systems to add consent management workflows that we didn't budget for initially.
For clients serving multiple markets, the compliance matrix gets ugly fast. HIPAA for US, GDPR for EU, DPDP for India, PDPA for Singapore. Each has different requirements for consent, storage, access, and breach notification. We now maintain compliance templates for each market and include regulatory scoping in our project estimates from the start.
The Practical Workarounds
Not all AI in healthcare needs to be a medical device. The key distinction is whether the AI makes decisions or supports decisions. A system that says "this X-ray shows pneumonia" is making a decision — that's SaMD. A system that says "here are similar cases for your review" is supporting a decision — that's generally not SaMD. We've learned to architect systems as "clinical decision support" rather than "diagnostic AI." The doctor always makes the final call, and the UI makes this crystal clear.
Another approach: wellness vs clinical framing. If your AI monitors general wellness indicators (sleep patterns, activity levels, mood) without making clinical claims, the regulatory burden is much lighter. We helped a mental health startup reframe their product from "AI depression diagnosis" to "AI-powered wellness monitoring with clinical escalation pathways." Same underlying technology, very different regulatory category.
Our Advice for HealthTech Builders
Budget 20-30% of your project timeline for regulatory compliance work. Hire a regulatory consultant before you write a line of code. Design for "decision support" not "decision making" unless you're prepared for the regulatory process. And most importantly, build audit trails into everything — every AI inference, every data access, every user action should be logged. When (not if) a regulator asks "how did the system arrive at this recommendation?", you need to have the answer.