Indonesien KMK 951/2026: Marktzulassung von Software-Medizinprodukten

Der indonesische Gesundheitsminister hat den Erlass Nr. HK.01.07/MENKES/951/2026 über den Leitfaden für die Marktzulassung softwarebasierter Medizinprodukte (Kepmenkes/KMK 951/2026) erlassen. Der Erlass wurde am 7. September 2026 unterzeichnet und trat am selben Tag in Kraft. Er übernimmt den Leitfaden in seinem Anhang als Referenz (acuan) für Behörden, Medizinprodukteunternehmen und andere Interessengruppen, die mit der Marktzulassung (izin edar) softwarebasierter Produkte befasst sind. Der Leitfaden beschreibt sich selbst als eine technische Erläuterung der Anforderungen und Verfahren für die Marktzulassung. Wo in diesem Artikel „muss“ steht, verwendet der Leitfaden selbst verbindliche Formulierungen (wajib oder harus) oder führt den Punkt unter den Pflichten des Inhabers (kewajiban) auf. Der Erlass enthält keine Übergangsbestimmung für Produkte, die bereits registriert sind oder deren Anträge sich in der Prüfung befinden.

Anwendungsbereich

Der Leitfaden umfasst drei Produktgruppen:

• Software as a Medical Device (SaMD): Eigenständige Software mit medizinischer Zweckbestimmung, die nicht Teil eines Hardware-Medizinprodukts ist. Dies schließt Software für In-vitro-Diagnostika (IVD) sowie Software ein, die auf Standard-Plattformen wie Computern, Tablets und Smartphones läuft. Software, die ein anderes Medizinprodukt lediglich antreibt oder steuert, ist keine SaMD. Die Beispiele des Leitfadens sind eine App zur Blutzuckerüberwachung, ein Algorithmus, der das Herzinfarktrisiko anhand digitaler EKG-Daten vorhersagt, Röntgenbetrachtungssoftware auf einer Standard-Workstation und eine App zur Vitaldaten-Fernüberwachung.
• Software in a Medical Device (SiMD): In ein Medizinprodukt eingebettete Software, die dessen Betrieb unterstützt. Zu ihren Funktionen gehören unter anderem das Betreiben oder Steuern des Produkts, das Ändern seines Zustands oder das Erzeugen von Ausgaben im Zusammenhang mit seiner Hardwarefunktion. Gemäß dem Klassifizierungs-Ablaufdiagramm des Leitfadens wird SiMD als Zubehör des Hauptprodukts registriert, und ihre Anforderungen und ihre Risikoklasse folgen diesem Produkt. Die Beispiele des Leitfadens sind die Signalverarbeitung in MRT- oder CT-Scannern, die Beatmungsgeräteautomatisierung, Ultraschall-Bildgebungssoftware sowie Stimulations- oder Defibrillationssoftware in Herzschrittmachern und ICDs.
• Medizinprodukte mit Anwendungen künstlicher Intelligenz: KI, einschließlich maschinellem Lernen, natürlicher Sprachverarbeitung und großen Sprachmodellen (LLMs), ist nur dann ein Medizinprodukt, wenn sie eine medizinische Zweckbestimmung hat. Ausgaben generativer KI wie Bilder, Text, Audio oder Video fallen in den Anwendungsbereich, wenn sie für Diagnose, Überwachung, Therapieentscheidungen oder die Patientenversorgung bestimmt sind. KI, die ausschließlich für das administrative Datenmanagement, die Speicherung oder sonstige betriebliche Funktionen verwendet wird, welche die Funktion eines Produkts nicht beeinflussen, ist ausgeschlossen.

Dasselbe Ablaufdiagramm stuft Software dann nicht als Medizinprodukt ein, wenn sie Daten lediglich speichert, archiviert, übermittelt, einfache Suchen durchführt oder eine verlustfreie Kompression anwendet, oder wenn sie nicht auf patientenindividuelle Daten einwirkt. Software, die auf patientenindividuelle Daten einwirkt, ist nach dem Ablaufdiagramm ebenfalls kein Medizinprodukt, wenn sie keine der aufgeführten Funktionen ausführt: Erfassen, Verarbeiten oder Analysieren von Signalen, IVD-, MRT-, NGS-, CGM- oder computergestützten Detektions-/Diagnosedaten; Anzeigen, Analysieren oder Drucken von kontinuierlichen Signalen, medizinischen Bildern oder EKG-Wellenformen; oder Ausgeben von Krankheitsrisiko-Scores, Wahrscheinlichkeiten oder zeitkritischen Ausgaben.

