Indiens CDSCO-Softwareleitfaden 2026: MDR 2017

Indiens Central Drugs Standard Control Organization (CDSCO) hat am 21. Juli 2026 ihr aktuelles Guidance Document on Medical Device Software veröffentlicht. Das 62-seitige Dokument mit der Nummer CDSCO/MD/GD/MDSW/01/2026 führt den aktuellen Ansatz der CDSCO in Bezug auf Medizinproduktesoftware (MDSW), einschließlich Software für In-vitro-Diagnostika (IVD), in einer betrieblichen Referenz unter den Medical Devices Rules, 2017 (MDR 2017), zusammen.

Der Status ist von Bedeutung. Laut CDSCO spiegelt der Leitfaden die aktuellen Praktiken gemäß MDR 2017 wider und „sollte nicht als neue regulatorische Kontrolle missverstanden werden.“ Es handelt sich um eine Orientierungshilfe zur Information der Öffentlichkeit, nicht um eine neue Verordnung oder einen Ersatz für den Drugs and Cosmetics Act, die MDR 2017 oder spätere Klarstellungen der CDSCO. Die praktische Änderung ist daher kein neues Softwaregesetz, sondern eine wesentlich klarere Orientierungshilfe dafür, wie die CDSCO die Anwendung des bestehenden Regulierungsrahmens auf Software-Anträge, Lizenzierungen, Qualitätssysteme, Änderungen und Überwachungen nach dem Inverkehrbringen erwartet.

Lesen Sie die offizielle CDSCO-Mitteilungsseite für Medizinprodukte oder öffnen Sie das vollständige Leitfaden-PDF.

Welche Software fällt in den Anwendungsbereich

Der Leitfaden findet Anwendung, wenn Software eigenständig oder in Kombination mit einem anderen Produkt einen medizinischen Zweck erfüllt und die Definition eines Medizinprodukts nach indischem Recht erfüllt. Die CDSCO verwendet MDSW als Oberbegriff, der – sofern im Dokument nicht anders angegeben – auch Software für IVD-Medizinprodukte umfasst.

Die Zweckbestimmung ist die Trennlinie. Die CDSCO schließt Software aus, die ausschließlich für das allgemeine Wohlbefinden (Wellness), die Förderung eines gesunden Lebensstils, die routinemäßige Erfassung von Körperparametern oder Fitness verwendet wird, vorausgesetzt, dass sie nicht für einen medizinischen Zweck bestimmt ist. Eine Kennzeichnung als Wellness-Produkt hebt diagnostische, überwachende, prädiktive, therapeutische oder sonstige medizinische Auslobungen nicht auf. Hersteller sollten daher die Angabe der Zweckbestimmung über das Produkt, den Antrag, die Kennzeichnung, die Gebrauchsanweisung und Werbematerialien hinweg abstimmen, bevor sie sich auf den Ausschluss berufen.

Das Dokument ist für mehr als nur eigenständige Apps von Bedeutung. Seine Beispiele und Abschnitte zu Einreichungen behandeln Software, die unabhängig arbeitet, Software, die Hardware steuert oder beeinflusst, cloud- oder netzwerkbasierte Systeme, KI/ML-Funktionen und IVD-Software. Es richtet sich an Hersteller, Importeure, Innovatoren, Forscher und andere Antragsteller, die behördliche Genehmigungen anstreben.

Die Klassifizierung beginnt weiterhin mit der Zweckbestimmung

MDSW folgt den vier Risikoklassen, die bereits von der MDR 2017 verwendet werden:

Die CDSCO stellt fest, dass die Software-Klassifizierung grundlegend auf der Zweckbestimmung und den Klassifizierungsregeln im Ersten Anhang (First Schedule) der MDR 2017 basiert. Wenn mehr als eine Regel anwendbar ist, gilt die strengste Regel, die zur höheren Klasse führt. Der Leitfaden bietet praktische Beispiele, die jedoch eine produktspezifische Klassifizierungsbegründung nicht ersetzen.

