Is Your AI Software a Medical Device? A CDSCO Guide for Hospitals (2026)

Disclosure: Surgy Health builds AI software for hospitals. This guide explains the rules as they apply to any vendor, including us. It is a practitioner's summary, not legal or regulatory advice.

What changed in 2026

CDSCO released a draft guidance on medical device software in October 2025 and issued the final Guidance Document on Medical Device Software on 21 July 2026. The 62-page document covers standalone software, software embedded in or driving hardware, mobile and cloud software, and AI- and machine-learning-based software.

CDSCO states that the guidance "reflects current practices under the MDR-2017 and should not be misconstrued as a new regulatory control" (section 2.0). For hospitals, the practical change is clarity: there is now a published test for when the software you buy is a regulated device, and a published list of what its maker must disclose.

What counts as medical device software?

Software is medical device software (MDSW) when its maker intends it for a medical purpose — diagnosis, prevention, monitoring, treatment or alleviation of disease, or supporting clinical decisions. The guidance covers two kinds:

• Software as a medical device (SaMD): standalone software that performs the medical function itself, such as computer-aided detection on X-rays or ECG analysis, or AI that triages scans or screens for cancer.
• Software in or driving a medical device (SiMD): software that controls hardware, such as an insulin pump's control software, or an app that controls a device over Bluetooth or Wi-Fi.

The same algorithm can be in or out of scope depending on what the vendor claims it is for. A model that summarises a consultation for the record is documentation. The same model, marketed to suggest diagnoses, is informing clinical management.

What is out of scope

Section 5.2 of the guidance lists software that is not medical device software:

• Hospital or clinical information systems (HIS/CIS) used only for admission, scheduling, billing, communication or storing patient information
• Laboratory information systems and image-management systems that only manage, store or share data
• ERP and quality-management software
• General communication tools such as email and video calling
• General wellness software that makes no reference to diseases or conditions

The caveat that matters for hospitals: an HIS, LIS or image-management system with added medical functions — for example, image analysis as a diagnostic aid or real-time patient monitoring — may be a medical device. Check each module, not just the product name.

Out of scope does not mean unregulated. Admin AI that processes patient data is covered by India's Digital Personal Data Protection Act and Rules, and NABH's information management standards still apply.

How CDSCO classifies medical device software

Software that drives or influences a hardware device takes the same risk class as that hardware (section 7.1). Standalone software is classified with the matrix below (Table 2 of the guidance). Where more than one rule applies, the stricter class applies. If standalone software is meant for non-clinical users in a serious situation without specialist support, it may be treated as critical.

The Central Licensing Authority confirms the class. CDSCO publishes a classification list on its MD Online portal; if a product type isn't listed, the applicant can ask CDSCO to classify it.

Hospital AI examples on the matrix

These examples are illustrative. The actual class depends on the vendor's intended-use statement and CDSCO's decision.

Where common hospital AI tools usually land

Who licenses what

Table 5 of the guidance sets the licensing authority by activity and class:

The guidance notes that Class A devices that are non-sterile and non-measuring are exempt from the licensing requirements; their makers should still check registration obligations on the MD Online portal. Commercial applications go through CDSCO's MD Online system; test licences for manufacture (Form MD-12/MD-13) and import (Form MD-16/MD-17) go through the National Single Window System.

What CDSCO expects from AI-based medical devices

For AI and machine-learning software, the guidance asks makers to:

• Disclose the data. Describe the composition of training, validation and test datasets, and state whether data is real-world, from public databases or literature, or synthetic (section 12.4.2).
• Prove it works in India. Show performance and robustness across sub-populations relevant to India; models trained or validated outside India need justification and may need Indian validation.
• Control change. Describe whether the model updates itself or is updated under the maker's control, and where applicable submit an Algorithm Change Protocol covering data management, retraining, re-validation and rollback.
• Watch for drift. Keep documented procedures to monitor performance after deployment, including algorithm drift and degradation (section 9.0).
• Secure it. Encryption in transit and at rest, access control, audit trails, threat modelling at design stage and safe behaviour during incidents; standards referenced include IEC 81001-5-1 and ISO/IEC 27001.
• State the cloud. For software delivered as a service, state whether the cloud host is MeitY-empanelled (section 12.1).
• Keep evidence current. Clinical evidence can include literature, guidelines, clinical investigations and real-world data; post-approval changes must be notified.

Hospital buyer checklist

Before you buy any AI tool that touches clinical care, ask the vendor for:

1. The intended-use statement, in writing, exactly as filed or planned.
2. The CDSCO class and how it was decided (Table 2 cell, or hardware it drives).
3. Registration or licence number, or a dated plan if the product isn't yet registered.
4. Dataset summary: where training and test data came from and how Indian patients were represented.
5. Indian validation results, ideally from a hospital like yours.
6. Update policy: how model changes are made, tested and notified to you; the Algorithm Change Protocol if one exists.
7. Drift-monitoring reports you will receive after go-live, and how often.
8. Hosting: cloud provider, region and MeitY empanelment status.
9. Field safety process: how you'll be told about a safety issue and what you must do.
10. Your contract terms: who carries liability for errors, and audit rights.

Then run the tool in shadow mode on your own anonymised data. A CDSCO registration tells you the device is lawfully on the market; it doesn't tell you how accurate it will be in your wards.

Add these questions to your healthcare AI RFP, and record each approved tool in your AI governance policy register.

Selling or buying in the Gulf too?

Saudi Arabia (SFDA) and the UAE (MOHAP, plus Abu Dhabi DoH and Dubai DHA policies) regulate clinical AI separately. See AI in healthcare in the UAE and Saudi Arabia: rules for hospitals.

Related reading

• Hospital AI buyer's guide
• DPDP Act for hospitals
• Hospital AI governance policy template
• Healthcare AI RFP template and scorecard
• AI medical scribe software for hospitals

Sources

• CDSCO, Guidance Document on Medical Device Software, Doc No. CDSCO/MD/GD/MDSW/01/2026 (issued 21 July 2026)
• Nishith Desai Associates, From code to compliance: decoding India's medical device software guidance (3 August 2026)
• Emergo by UL, India CDSCO finalizes guidance on medical device software (30 July 2026)
• Pure Global, India CDSCO medical device software guidance 2026 (9 August 2026)
• Ministry of Electronics and IT, Digital Personal Data Protection Rules, 2025

This guide summarises published guidance for hospital buyers. It is not legal or regulatory advice; confirm classification and licensing questions with CDSCO or qualified regulatory counsel.