NEWOncologists studied OneRx across seven measures, a first for India. Now peer reviewed and published.·Read what they found →

Medical AI Regulation in India: CDSCO, NMC and DPDP in 2026

Medical AI Regulation in India: CDSCO, NMC and DPDP in 2026
Evidence Brief · OneRX

Medical AI Regulation in India: CDSCO, NMC and DPDP in 2026

The most common thing said about clinical AI regulation in India is that there is not any. No AI Act, no dedicated statute, therefore an open field.

That is wrong in a way that creates real exposure, because the absence of a single named law does not mean the absence of regulation. Four existing regimes already apply, and they apply simultaneously. CDSCO governs the software as a product under the Medical Devices Rules, 2017. The NMC and the Telemedicine Practice Guidelines govern how you practise with it. The Digital Personal Data Protection Act governs the data flowing through it. And ABDM governs whether it can participate in the health record ecosystem at all.

None of these was written specifically for large language models. All of them bind anyway.

What follows is an orientation as of July 2026, written for clinicians and hospital leaders rather than lawyers. Regulatory positions in this space are moving quickly, and anything load-bearing should be confirmed against the current official texts rather than against this article.

CDSCO: is your software a medical device?

In October 2025, CDSCO published a draft Guidance Document on Medical Device Software — the first comprehensive statement of how the Medical Devices Rules, 2017 apply to software rather than to hardware. Final guidance followed in 2026 after stakeholder consultation.

The document draws a distinction that determines everything else.

Software in a Medical Device, or SiMD, is embedded in and inseparable from physical hardware. Pacemaker firmware. The software running an IVD analyser. It inherits the risk classification of the parent device and is regulated as part of it.

Software as a Medical Device, or SaMD, performs a medical function independently of any hardware. Diagnostic applications. AI imaging tools. Remote monitoring platforms. And, explicitly, clinical decision support systems.

Classification runs Class A through D on a risk basis, determined by three things: the medical purpose the software serves, how significant its output is to clinical decision-making, and the severity of the condition it addresses. Class C and D require Central Licensing Authority approval with a full technical dossier, risk assessment, quality management system evidence and clinical data.

Two features of this framework matter more than the classification table itself.

Intended use drives classification, not architecture

This surprises people. The wording in your labelling, promotional material and instructions for use can move a product from Class B to Class C if it implies a diagnostic or life-supporting function. Two platforms running an identical underlying model can sit in different classes because one markets itself as making diagnoses and the other as surfacing evidence for a clinician to interpret.

Marketing copy is a regulatory artefact here, which is not how most software companies think about it.

AI systems need documented change controls

AI and machine learning systems need an Algorithm Change Protocol. Models that update after deployment must document how they change and under what controls — a requirement that does not arise for static software and that many AI vendors have not planned for.

Network-connected software is expected to produce vulnerability assessment and penetration testing evidence. Post-market surveillance and ongoing safety monitoring are not optional extras.

Purely administrative software — billing, scheduling, inventory — falls outside scope entirely. Separately, the Drugs and Cosmetics Act remains the primary legislation for medical devices, with the Drugs, Medical Devices and Cosmetics Bill still pending parliamentary passage as of July 2026.

NMC: how you practise with it

The National Medical Commission replaced the Medical Council of India in 2020 under the NMC Act, 2019. The Telemedicine Practice Guidelines, issued in March 2020 by the Board of Governors in supersession of the MCI, remain the governing framework for remote practice and continue to apply in 2026.

Three points carry most of the weight.

Registration

Only practitioners registered with the NMC or a State Medical Council may practise telemedicine. There is no separate telehealth licence — your existing registration covers it, provided the procedural rules are followed.

The same standard of care applies

The same standard of care applies as in person. Negligence liability is entirely unchanged by the presence of a software tool in the workflow.

Prescribing and record obligations remain

Professional conduct updates have tightened telemedicine prescribing, including restrictions on Schedule X drugs, which is directly relevant in oncology and pain management. E-prescription formatting requirements and digital record retention obligations apply alongside.

The load-bearing principle underneath all of this: no AI tool transfers clinical liability. A recommendation surfaced by software and acted upon by a registered practitioner is that practitioner's decision, full stop. There is no current Indian framework that shifts responsibility to a software vendor for a clinical decision made by a treating clinician.

Which is also why traceability stops being an abstract virtue. If a decision is questioned eighteen months later and you cannot reconstruct which source produced the recommendation you acted on, or what guideline version it reflected, you cannot defend the decision on the record.

"The system suggested it" is not a defence. "The system retrieved NCCN version 3.2026, section X, on this date, and I applied clinical judgement to it" is a different conversation entirely.

DPDP: the data

The Digital Personal Data Protection Act, 2023 is the governing data statute. MeitY notified the DPDP Rules in November 2025 with staggered commencement — some provisions immediate, Consent Manager obligations by November 2026, and core obligations covering notices, data principal rights, processing, security safeguards, children's data and cross-border transfers by May 2027 on an eighteen-month runway.

Enforcement sits with the Data Protection Board of India. The penalty schedule runs to substantial figures, including up to ₹250 crore for failure to implement reasonable security safeguards where that failure results in a breach.