Für ein Software-Portfolio ist die zweckmäßige Analyseeinheit daher nicht die Codebasis oder die kommerzielle Plattform. Es ist jeder regulierte medizinische Zweck und der Schaden, der aus den bereitgestellten Informationen oder der Steuerung durch die Funktion resultieren könnte. Zwei Module, die dieselbe technische Architektur nutzen, erfordern möglicherweise eine unterschiedliche regulatorische Behandlung, wenn sich ihre medizinischen Zwecke und Risiken unterscheiden.

Der Einreichungsweg und die Lizenzierungsbehörde

Der Leitfaden unterscheidet den Online-Weg nach der Art des Antrags:

• Testlizenzen: Einreichung über Indiens National Single Window System.
• Sonstige behördliche Genehmigungen, Herstellungs- oder Importlizenzen sowie Registrierung für Verkauf und Vertrieb: Einreichung über das Online System for Medical Devices.

Die Lizenzierungszuständigkeit ändert sich ebenfalls je nach Vorgang und Risikoklasse. Die Tabelle 5 der CDSCO weist Testlizenzen und Importlizenzen für alle Klassen der zentralen Lizenzierungsbehörde (Central Licensing Authority, CLA) zu. Herstellungslizenzen für MDSW der Klassen A und B liegen bei der staatlichen Lizenzierungsbehörde (State Licensing Authority, SLA), während Herstellungslizenzen der Klassen C und D bei der CLA liegen. Nicht-sterile Produkte der Klasse A ohne Messfunktion sind von der Lizenzierung befreit und erfordern eine Registrierung gemäß Kapitel IIIB der MDR 2017; diese Befreiung sollte nicht ohne Prüfung der anwendbaren Bedingungen auf andere Softwarekonfigurationen der Klasse A verallgemeinert werden.

Diese Aufteilung ist für Unternehmen mit sowohl indischer Herstellung als auch importierten Produkten betrieblich von großer Bedeutung. „CDSCO-Einreichung“ ist kein einzelner, undifferenzierter Weg: Das korrekte Portal, das Formular, die Behörde und das Dossier hängen davon ab, wofür der Antragsteller eine Genehmigung beantragt.

Was das Dossier nun an einem Ort zusammenfasst

Die Abschnitte 12.1–12.5 und Anhang A (Annexure A) strukturieren die erwarteten Nachweise über Testlizenzen, klinische Prüfungen oder IVD-Leistungsbewertungen, Genehmigungen für Prüfprodukte, kommerzielle Herstellungs-/Importlizenzen und Pflichten nach dem Inverkehrbringen hinweg. Die Anwendbarkeit hängt weiterhin vom Produkt und dem Antrag ab, aber der Leitfaden macht die wesentlichen Nachweisbereiche sichtbar:

• Zweckbestimmung, Indikationen, Zielanwender, Nutzungsumgebung, Eingaben, Ausgaben, Kontraindikationen und Einschränkungen;
• Produktbeschreibung, Softwarearchitektur, Versionierung, Schnittstellen, Abhängigkeiten und die Beziehung zwischen Software und etwaiger Hardware;
• Klassifizierungsbegründung und gegebenenfalls Vergleich mit einem Referenzprodukt (Predicate);
• Nachweise zum Software-Lebenszyklus, zu Anforderungen, Design, Verifizierung, Validierung, Konfiguration, Fehlern und Änderungsmanagement;
• Risikomanagement, das gegebenenfalls klinische, gebrauchstaugliche, datenbezogene, cybersicherheitsbezogene, interoperabilitätsbezogene und KI-bezogene Risiken abdeckt;
• klinische Evidenz oder Leistungsnachweise, die der Software und dem Zulassungsweg angemessen sind;
• Kennzeichnung, elektronische Informationen, Installation, Wartung, Updates und Informationen zur Versionsrückverfolgbarkeit;
• QMS-Nachweise für inländische oder ausländische Herstellungsstätten; und
• Überwachung nach dem Inverkehrbringen (Post-Market Surveillance), Vigilanz, Korrekturmaßnahmen, Rückrufe und softwarespezifische Sicherheitskorrekturmaßnahmen im Feld.

