SaMD and MDSW in India: Classification and Dossier

1. Key takeaways

In India, standalone medical software (SaMD and MDSW) is classified into Class A to D by intended use, using the parameters in Part I of the First Schedule, exactly as with other devices, and the classification decision remains with the Central Licensing Authority. Devices that include software must provide software verification data (IEC 62304) in the DMF. The fee structure itself has no separate line item for “software”: the site fee and per-device fee of the Second Schedule apply according to the device class.

• Software is classified like any other device, by intended use and risk parameters, not by the fact that it is intangible.
• There is no software-specific fee line, so the cost is driven entirely by the assigned class.
• The intended use wording in the IFU is the most powerful determinant of both class and fee.
• Clinical decision support raises risk; data management without clinical decisions may sit in Class A.
• Software changes follow the Sixth Schedule change rules, with prior approval and notification timelines.

2. Legal basis

Classification, software documentation, fees, and change control each rest on separate provisions. The table below sets out each matter and its source, including one item recorded as a third-level source pending verification.

3. Expert insights

Insight one: India has not created a separate fee for software, but it has not lowered the requirements for software either. The practical meaning is that a software product cannot expect to be cheaper “because it is software”. It pays according to the class into which it is placed, and the DMF requirements are not reduced because the product is intangible. Teams that budget software as a low-cost registration should test that assumption against the classification outcome before committing.

Insight two: the class depends on what the software decides. Software used to assist diagnosis or to drive treatment decisions usually carries a higher risk level; software used for data management that does not participate in clinical decisions may fall into Class A. The decisive factor is how the intended use is written in the IFU. Two products built on the same algorithm can land in different classes depending on how their function is described. This is not a drafting trick: the description must match what the product actually does, because the clinical evidence and the post-market obligations follow the claim.

Insight three: the IFU wording determines the class, and the class determines the fee. For one and the same algorithm, an IFU that says it “assists the physician in interpretation” and an IFU that says it “provides a diagnostic conclusion” may fall into different classes. Software classification is decided by documentation, and this is the particular character of software projects. The wording should therefore be settled deliberately, in English, before any dossier text is drafted around it.

Insight four: software changes in India are subject to the Sixth Schedule rules as well. Under Rule 38(1)(v), a major change requires prior approval (60 days, deemed approved if the period lapses), and a minor change must be notified within 30 days. For software that iterates frequently, this rule applies far more often than it does to hardware. A release plan that ignores the distinction will either over-notify trivial updates or under-notify substantive ones. Classifying each planned change in advance is therefore part of release management, not a regulatory afterthought.

4. Practical recommendations

When handling software projects, GRZAN locks down the English wording of the IFU first and discusses classification second. Together with the client, we write a statement of no more than 100 words describing where the software sits in the clinical pathway, and use it as the common basis for both the classification request and the intended use section of the DMF. For products under continuous iteration, we also agree with the client in advance on the rules for determining version changes — which updates are major changes requiring prior approval, and which are minor changes subject to 30-day notification — so that every release does not have to go through the approval process.

• Fix the English IFU wording before requesting a classification decision.
• Write a short positioning statement for the clinical pathway and reuse it across all documents.
• Confirm which First Schedule parameters drive the class for this specific function.
• Budget fees by the assigned class rather than by the assumption that software is cheaper.
• Agree major and minor change criteria with the client before the first release.
• Document the software description in the DMF in the same words used in the IFU claim.

5. Verification checklist

• □ The English intended use wording in the IFU has been locked down
• □ Classification has been completed against the First Schedule parameters, or a classification request has been filed with the CLA
• □ The DMF contains software verification data (practical estimate: IEC 62304, pending verification)
• □ Fees have been calculated according to the assigned device class
• □ Criteria for major and minor version changes have been established

Regulatory information verified as of 27 October 2026.

How GRZAN can help. GRZAN provides medical device and IVD registration, quality system, authorised representative and local testing support across South Asia, including India. Our team prepares dossiers to CDSCO expectations, manages SUGAM submissions and deficiency responses, and supports post-market vigilance obligations. Business enquiries: info@grzanglobal.com