Separately, CERT-In directions require cyber security incident reporting within six hours, with log retention and time synchronisation obligations attached.

For an individual clinician the practical consequence is narrower than the statute but sharper than most people assume. Entering identifiable patient data into a consumer AI tool is a data-processing act. Consumer platform terms of service were not drafted with health data in mind, and the fact that a tool is free does not make the processing incidental.

Three questions worth asking of any platform before clinical use

  1. What happens to my queries after I close the window?
  2. Are patient identifiers required at all for the tool to function?
  3. Will the vendor contract as a data fiduciary?

ABDM: interoperability

The Ayushman Bharat Digital Mission provides the health data exchange architecture — ABHA identities, consent-based record sharing through the Health Information Exchange and Consent Manager, FHIR-based interoperability, and the Unified Health Interface.

Over 840 million ABHA identities have been created, and integration is increasingly expected of providers linked to government schemes, including AB-PMJAY empanelled hospitals.

For clinical AI this determines whether a tool can participate in the record ecosystem at all rather than sitting alongside it as a separate lookup. FHIR adoption remains uneven across hospital tiers, so the practical answer varies considerably by institution.

Where OneRX differs

Each of the four regimes above implies a design requirement rather than a compliance checkbox. OneRX is a medical AI platform for clinical decision support, and the mapping is direct.

Regulatory requirement What it demands OneRX design
CDSCO — intended use drives classification Claims must match function Positioned and described as decision support, not diagnosis; clinical judgement retained by the clinician
CDSCO — traceability expectation Decision process reconstructable Every recommendation resolves to a retrievable source document with guideline version named
CDSCO — Algorithm Change Protocol Documented control over post-deployment change Corpus index dates surfaced; version state visible on the answer
NMC — liability stays with the practitioner Clinician must be able to defend the decision Retrieval trail available retrospectively rather than a bare recommendation
DPDP — processing obligations Minimise identifiers, contract appropriately Built for clinical questions rather than patient records

The point of the table is not that regulation is a marketing opportunity. It is that traceability, version pinning and a retrieval trail happen to be the same features that make a tool clinically useful and the same features that make it defensible.

A system built on parametric recall cannot produce any of them, whatever its compliance documentation says.

That is also why 1,400+ doctors across 8+ countries use OneRX at the point of care rather than a general-purpose chatbot: the answer arrives with its provenance attached.

Six questions before procurement

For anyone bringing clinical AI into a hospital workflow.

  1. What is its CDSCO classification, and does the marketing language match that class?
  2. Does it claim to make decisions or to support them? The wording carries regulatory weight, not just reputational weight.
  3. Can any recommendation be traced to a source document retrospectively, months later?
  4. Is there an Algorithm Change Protocol, and will you be notified when the model changes underneath you?
  5. What happens to queries, and will the vendor contract as a data fiduciary under DPDP?
  6. Is it ABDM-compatible, and does that matter for your patient population and empanelment status?

Questions clinicians actually ask

Is AI-based clinical decision support regulated in India?

Yes. CDSCO treats standalone clinical decision support as Software as a Medical Device under the Medical Devices Rules, 2017, classified A to D by intended use and risk, with additional documentation expected for AI and machine learning systems that change after deployment.

Do I need CDSCO approval to use an AI tool in my clinic?

The regulatory obligation sits with the manufacturer or importer rather than the prescribing clinician. But you should know the classification of what you deploy, and your own NMC obligations on standard of care and record-keeping apply regardless of what the vendor has or has not done.

Who is liable if an AI tool contributes to an error?

The registered medical practitioner remains responsible for the clinical decision. No current Indian framework transfers liability to a software vendor for a decision made by a treating clinician.

Can I enter patient details into a general AI chatbot?

Treat it as data processing under the DPDP Act, governed by consumer terms that were not designed for health data. De-identify, or use a tool whose vendor will contract appropriately.

When do DPDP obligations actually bite?

Staggered from the November 2025 notification, with Consent Manager provisions by November 2026 and core obligations by May 2027. Confirm current commencement status against MeitY notifications rather than secondary commentary.

References

  1. Central Drugs Standard Control Organisation. Guidance Document on Medical Device Software under MDR-2017. 21 July 2026. Official CDSCO publication
  2. Medical Devices Rules, 2017. Government of India. Official CDSCO PDF
  3. Board of Governors in supersession of the Medical Council of India. Telemedicine Practice Guidelines. 25 March 2020. Official MoHFW PDF
  4. National Medical Commission Act, 2019. India Code
  5. Digital Personal Data Protection Act, 2023. India Code
  6. Digital Personal Data Protection Rules, 2025. Ministry of Electronics and Information Technology. Notified 14 November 2025. Official MeitY publication
  7. Indian Computer Emergency Response Team (CERT-In). Directions under sub-section (6) of Section 70B of the Information Technology Act, 2000 relating to information security practices, procedure, prevention, response and reporting of cyber incidents. 28 April 2022. Official CERT-In directions
  8. Ayushman Bharat Digital Mission. Health information exchange, consent management and ABHA architecture. Accessed July 2026. Official ABDM information