Herstellung, Vertrieb und Qualitätssystem

Die Produktion wird von einem Medizinproduktehersteller durchgeführt, der über eine indonesische Gewerbelizenz unter dem relevanten KBLI-Code verfügen und die Gute Herstellungspraxis für Medizinprodukte (CPB) einhalten muss. Der Vertrieb wird von einem Medizinprodukte-Händler oder dessen Niederlassung durchgeführt, der über eine Gewerbelizenz verfügen und die Gute Vertriebspraxis (CDB) einhalten muss. Sowohl Hersteller als auch Händler müssen ein Qualitätsmanagementsystem anwenden. Der Leitfaden beschreibt ein wirksames Qualitätsmanagementsystem dahingehend, dass es die Kontrolle ausgelagerter Prozesse umfasst, einschließlich kommerzieller Standardsoftware (Commercial Off-the-Shelf, COTS), wobei der Produkteigentümer für Sicherheit und Leistung verantwortlich bleibt.

Für die Implementierung des Qualitätsmanagementsystems führt der Leitfaden Normen auf, die als Referenzen herangezogen werden können, ohne Angabe von Ausgaben. Dazu gehören ISO 13485, ISO 14971, IEC 60601-1 und IEC 61010-1 (die der Erlass als ISO-Normen bezeichnet), IEC 62366-1, IEC 62304, IEC 82304, IEC 63450, IEC 63521 und ISO 27001.

Registrierungsunterlagen

Softwareverifizierung und -validierung. Diese Unterlagen müssen dem Software-Entwicklungslebenszyklus nach IEC 62304 oder einer gleichwertigen anerkannten Norm folgen. Sie müssen mindestens Softwareversion, Rückverfolgbarkeit, Änderungskontrolle, Interoperabilität und Cybersicherheit abdecken. Weicht die geprüfte Version von der eingereichten Version ab, muss der Antragsteller einen Versionsvergleich mit Begründung vorlegen. Eine zusätzliche Validierung ist erforderlich, wenn wesentliche Änderungen vorliegen, die sich auf die Sicherheit, die Leistung oder die Zweckbestimmung auswirken könnten. Die vermarktete Softwareversion muss auf der Kennzeichnung des Produkts und/oder der Software-Benutzeroberfläche angegeben sein.

Vernetzte Software. Software, die mit anderen Produkten, externen Systemen, Netzwerken oder dem Internet verbunden ist, erfordert zusätzliche Angaben im Dossier. Sie muss Datenaustauschmechanismen beschreiben, die Vertraulichkeit, Integrität und Verfügbarkeit schützen, zusammen mit der Schwachstellenidentifikation, Risikoanalyse, Risikominderung und dem Nachweis, dass die Kontrollmaßnahmen wirksam sind.

Risikomanagement. Das Risikomanagement muss sich unter Bezugnahme auf Normen wie ISO 14971 über den gesamten Softwarelebenszyklus erstrecken. Jede Softwareänderung muss auf zusätzliche Risiken hin bewertet werden.

Produkte mit KI und maschinellem Lernen. Design, Entwicklung, Validierung, Bereitstellung sowie jedes Training oder Nachtraining von KI-Modellen müssen innerhalb des Qualitätsmanagementsystems erfolgen. Tabelle 3.1 des Leitfadens legt dar, was ein KI/ML-Dossier enthalten muss:

Produkte, die kontinuierliches maschinelles Lernen nutzen, müssen zudem dokumentieren, wie Modelländerungen kontrolliert werden, sodass sie Sicherheit, Leistung oder Zweckbestimmung nicht beeinträchtigen. Diese Dokumentation umfasst die Aktualisierungshäufigkeit, Anomalieerkennung und -minderung, den Umgang mit Real-World-Daten, die Datensatzintegrität, Versionskontrolle mit Rollback auf einen früheren Algorithmus, Rückverfolgbarkeit zwischen Daten, Training und Ausgaben sowie eine fortlaufende Validierungsstrategie. Produkte, die generative Modelle oder LLMs verwenden, müssen zudem Ausgabekontrollen, die Minderung von Halluzinationen, Anwendungsgrenzen und die Art und Weise beschreiben, wie die Konsistenz und Genauigkeit der von ihnen generierten medizinischen Informationen während der kontinuierlichen Anpassung bewertet werden.

Klinische Evidenz

Klinische Evidenz kann aus einem der folgenden Elemente bestehen:

• einer Literaturübersicht und relevanten klinischen Praxisleitlinien;
• einem Vergleich mit ähnlicher, bereits auf dem Markt befindlicher Software, sofern vorhanden;
• Ergebnissen klinischer Prüfungen, insbesondere zur Untermauerung neuer Auslobungen oder wesentlicher Änderungen der klinischen Funktion.

Klinische Prüfungen vor dem Inverkehrbringen hängen vom Risiko des Produkts und davon ab, wie maßgeblich seine Informationen für klinische Entscheidungen sind. Der Leitfaden stuft klinische Evidenz als gut etabliert oder neuartig ein, und diese Einstufung dient als Grundlage für die Entscheidung, ob zusätzliche Evidenz erforderlich ist. Die Evidenz sollte verhältnismäßig und ohne ungebührliche Belastung gewählt werden. Bei Software mit hohem Risiko kann für die klinische Bewertung eine unabhängige Prüfung erforderlich sein. Eine analytische Validierung und eine klinische Validierung sind für alle softwarebasierten Produkte erforderlich. Die klinische Validierung findet sowohl vor als auch nach dem Inverkehrbringen statt. Eine neue Zweckbestimmung oder eine neue Zielpopulation erfordert eine Wiederholung der klinischen Bewertung.

Der Leitfaden führt Tabelle 3.2 als empfohlene klinische Evidenz ein, obwohl der eigene Titel der Tabelle sie als die für die Marktzulassung „erforderliche“ klinische Evidenz bezeichnet. Sie ist nach dem Schweregrad der Gesundheitssituation und der Bedeutung der Softwareinformationen für die medizinische Entscheidung gegliedert:

Der Schweregrad der Situation ändert die aufgeführte Evidenz nicht; dies tut nur die Bedeutung der Informationen.

Lokale klinische Validierung für bestimmte importierte Software

Bestimmte importierte softwarebasierte Medizinprodukte benötigen eine lokale klinische Validierung in Indonesien. Deren Zweck besteht darin nachzuweisen, dass die Software klinisch aussagekräftige Ergebnisse für die indonesische Zielpopulation liefert. Dies gilt für importierte Software, die:

• unter Verwendung von Daten, die die indonesische Bevölkerung repräsentieren, weiterentwickelt und/oder neu trainiert wurde; und/oder
• KI mit einem mittleren bis hohen Risikoniveau nutzt, insbesondere für die Diagnose, das Screening oder die klinische Entscheidungsfindung.

Die Validierung kann erfolgen an:

• Krankenhäusern, Universitäten oder akkreditierten Laboratorien;
• technischen Fachabteilungen des Gesundheitsministeriums, die für die Sicherheit von medizinischen Geräten und Einrichtungen oder für biomedizinische und gesundheitsgenomische Dienste zuständig sind.

Die Einheit für Biomedizin und Genomik kann die anderen Zentren bei Bedarf anleiten. Die Validierung kann parallel zum Antrag auf Marktzulassung erfolgen, sofern die klinischen und Leistungsnachweise des Herstellers beigefügt sind. Die Ergebnisse müssen spätestens ein Jahr nach Erteilung der Marktzulassung eingereicht werden. Während der Validierung darf das Produkt in begrenztem Umfang zu Evaluierungszwecken oder im Rahmen spezifischer Vereinbarungen verwendet werden, sofern die Patientensicherheit nicht gefährdet wird. Weichen die Ergebnisse signifikant von den ursprünglichen klinischen Nachweisen ab, können verwaltungsrechtliche Maßnahmen nach den geltenden Vorschriften folgen. Der Leitfaden hält fest, dass die lokale Validierung effizient, verhältnismäßig und risikobasiert sein sollte und den Zugang zu Innovationen nicht behindern sollte.

Regulatory Sandbox und Technologiereifegrad

Für Software, bei der es an ausreichenden klinischen Nachweisen hinsichtlich Genauigkeit, Präzision der Interpretation, Sicherheit oder Leistung bei der indonesischen Bevölkerung fehlt, kann das Unternehmen eine eigene klinische Prüfung gemäß dem Leitfaden für klinische Prüfungen von Medizinprodukten durchführen. Alternativ kann es begrenzte Tests über eine Regulatory Sandbox gemäß den geltenden Vorschriften durchführen. Derselbe Abschnitt legt fest, dass digitale Gesundheitsinnovationsprodukte, die eine Marktzulassung als Medizinprodukte beantragen, den Technology Readiness Level (TKT) 9 erreicht haben müssen. TKT 9 bedeutet, dass nachgewiesen wurde, dass das System in seiner tatsächlichen Betriebsumgebung in Übereinstimmung mit seiner Zweckbestimmung erfolgreich funktioniert. Der Leitfaden definiert den Begriff „digitales Gesundheitsinnovationsprodukt“ nicht und gibt auch nicht an, ob diese Anforderung über Produkte der Sandbox hinaus gilt.