Anhang A wandelt diese Bereiche in Antrags-Checklisten um. Er stellt außerdem klar, dass der Antragsteller, wenn ein aufgeführtes Dokument nicht anwendbar ist, eine detaillierte Begründung vorlegen sollte, anstatt es stillschweigend wegzulassen.

QMS, Normen, Cybersicherheit und Softwareänderungen

Die CDSCO ordnet die Steuerung des Software-Lebenszyklus dem Qualitätsmanagementsystem zu. Inländische Hersteller müssen QMS-Verfahren und -Aufzeichnungen einrichten und aufrechterhalten und zusammen mit einem Antrag auf Herstellungslizenz die Verpflichtungserklärung zur Einhaltung des Fünften Anhangs (Fifth Schedule) der MDR 2017 einreichen. Bei Importen muss der ausländische Hersteller den Antrag auf Importlizenz mit den im Leitfaden beschriebenen QMS-Nachweisen unterstützen.

Der Abschnitt zu Normen wahrt die Hierarchie der MDR 2017: anwendbare BIS-Normen oder notifizierte indische Normen an erster Stelle, gefolgt von ISO-, IEC- oder anderen angegebenen internationalen Normen, wenn keine indische Norm verfügbar ist, sowie validierten Herstellernormen, wenn keine der genannten spezifiziert ist. Seine beispielhafte MDSW-Tabelle enthält unter anderem ISO 13485, ISO 14971, IEC 62304, IEC 82304-1 und IEC 81001-5-1. In der Tabelle heißt es, dass Normen „anwendbar sein können“; dies ist keine Erklärung, dass jede aufgeführte Norm auf jedes Produkt identisch anzuwenden ist.

Hinsichtlich der Sicherheit im Lebenszyklus stellt die CDSCO fest, dass Hersteller eine Stückliste (Bill of Materials), einschließlich einer Software-Stückliste (Software Bill of Materials, SBOM), führen und regelmäßig aktualisieren sollten, die gegebenenfalls Drittanbieter-, Open-Source- und kommerzielle Komponenten abdeckt. Der Leitfaden verknüpft die SBOM mit der Überwachung, Bewertung und Behebung bekannter Schwachstellen. Er fordert zudem eine dokumentierte Überwachung der Leistung nach der Bereitstellung (Post-Deployment Performance), einschließlich klinisch signifikanter Verschlechterung, Algorithmen-Drift, Cybersicherheitslücken und unbeabsichtigter Ergebnisse.

Die Formulierung zur Planung von KI-Änderungen erfordert Sorgfalt. Der Leitfaden führt aus, dass ein Algorithmen-Änderungsprotokoll (Algorithm Change Protocol, ACP) entwickelt werden kann, wo immer dies anwendbar ist, basierend auf der Art und den Risiken der MDSW. Ein ACP wird daher nicht als obligatorisches Dokument für jedes Softwareprodukt dargestellt. Wo es angewendet wird, sollte es Verfahren beschreiben, die sicherstellen sollen, dass Änderungen die Sicherheit oder die Zweckbestimmung nicht beeinträchtigen, einschließlich relevanter Daten-, Validierungs-, Risiko-, Überwachungs- und Rollback-Kontrollen.

Pflichten nach dem Inverkehrbringen hängen vom Risiko und vom Zulassungsweg ab

Die kommerzielle Zulassung beendet den Software-Lebenszyklus nicht. Der Leitfaden verknüpft Lizenzbedingungen, die Meldung unerwünschter Ereignisse, Sicherheitskorrekturmaßnahmen im Feld, Rückrufe, Updates und die Versionsrückverfolgbarkeit mit dem bestehenden Post-Market-Regulierungsrahmen der MDR 2017. Bei Software kann ein Rückruf die Einstellung des Vertriebs, die Deinstallation oder die Außerbetriebnahme des Produkts aus Vertriebskanälen, Netzwerken oder Hardware umfassen.

