CDSCO Regulations for Software as a Medical Device (SaMD) in India

Software as a Medical Device (SaMD) refers to standalone software intended to perform one or more medical purposes (e.g., diagnosis, monitoring, prediction, prevention, or treatment of disease) without being part of or embedded in a hardware medical device. This includes mobile apps, AI/ML-based diagnostic tools, cloud-based imaging analysis software, and other digital health solutions running on general-purpose platforms like smartphones, PCs, or servers.

In India, SaMD is regulated under the Medical Devices Rules, 2017 (MDR 2017) as a “medical device” if it meets the definition in the Drugs and Cosmetics Act, 1940 (as amended). The Central Drugs Standard Control Organisation (CDSCO) oversees this, with key clarifications provided in the Draft Guidance Document on Medical Device Software released on October 21, 2025 (still in draft/stakeholder feedback stage as of early 2026, but widely referenced and applied in practice). The guidance aligns India’s framework with global standards (e.g., IMDRF definitions and risk categorization) without introducing entirely new rules—it’s primarily clarificatory for existing MDR provisions.

Key Distinctions in the Guidance

  • SaMD (Standalone Software): Independent; performs medical purpose on its own or interfaced with other devices/general software. Examples: AI radiology tools, symptom checkers, or predictive algorithms.
  • SiMD (Software in a Medical Device): Embedded/integral to hardware (e.g., pacemaker firmware or IVD analyzer software). Classified with the parent hardware—no separate class needed.
  • Excluded: Non-medical software (e.g., hospital billing apps, appointment schedulers, or general wellness tools without medical claims).

Administrative/non-clinical software falls outside MDR scope.

Risk-Based Classification for SaMD

SaMD follows the four-class risk system (A–D) under MDR 2017’s First Schedule, determined by:

  1. Intended medical purpose (e.g., diagnosis vs. monitoring).
  2. Significance of information provided to healthcare decisions (e.g., treat vs. inform).
  3. Severity of the healthcare situation or condition addressed (critical vs. non-critical).

Examples from the draft:

  • Class A (Low Risk): Informational tools (e.g., wellness trackers without treatment claims).
  • Class B: Moderate risk (e.g., monitoring apps for non-critical conditions).
  • Class C: High risk (e.g., diagnostic software for serious diseases).
  • Class D (Highest Risk): Critical situations (e.g., AI for life-threatening diagnoses like cancer or heart conditions).

Higher classes require more stringent controls, including Central Licensing Authority (CDSCO) approval for C/D.

Regulatory Pathways & Licensing

  • Low-Risk (Class A non-sterile/non-measuring): Registration via MD Online portal (no full license needed in many cases).
  • Class A/B: Often State Licensing Authority (SLA) for manufacturing/import license (MD-5/MD-15 pathway).
  • Class C/D: Central Licensing Authority (CDSCO) oversight.
  • Novel SaMD (no predicate device): Apply for prior permission via Form MD-26 → MD-27 (for innovative/first-of-kind software), then full license.
  • Submission: Via SUGAM portal (cdscomdonline.gov.in) for licenses/permissions; NSWS portal for test licenses.
  • QMS Requirements: ISO 13485:2016 compliance mandatory; risk management per ISO 14971.
  • Clinical/Performance Evaluation: Required for higher-risk or novel SaMD (global data often accepted with local bridging if needed).
  • Post-Market: Vigilance reporting, Periodic Safety Update Reports (PSURs), recalls (may include uninstall/decommissioning for software).

Key Standards & Documentation

  • IMDRF/IMDRF SaMD frameworks for classification.
  • IEC 62304 (software lifecycle), IEC 62366 (usability), IEC 81001-5-1 (health software safety).
  • Technical file: Intended use statement, risk analysis, validation reports, cybersecurity measures (increasingly emphasized for AI/ML).
  • For AI/ML-based SaMD: Algorithm change protocols, training data details, bias mitigation.

2026 Context & Status

The October 2025 draft guidance (76 pages) remains the primary reference for SaMD/SiMD regulation, with stakeholder feedback incorporated. No major finalization announced by early 2026, but it’s actively guiding applications. CDSCO emphasizes lifecycle approach, global harmonization, and predictability for innovators (e.g., AI diagnostics often Class C/D). Manufacturers should monitor cdsco.gov.in for updates, as the framework evolves with digital health growth.

This positions India closer to international norms (IMDRF, FDA, EMA) while tailoring to local needs—essential for medtech companies entering or expanding in India.

By Sam Michael

Follow us on X @realnewshubs and subscribe for push notifications.

Follow and subscribe us increase push notification.

FAQ Schema

Question: What is SaMD under CDSCO regulations? Answer: Standalone software performing medical purposes independently (e.g., diagnostic apps, AI tools) without hardware integration, regulated as a medical device under MDR 2017.

Question: How is SaMD classified in India? Answer: Risk-based (Class A–D) per intended use, information significance, and condition severity—higher classes (C/D) often for critical diagnostics.

Question: Is the 2025 draft guidance final? Answer: As of early 2026, it’s draft (issued Oct 2025 for comments), but widely used as clarificatory for MDR 2017; check CDSCO portal for final status.

Question: What QMS is required for SaMD? Answer: ISO 13485:2016 compliance, plus risk management (ISO 14971) and software lifecycle standards (e.g., IEC 62304).

Review Schema

Item Reviewed: CDSCO Regulations for Software as a Medical Device (SaMD) Reviewer: Sam Michael Review Rating: 4.5/5 Review Body: The 2025 draft guidance clarifies SaMD/SiMD under existing MDR 2017 rules—strong risk-based framework with global alignment, though still draft. Key for digital health innovators; monitor CDSCO for finalization and updates.

1 thought on “CDSCO Regulations for Software as a Medical Device (SaMD) in India”

  1. Pingback: FDA Regulations for Software as a Medical Device (SaMD) in the United States | VSD Regulatory Consultant Affairs

Leave a Reply