Kennzeichnung

Die Kennzeichnung kann in Form eines Etiketts, einer Gebrauchsanweisung, einer Bedienungsanleitung oder anderer relevanter Informationen erfolgen. Sie muss mindestens den Produktnamen, die Software-Versionsnummer und den Produkteigentümer ausweisen. Zudem muss sie die Zweckbestimmung, Anweisungen, Leistungsinformationen und Sicherheitsangaben einschließlich Warnhinweisen klar und deutlich darstellen. Software, die auf physischen Datenträgern (CD, DVD oder USB) geliefert wird, benötigt ein physisches Etikett und eine Gebrauchsanweisung, entweder in gedruckter Form oder als Link. Software, die heruntergeladen wird oder webbasiert ist, muss mit Screenshots der Benutzeroberfläche registriert werden – wie etwa einem Startbildschirm (Splash Screen) oder einer Broschüre –, die die Identifikationselemente und die Versionsnummer zeigen. Den Anwendern müssen zudem der Download-Link, der Download-Ablauf, eine Installationsanleitung sowie das Betriebsverfahren bereitgestellt werden.

Änderungen nach der Zulassung

Der Leitfaden unterteilt Änderungen an einem zugelassenen softwarebasierten Produkt in zwei Kategorien sowie eine Auffangregel:

Jede Änderung muss im Qualitätsmanagementsystem dokumentiert werden.

Pflichten des Zulassungsinhabers

Der Inhaber muss ethische Grundsätze für softwarebasierte Produkte einhalten:

• Inklusivität und Nichtdiskriminierung;
• Sicherheit und Schutz;
• Menschlichkeit;
• Barrierefreiheit;
• Transparenz;
• Glaubwürdigkeit und Rechenschaftspflicht;
• Schutz personenbezogener Daten;
• Nachhaltigkeit;
• geistiges Eigentum.

Datenschutzvorfälle müssen gemäß den geltenden Vorschriften gemeldet werden. Für KI/ML-Produkte ist die Good Machine Learning Practice (GMLP) verpflichtend, geregelt anhand von zehn Prinzipien. Diese reichen von der Zweckbestimmung und multidisziplinären Fachkompetenz bis hin zur Überwachung nach dem Inverkehrbringen und dem Änderungsmanagement, einschließlich der Risiken von Aktualisierungen und erneutem Training. Bei KI/ML-Software muss das Datenmanagement Grundsätzen folgen, die Folgendes umfassen:

• Sicherheit und Vertraulichkeit von Patientendaten;
• Transparenz und Rechenschaftspflicht von KI-Funktionen;
• Datenminimierung;
• Aufbewahrung und Löschung auf der Grundlage der Einwilligung des Patienten;
• Cloud-Speicherung mit hohen Sicherheitsstandards;
• eine Richtlinie zur Meldung von Vorfällen und Datenschutzverletzungen;
• Eindämmung von Cyber-Bedrohungen.

Der Inhaber muss sich zudem verpflichten, dass die Ausgabedaten der Software in das nationale Gesundheitsinformationssystem (SIKN) oder SATUSEHAT integriert werden können. Im Falle einer Integration muss das Produkt als offenes System ausgelegt sein, die geltenden Interoperabilitätsstandards unterstützen und in der Lage sein, sich mit der nationalen Plattform für den Austausch von Gesundheitsdaten zu verbinden.

Überwachung nach dem Inverkehrbringen

Der Minister überwacht softwarebasierte Produkte. Ein Weg hierfür sind Berichte von Unternehmen, welche Folgendes umfassen:

• Reklamationsbearbeitung (Complaint Handling), die unerwünschte Ereignisse (Adverse Events) und Sicherheitskorrekturmaßnahmen im Feld (Field Safety Corrective Actions, FSCAs) abdeckt;
• technische Überwachung, die Schwachstellen in der Cybersicherheit abdeckt;
• klinische Leistungsvalidierung nach dem Inverkehrbringen unter Verwendung relevanter Daten, einschließlich Real-World-Daten.

Zeigt die Überwachung ein Risiko auf, können Korrekturmaßnahmen Sicherheitswarnungen und/oder einen Produktrückruf umfassen. Überwachungsaufzeichnungen müssen für Kontrollzwecke bereitgehalten werden. Die Überwachung umfasst zudem routinemäßige Vor-Ort-Inspektionen einmal pro Jahr sowie anlassbezogene Inspektionen bei Bedarf.