Die Aussage zum Regelmäßigen Sicherheitsaktualisierungsbericht (Periodic Safety Update Report, PSUR) ist enger gefasst als eine pauschale Regelung für alle MDSW. Die CDSCO weist ausdrücklich darauf hin, dass MDSW, die nach klinischen Prüfungen für das Inverkehrbringen genehmigt wurden – wie beispielsweise ein Produkt ohne Referenzprodukt (Predicate) –, genau überwacht werden sollten und dass der Hersteller oder Importeur PSURs gemäß den in der MDR 2017 festgelegten Bedingungen vorlegen muss. Teams sollten die genaue Pflicht nach dem Inverkehrbringen dem Zulassungsweg und den Lizenzbedingungen zuordnen, anstatt einen universellen Rhythmus von einem anderen Produkt zu übernehmen.

Was Hersteller und Importeure jetzt tun sollten

Nach Auffassung von Pure Global ist die sinnvollste Reaktion eine kontrollierte Lückenanalyse und keine vollständige Neugestaltung allein aufgrund des Begriffs „Guidance“.

1. Ersetzen Sie den Entwurf in der Regulatory-Intelligence-Akte. Erfassen Sie die Dokumentennummer vom 21. Juli 2026 und archivieren Sie den veröffentlichten Leitfaden als aktuelle Referenz.
2. Gleichen Sie Zweckbestimmung und Klassifizierung ab. Bestätigen Sie, dass Produktangaben, Modulgrenzen, Klassifizierungsregeln und die Analyse der am höchsten anwendbaren Regel übereinstimmen.
3. Bestätigen Sie den transaktionsspezifischen Pfad. Trennen Sie Test-, Herstellungs-, Import-, Prüf- und kommerzielle Registrierungsaktivitäten voneinander und ordnen Sie jede dem korrekten Portal, Formular und der zuständigen Zulassungsbehörde zu.
4. Gleichen Sie das Dossier mit den Abschnitten 12 und Annexure A ab. Identifizieren Sie fehlende Nachweise und dokumentieren Sie, warum ein Checklistenpunkt nicht anwendbar ist.
5. Überprüfen Sie das QMS anhand der Software-Realität. Bestätigen Sie, dass Aufzeichnungen zu Lebenszyklus, Risiko, Konfiguration, Verifizierung/Validierung, Schwachstellen, SBOM, Überwachung und Änderungen als kontrollierte Nachweise und nicht als technische Artefakte außerhalb des QMS existieren.
6. Definieren Sie die Änderungsgrenze vor dem nächsten Release. Bestimmen Sie, welche Änderungen eine Validierung, Dokumentation und regulatorische Bewertung erfordern und ob ein ACP für die jeweilige KI/ML-Funktion nützlich ist.
7. Stimmen Sie Post-Market-Daten mit den Versionen ab. Reklamationen, unerwünschte Ereignisse, Leistungsabweichungen, Schwachstellen, Korrekturen und Rückrufe müssen bis zu der tatsächlich eingesetzten Softwareversion rückverfolgbar bleiben.

Für den umfassenderen indischen Registrierungspfad siehe den Leitfaden zum Marktzugang für Medizinprodukte in Indien von Pure Global. Für eine marktübergreifende Ansicht darüber, wie KI-gestützte Software klassifiziert und instand gehalten wird, siehe KI als Medizinprodukt: Die globale Karte von Regulierung, Registrierung und Marktzugang.

Die zentrale Erkenntnis ist präzise: Die CDSCO hat kein separates neues Software-Regime angekündigt. Sie hat die bislang klarste konsolidierte Darstellung darüber vorgelegt, wie sich Software als Medizinprodukt in das bestehende indische MDR-2017-System einfügt. Der Wert für die Compliance ergibt sich daraus, diese Übersicht zu nutzen, um Unstimmigkeiten aufzudecken, bevor sie in einem Lizenzantrag, einem Software-Release oder einem Post-Market-Ereignis zu Tage treten.