Medizinische Software · Regulatory Engineering · EU-Marktzugang
Wie erhält medizinische Software eine CE-Kennzeichnung?
Softwareentwicklung und regulatorische Entwicklung müssen gemeinsam die Freigabe erreichen
Die CE-Kennzeichnung ist kein Logo, das nach Abschluss der Entwicklung hinzugefügt wird. Sie ist das sichtbare Ergebnis eines Systems, das Zweckbestimmung, Softwarearchitektur, klinische Nachweise, Risikokontrollen, Qualitätsprozesse und Pflichten nach dem Inverkehrbringen miteinander verbindet.
Freigabepfad öffnen ↓Ein Produkt, zwei synchronisierte Entwicklungspfade
Eine zuverlässige Anwendung ist nicht automatisch ein konformes Medizinprodukt. Das Produkt und seine regulatorischen Nachweise müssen dieselbe Zweckbestimmung, dieselben Risiken, dieselbe Funktionalität und dieselbe freigegebene Version beschreiben.
Die Funktion entwickeln
Anforderungen, Architektur, Implementierung, Schnittstellen, Verifizierung, Usability, Cybersicherheit, Konfiguration und kontrollierte Freigabe.
Die Begründung entwickeln
Qualifizierung, Klassifizierung, Risiken, GSPR, klinische Nachweise oder Leistungsnachweise, QMS, Konformitätsbewertung und Lebenszykluskontrolle.
01
Zuerst klären, ob die Software ein Medizinprodukt ist #
Medical Device Software ist Software, die allein oder in Kombination für einen Zweck eingesetzt werden soll, der von der Definition eines Medizinprodukts oder eines In-vitro-Diagnostikums erfasst wird.
Software kann MDSW sein, wenn sie diagnostische oder therapeutische Entscheidungen unterstützt, physiologische Prozesse überwacht, eine patientenspezifische Behandlung berechnet, medizinische Bilder auswertet, diagnostische Daten interpretiert oder klinisch relevante Verläufe vorhersagt.
Die Software muss weder ein physisches Medizinprodukt steuern noch unmittelbar auf den menschlichen Körper einwirken. Eine eigenständige Anwendung kann selbst ein Medizinprodukt sein, wenn ihre Zweckbestimmung medizinisch ist.
- Unterstützung diagnostischer oder therapeutischer Entscheidungen
- Patientenspezifische Berechnungen oder Vorhersagen
- Auswertung von Bildern, Signalen oder physiologischen Daten
- Überwachung physiologischer Prozesse
- Interpretation von Labor- oder anderen Diagnosedaten
Nicht jedes digitale Gesundheitsprodukt ist MDSW. Software, die ausschließlich Terminplanung, Abrechnung, Kommunikation, Speicherung, Archivierung, verlustfreie Übertragung oder allgemeines Wohlbefinden unterstützt, kann außerhalb von MDR und IVDR liegen, sofern sie keine medizinische Funktion erfüllt.
Beginnen Sie nicht mit der Auswahl einer Risikoklasse. Klären Sie zuerst, ob das Produkt ein Medizinprodukt, ein IVD, ein Zubehör oder ein nicht reguliertes Produkt ist.
Der aktuelle europäische Ansatz wird im Leitfaden MDCG 2019-11 rev.1 der Europäischen Kommission erläutert. MDRC behandelt die Abgrenzung außerdem im Artikel über Software als Medizinprodukt oder Zubehör.
02
Die Zweckbestimmung vor dem regulatorischen Weg festlegen #
Die Zweckbestimmung bildet die Grundlage der Konformitätsbewertung. Sie legt fest, was die Software leisten soll, welche Verordnung gilt, welche Nachweise benötigt werden und welche Folgen ein fehlerhaftes Ergebnis haben kann.
Eine belastbare Zweckbestimmung beschreibt die medizinische Funktion, die Nutzer, die Patientenpopulation, die Anwendungsumgebung, die Eingaben, die Ausgaben und den klinischen Kontext. „Software für medizinisches Fachpersonal“ definiert noch kein reguliertes Produkt.
- Medizinische Funktion und klinische Aussage
- Vorgesehene Patientenpopulation und Nutzergruppe
- Anwendungsumgebung und Arbeitsablauf
- Eingabedaten und erzeugte Ausgabe
- Rolle der Ausgabe bei einer medizinischen Entscheidung
Ebenso wichtig ist die Produktgrenze. Eine digitale Plattform kann eine regulierte klinische Funktion mit Kommunikations-, Speicher- oder Verwaltungsmodulen verbinden. Diese Funktionen haben nicht automatisch denselben regulatorischen Status. Der Hersteller muss zeigen, welche Komponenten zum Medizinprodukt gehören und welche außerhalb davon bleiben.
Eine klare regulatorische Strategie verhindert, dass Marketingaussagen, technische Architektur und Konformitätsbewertungsweg während der Entwicklung auseinanderlaufen.
03
Bestimmen, ob MDR oder IVDR gilt #
Software fällt grundsätzlich unter die MDR, wenn ihre Zweckbestimmung Diagnose, Prävention, Vorhersage, Prognose, Überwachung, Behandlung oder Linderung einer Krankheit betrifft, ohne die spezifische Definition eines IVD zu erfüllen.
Software kann unter die IVDR fallen, wenn sie Informationen durch die Untersuchung von Daten aus Proben menschlichen Ursprungs liefert und diese Informationen einem IVDR-Zweck dienen. Dazu gehören beispielsweise die Feststellung eines pathologischen Zustands, die Bestimmung einer Prädisposition, die Vorhersage des Therapieansprechens oder die Überwachung therapeutischer Maßnahmen.
Die Datenquelle ist relevant, entscheidet aber nicht allein. Zweckbestimmung, Art der erzeugten Information und Verwendung dieser Information müssen gemeinsam bewertet werden.
Informationen oder Funktionen mit medizinischem Zweck außerhalb des spezifischen Bereichs der In-vitro-Untersuchung.
Informationen aus der Untersuchung von Proben menschlichen Ursprungs für einen Zweck der IVDR.
Ein Laborinformationssystem, das Ergebnisse nur speichert und überträgt, ist möglicherweise kein IVD. Software, die Labormesswerte interpretiert und patientenspezifische diagnostische Informationen erzeugt, kann dagegen ein IVD sein.
Die rechtlichen Definitionen finden sich in den amtlichen Texten der Medizinprodukteverordnung und der Verordnung über In-vitro-Diagnostika.
04
Die Software nach ihrer klinischen Auswirkung klassifizieren #
Die Qualifizierung beantwortet die Frage, ob das Produkt ein Medizinprodukt ist. Die Klassifizierung bestimmt, wie viel regulatorische Kontrolle erforderlich ist.
Medizinische Software nach der MDR wird häufig anhand von Regel 11 des Anhangs VIII klassifiziert. Software, die Informationen für diagnostische oder therapeutische Entscheidungen bereitstellt, gehört grundsätzlich zur Klasse IIa. Sie wird der Klasse IIb oder III zugeordnet, wenn eine fehlerhafte Entscheidung schwerwiegendere Folgen haben kann.
Software zur Überwachung physiologischer Prozesse gehört grundsätzlich zur Klasse IIa. Sie kann in die Klasse IIb fallen, wenn sie Vitalparameter überwacht, deren Veränderung zu einer unmittelbaren Gefahr führen könnte. Software, die nicht von diesen Teilen der Regel 11 erfasst wird, kann in Klasse I verbleiben.
Bei Software nach der IVDR richtet sich die Klassifizierung nach ihrer Zweckbestimmung und den anwendbaren IVDR-Regeln. Eigenständige Software wird für sich klassifiziert. Software, die ein IVD steuert oder dessen Anwendung beeinflusst, folgt grundsätzlich der Klasse dieses Produkts.
Die Klassifizierungsbegründung sollte Zweckbestimmung, anwendbare Regel und vorhersehbare klinische Folgen miteinander verbinden. Klasse I darf nicht allein deshalb gewählt werden, weil das Produkt „nur Software“ ist.
05
Ein Qualitätsmanagementsystem für den tatsächlichen Entwicklungsprozess aufbauen #
Jeder Hersteller benötigt ein Qualitätsmanagementsystem, das zum Produkt, zur Risikoklasse und zu seinen Tätigkeiten passt. Das QMS muss deutlich mehr als die Programmierung kontrollieren.
Regulatorische Strategie, Zweckbestimmung, Anforderungen und Entwicklungslenkung
Risikomanagement, klinische Bewertung, Verifizierung, Validierung und Usability
Lieferanten, ausgelagerte Prozesse, Freigaben, Änderungen und Konfiguration
PMS, Vigilanz, Cybersicherheit, CAPA und fortlaufende Konformität
EN ISO 13485 wird häufig zur Strukturierung dieses Systems eingesetzt und kann innerhalb ihres Anwendungsbereichs Nachweise für die Konformität liefern. Sie ersetzt MDR oder IVDR nicht. Der Hersteller muss weiterhin zeigen, dass jede anwendbare regulatorische Verpflichtung erfüllt wird.
Bei Software mit Beteiligung einer Benannten Stelle wird das QMS in der Regel im Rahmen der Konformitätsbewertung geprüft. Eine sauber formulierte Verfahrenssammlung reicht nicht aus, wenn die Entwicklungsaufzeichnungen zeigen, dass diese Verfahren nicht eingehalten wurden.
06
Lebenszyklusnachweise statt einer bloßen IEC-62304-Aussage schaffen #
IEC 62304 bietet einen anerkannten Rahmen für Softwarelebenszyklusprozesse. Sie behandelt Planung, Anforderungen, Architektur, Detailentwurf, Implementierung, Integration, Prüfung, Freigabe, Wartung, Konfigurationsmanagement und Problemlösung.
Die Norm ist wichtig, aber keine vollständige regulatorische Antwort. IEC 62304 allein weist nicht die Konformität mit allen Grundlegenden Sicherheits- und Leistungsanforderungen nach. Sie ersetzt weder Risikomanagement noch Usability Engineering, klinische Nachweise, Cybersicherheit, Kennzeichnung, Qualitätsmanagement oder Überwachung nach dem Inverkehrbringen.
Softwarelebenszyklusprozesse und kontrollierte Wartung
Risikomanagement für Medizinprodukte über den gesamten Produktlebenszyklus
Usability Engineering und Kontrolle anwendungsbedingter Risiken
Sicherheitsaktivitäten im Lebenszyklus von Gesundheitssoftware
Qualitätsmanagementprozesse zur Unterstützung einer beständigen Konformität
Normen sind grundsätzlich freiwillig und sollten entsprechend dem Produkt und seinen Risiken ausgewählt werden. Ist eine Norm harmonisiert und im Amtsblatt der EU zitiert, kann ihre Anwendung nur für die von ihr abgedeckten Anforderungen eine Konformitätsvermutung begründen. Die Europäische Kommission veröffentlicht aktuelle Informationen zu harmonisierten Medizinproduktenormen.
Weitere Aspekte des Lebenszyklus behandelt MDRC auf den Seiten zur Konformität mit IEC 62304 und zur Cybersicherheit medizinischer Software.
07
Die Technische Dokumentation sollte eine zusammenhängende Geschichte erzählen
Die Technische Dokumentation ist kein Lager für voneinander getrennte Dokumente. Sie ist eine rückverfolgbare Argumentation, die zeigt, wie die Software konzipiert, entwickelt, bewertet, freigegeben und unter Lebenszykluskontrolle gestellt wurde.
Die Zweckbestimmung führt zu Anforderungen. Anforderungen führen zu Risiken und Kontrollen. Kontrollen führen zu Verifizierung, klinischen Nachweisen und der abschließenden Nutzen-Risiko-Bewertung.
Sie sollte jede anwendbare Anforderung mit einem konkreten kontrollierten Nachweis verbinden. Eine allgemeine Aussage wie „konform mit IEC 62304“ ersetzt diese Rückverfolgbarkeit nicht.
08
Klinischen Nutzen oder Leistungsfähigkeit nachweisen #
Software kann exakt wie spezifiziert funktionieren und dennoch klinisch versagen. Ein technisch genauer Algorithmus ist nicht automatisch klinisch relevant.
Der Hersteller muss nachweisen, dass der Zusammenhang zwischen der Softwareausgabe und dem angestrebten klinischen Zustand valide ist und dass die Software in der vorgesehenen Population, Umgebung und im vorgesehenen Arbeitsablauf angemessen funktioniert.
Valide klinische Assoziation, technische Leistung und klinische Leistung stützen die klinische Bewertung.
Wissenschaftliche Validität, analytische Leistung und klinische Leistung stützen die Leistungsbewertung.
Die Nachweise können Literatur, analytische Studien, retrospektive Datensätze, prospektive Prüfungen, Usability-Nachweise, Real-World-Daten und Informationen nach dem Inverkehrbringen umfassen. Eine klinische Prüfung oder Leistungsstudie ist nicht für jedes Produkt automatisch erforderlich. Der notwendige Nachweisumfang ergibt sich aus den Aussagen, der Neuartigkeit, dem Risiko, den Eingaben, den Ausgaben und der vorgesehenen Population.
Die aktuelle Leitliniensammlung der Europäischen Kommission enthält MDCG 2020-1 zur klinischen Bewertung und Leistungsbewertung von MDSW. MDRC bietet weitere Informationen zur klinischen Bewertung softwarezentrierter Medizintechnologien.
09
Regulatorische Rollen, UDI und Registrierung organisieren #
Jeder Hersteller muss über mindestens eine für die Einhaltung der Regulierungsvorschriften verantwortliche Person verfügen, die die Qualifikationsanforderungen aus Artikel 15 erfüllt. Kleinst- und Kleinunternehmen dürfen einen externen PRRC einsetzen, die Person muss jedoch dauerhaft und ständig zur Verfügung stehen.
Ein Hersteller mit Sitz außerhalb der Europäischen Union muss einen einzigen EU-Bevollmächtigten mindestens für alle Produkte derselben generischen Produktgruppe benennen. Die Beziehung wird durch ein schriftliches, vom Bevollmächtigten angenommenes Mandat begründet.
Regulatorische Aufsicht mit der in Artikel 15 verlangten Qualifikation und Verfügbarkeit
Formelle EU-Schnittstelle für Hersteller mit Sitz außerhalb der Union
Auch medizinische Software unterliegt dem UDI-System. Der Hersteller muss die anwendbare Struktur von Basis-UDI-DI und UDI-DI festlegen, die Regeln der ausgewählten Zuteilungsstelle befolgen und bestimmen, wie die Kennung für die Software dargestellt wird.
Eine neue UDI-DI kann erforderlich werden, wenn eine Änderung die ursprüngliche Leistung, Sicherheit, Zweckbestimmung oder Interpretation von Daten durch die Software verändert. Die Basis-UDI-DI ist nicht die Kennung einer einzelnen Softwareversion.
Der Zusammenhang zwischen diesen Kennungen wird im MDRC-Artikel über UDI-DI, Basis-UDI-DI, GTIN und GMN erläutert.
Seit dem 28. Mai 2026 sind die ersten vier EUDAMED-Module verpflichtend. Die Registrierung der Akteure sowie die UDI- und Produktregistrierung gehören daher in den aktiven Marktzugangsplan. Den aktuellen Stand erläutert die EUDAMED-Übersicht der Europäischen Kommission.
10
Die anwendbare Konformitätsbewertung abschließen #
Der Konformitätsbewertungsweg ergibt sich aus der anwendbaren Verordnung und der Risikoklasse. Software der Klasse I nach MDR und der Klasse A nach IVDR kann grundsätzlich in Eigenverantwortung erklärt werden. Auch diese Wege verlangen eine vollständige Technische Dokumentation, ein konformes QMS, Nachweise, Risikomanagement, Registrierung und eine Planung der Überwachung nach dem Inverkehrbringen.
Selbsterklärung bedeutet keine Befreiung. Sie bedeutet, dass der Hersteller die Konformitätsbewertung ohne routinemäßige Beteiligung einer Benannten Stelle durchführt.
Bei höheren Softwareklassen bewertet eine Benannte Stelle das anwendbare QMS und die Technische Dokumentation. Die Benannte Stelle vergibt nicht die CE-Kennzeichnung. Nach erfolgreicher Bewertung stellt sie die entsprechende Bescheinigung aus. Anschließend erstellt der Hersteller die EU-Konformitätserklärung und bringt die CE-Kennzeichnung an. Ist eine Benannte Stelle beteiligt, steht ihre vierstellige Kennnummer neben der Kennzeichnung.
Die Vorbereitung sollte vor dem formellen Antrag beginnen. Der Hersteller benötigt eine Benannte Stelle, deren Benennung die anwendbare Verordnung und die relevanten Medizinprodukt- oder IVD-Codes abdeckt. In der Bewertung wird geprüft, ob Zweckbestimmung, Klassifizierung, Risiken, Nachweise, Softwarelebenszyklus und QMS dasselbe Produkt beschreiben.
Die MDRC-Seite zur Vorbereitung auf die Benannte Stelle erläutert, wie sich Unternehmen auf diese Prüfung vorbereiten können.
11
Die CE-Kennzeichnung als Beginn eines kontrollierten Lebenszyklus verstehen #
Medizinische Software verändert sich auch nach dem Inverkehrbringen weiter. Betriebssysteme entwickeln sich. Bibliotheken werden aktualisiert. Schwachstellen treten auf. Datenverteilungen verschieben sich. Nutzer entdecken unerwartete Arbeitsabläufe und die klinische Praxis entwickelt sich weiter.
Reklamationen, Leistung, Schwachstellen, Trends und reale Nutzung
Klinische Auswirkungen, Risiko, regulatorische Bedeutung und Handlungsbedarf
Korrektur, Aktualisierung, Kommunikation, Nachweise und Konfiguration
PMS-Berichte, gegebenenfalls PSUR, CAPA und Änderungsnachweise
Regressionstests, Sicherheitstests und Wirksamkeitskontrollen
Genehmigte Version, aktualisierte Informationen und fortbestehende Konformität
Ein Patch kann technisch klein und klinisch dennoch bedeutsam sein. Eine Modellaktualisierung kann die durchschnittliche Leistung verbessern und zugleich ein neues Risiko für eine unterrepräsentierte Patientengruppe schaffen. Eine neue Datenquelle kann die regulatorische Grenze des Produkts verändern.
Jede Änderung muss hinsichtlich ihrer Auswirkungen auf Zweckbestimmung, Klassifizierung, Sicherheit, Leistung, Cybersicherheit, klinische Nachweise, UDI und Zertifizierungsstatus bewertet werden.
Fazit
CE-Kennzeichnung bedeutet die Freigabe einer kontrollierten Medizintechnologie
Die CE-Kennzeichnung medizinischer Software ist keine Übung in der Erstellung von Dokumenten. Sie ist der Prozess, eine medizinische Idee in ein kontrolliertes und durch Nachweise gestütztes Produkt zu überführen.
Der belastbarste Weg beginnt mit einer präzisen Zweckbestimmung, einer klaren Produktgrenze und einer begründeten Klassifizierung. Anschließend verbindet er die Softwareentwicklung mit Risiken, Usability, Cybersicherheit, klinischen Nachweisen, Technischer Dokumentation und Qualitätsmanagement.
Werden diese Elemente parallel zum Produkt entwickelt, wird die Konformitätsbewertung zum Abschluss eines bereits aufgebauten Systems und nicht zum Versuch, die regulatorische Geschichte erst nach Entwicklungsende zu rekonstruieren.
Typische Lücken
Was Hersteller besonders häufig unterschätzen
Die Zweckbestimmung wird erst formuliert, nachdem Architektur und Aussagen bereits feststehen.
Klasse I wird gewählt, weil das Produkt Software ist.
Die Konformität mit IEC 62304 wird mit vollständiger MDR- oder IVDR-Konformität gleichgesetzt.
Die Prüfung belegt technische Genauigkeit, aber keinen klinischen Nutzen.
Die Technische Dokumentation entspricht nicht der tatsächlich freigegebenen Version.
Cybersicherheit, UDI, EUDAMED und PMS werden bis zum Projektende aufgeschoben.
Regulatorischer Softwareweg
Müssen Produktentwicklung und regulatorische Entwicklung aufeinander abgestimmt werden?
Aus dem Wissenszentrum