Was dies für Hersteller bedeutet

Pure Global-Analyse:

• Klassifizieren Sie die Software zuerst. Nutzen Sie das Ablaufdiagramm des Leitfadens, um zu entscheiden, ob es sich bei der Software um SiMD, SaMD oder kein Medizinprodukt handelt. SiMD wird als Zubehör des Hauptprodukts registriert und folgt dessen Anforderungen und Risikoklasse. Der Leitfaden selbst stellt keine Regeln für SaMD-Risikoklassen auf.
• Ordnen Sie SaMD der Tabelle für klinische Nachweise zu. Tabelle 3.2 verwendet dieselben zwei Achsen wie der IMDRF-Rahmen zur SaMD-Risikokategorisierung (N12): den Zustand der gesundheitlichen Situation und die Bedeutung der Informationen. Ein Hersteller, der seine Software bereits nach N12 kategorisiert hat, kann ersehen, wo sie einzuordnen ist. Eine klinische Prüfung ist nur in der Spalte „Behandeln oder Diagnostizieren“ aufgeführt. Ob eine Prüfung erforderlich ist, hängt auch davon ab, ob die Nachweise gut etabliert oder neuartig sind, sowie von etwaigen neuen klinischen Angaben.
• Importierte KI mit mittlerem bis hohem Risiko (insbesondere für Diagnose, Screening oder klinische Entscheidungen): Planen Sie eine lokale klinische Validierung vor der Markteinführung. Diese kann parallel zum Zulassungsantrag laufen, die Einjahresfrist beginnt jedoch mit der Erteilung der Marktzulassung; organisieren Sie Prüfzentren und den Datenzugang daher frühzeitig. Der Leitfaden legt nicht fest, welche Risikoklassen als mittel bis hoch gelten; stimmen Sie dies daher mit dem Ministerium ab. Bei jeglicher importierten Software stellt eine Weiterentwicklung oder ein Nachtraining mit Daten, die repräsentativ für die indonesische Bevölkerung sind, für sich genommen bereits ein Kriterium für eine lokale Validierung dar.
• Release-Management: Fügen Sie dem Software-Release-Prozess eine Auswirkungsprüfung für Indonesien hinzu. Algorithmenänderungen, die die diagnostische oder therapeutische Funktion oder die klinische Leistung beeinflussen, das Hinzufügen oder Entfernen von Alarmen, die das Patientenmanagement betreffen, sowie Änderungen am Betriebssystem oder an der Infrastruktur, die die Leistung oder Sicherheit beeinflussen könnten, erfordern alle eine neue Marktzulassung und keine bloße Änderung der bestehenden Zulassung. Jede Änderung muss im Qualitätsmanagementsystem dokumentiert werden, und die Version muss auf dem Etikett und/oder der Benutzeroberfläche ausgewiesen sein. Die Erfassung einer indonesischen Änderungskategorie für jedes Release verknüpft somit den regulatorischen Einreichungsweg mit der Version, die die Anwender sehen.
• KI-Entwicklung und -Lebenszyklus: Die zehn GMLP-Grundsätze, die der Inhaber anwenden muss, orientieren sich an den zehn Leitprinzipien im GMLP-Dokument des IMDRF (N88, 2025), wenngleich der Erlass N88 nicht zitiert. GMLP-Arbeiten für andere Märkte sind ein sinnvoller Ausgangspunkt, der Erlass legt jedoch nicht dar, wie die Konformität nachzuweisen ist. Datensätze müssen die vorgesehene Patientenpopulation repräsentieren, und sowohl die lokale Validierung als auch die Sandbox beziehen sich auf die Leistung in der indonesischen Bevölkerung. Rechnen Sie mit Fragen zur indonesischen Repräsentativität.
• Bereits registrierte oder im Prüfverfahren befindliche Produkte: Der Erlass trat am 7. September 2026 in Kraft und enthält keine Übergangsbestimmung. Klären Sie mit dem Gesundheitsministerium ab, wie er für anhängige Anträge sowie für die nächste Änderung oder Verlängerung bestehender Registrierungen gilt. Gehen Sie nicht davon aus, dass frühere Unterlagen weiterhin ausreichend sind.

Die Indonesien-Marktseite von Pure Global deckt den gesamten Registrierungsweg ab. Unsere Analyse zu KI als Medizinprodukt und globalem Marktzugang vergleicht, wie andere Regulierungsbehörden KI-Software behandeln.