Unsere Fälle
Stimmen
Software als Medizinprodukt: Einordnung, Klassifizierung und Entwicklung
Wann ist Software ein Medizinprodukt? Zweckbestimmung, MDR-Regel 11, Risikoklassen, IEC 62304 und CE-Kennzeichnung mit Praxisbeispielen.
Wann Software zum Medizinprodukt wird
Software wird zum Medizinprodukt, wenn der Hersteller ihr eine medizinische Zweckbestimmung gibt. Artikel 2 der MDR (EU) 2017/745 nennt dafür Zwecke wie Diagnose, Verhütung, Überwachung, Vorhersage, Prognose, Behandlung oder Linderung. Die Leitlinie MDCG 2019-11 hilft bei der Qualifizierung. Sie ersetzt den Verordnungstext nicht. Ein System, das nur Termine, Betten und Rechnungen führt, hat diese Zweckbestimmung nicht. Ein Wellness-Tagebuch ohne diagnostische Aussage auch nicht. Sobald die Software einen Befund vorschlägt, einen Score für eine klinische Entscheidung rechnet oder einen Alarm aus einem Vitalwert ableitet, kippt die Einordnung. Im Englischen heißt das oft SaMD. Der Maßstab auf dieser Seite bleibt die MDR.
Medizinprodukt-Software und die Softwareentwicklung in der Medizintechnik folgen danach demselben Gerüst: Zweckbestimmung, Regel 11, Lebenszyklus nach IEC 62304, Risikomanagement nach ISO 14971 und die Technische Dokumentation für die CE-Kennzeichnung. Den Verordnungstext schreiben wir nicht ab. Er steht bei EUR-Lex, MDR (EU) 2017/745. Die Qualifizierung von Software fasst MDCG 2019-11 zusammen. Die Norm selbst liegt im IEC-Webstore unter 62304. WTT schreibt die Software und die entwicklungsseitigen Nachweise. Die Kennzeichnung setzt der Hersteller. Eine Zertifizierung sagen wir nicht zu.
Die Zweckbestimmung als Ausgangspunkt
Beispiel einer Zweckbestimmung: Die Software berechnet aus Vitalzeichen und Laborwerten einen Score und markiert Patientinnen und Patienten, die das Stationsteam vorrangig auf eine Sepsis prüfen soll. Anwender sind Ärztinnen, Ärzte und Pflege auf der Normalstation, nicht Laien. Die Software stellt keine Diagnose und startet keine Therapie. Sie liefert Informationen, die in eine diagnostische Entscheidung einfließen.
Anwender, Ort und Grenze
Die Zweckbestimmung nennt, wer die Software nutzt, in welcher Umgebung und was sie ausdrücklich nicht tut. Fehlt die Grenze, liest eine Benannte Stelle den weitesten sinnvollen Zweck. Aus einem Anzeigewerkzeug wird dann Entscheidungssoftware. Der Satz gehört in die Technische Dokumentation, nicht in einen Werbetext.
Der Score ist schon Regel 11
Das Sepsis-Beispiel liefert Informationen für eine diagnostische Entscheidung. Nach Regel 11 der MDR liegt die Untergrenze dann bei Risikoklasse IIa. Ob IIb näher liegt, hängt davon ab, ob ein Fehler eine ernsthafte Verschlechterung auslösen kann. Die Klasse behauptet der Hersteller. Wir setzen sie nicht fest.
Ein enger Satz heilt keine Funktion
Wer die Funktion im Code lässt und sie in der Zweckbestimmung verschweigt, bleibt bei der tatsächlichen Bestimmung. Klasse I ist kein Gestaltungsziel. Sie bleibt nur, wenn die Software weder Entscheidungen speist noch physiologische Prozesse überwacht. Sonst folgt die Klasse der Funktion.
Ohne Hersteller kein Dokument
Die Zweckbestimmung unterschreibt der Hersteller, nicht der Entwicklungsdienstleister. Fehlt diese Person, gibt es keine ehrliche Risikoklasse und keine Technische Dokumentation. Wir stoppen die regulatorische Ausarbeitung, bis der Hersteller benannt ist. Die Software können wir trotzdem entwerfen. Die Kennzeichnung können wir nicht vorbereiten.
Ein Projekt aus unserer Arbeit
Treten Sie mit Studenten in Kontakt, um 1-zu-1-College-Einblicke und -Führungen live zu erhalten
SACHVERSTAND
Bildung
TECHNOLOGIEN
Was das für Ihr Projekt bedeutet
Zuerst die Einordnung
Bevor eine Zeile Produktionscode entsteht, schreiben wir die Zweckbestimmung so, dass Regel 11 daran prüfbar ist. Gehört das Vorhaben in ein breiteres klinisches System, liegt die Übersicht bei der individuellen Healthcare-Software. Die Klasse folgt aus dem Satz, nicht aus dem Wunsch, eine Benannte Stelle zu vermeiden.
Zuerst die Einordnung
Bevor eine Zeile Produktionscode entsteht, schreiben wir die Zweckbestimmung so, dass Regel 11 daran prüfbar ist. Gehört das Vorhaben in ein breiteres klinisches System, liegt die Übersicht bei der individuellen Healthcare-Software. Die Klasse folgt aus dem Satz, nicht aus dem Wunsch, eine Benannte Stelle zu vermeiden.
Lebenszyklus nach IEC 62304
Plan, Anforderungen, Architektur, Verifikation und Freigabe entstehen als Nachweise, nicht als nachgereichte Folien. Die Software-Sicherheitsklasse A, B oder C legt den Umfang fest. SOUP-Komponenten werden benannt und auf bekannte Fehler geprüft. Das Qualitätsmanagement nach ISO 13485 führt der Hersteller. Wir liefern in sein System.
Nachweise, keine Kennzeichnung
Wir schreiben die entwicklungsseitigen Teile der Technischen Dokumentation: Anforderungen, Architektur, Tests, Rückverfolgbarkeit, SOUP. Die CE-Kennzeichnung, die Konformitätserklärung und das Zeichen mit der Nummer der Benannten Stelle setzt der Hersteller. Eine Behördenabnahme und einen Eintrag in ein Verzeichnis sagen wir nicht zu.
Anbindung an die Telematikinfrastruktur
Wenn die Software an die Telematikinfrastruktur angebunden werden muss, ist das ein eigenes Vorhaben mit eigenen Schnittstellen und Fristen. Die Einordnung als Medizinprodukt ersetzt diese Anbindung nicht. Der vorgesehene Ort dafür ist die Seite Telematikinfrastruktur-Anbindung.
Interoperabilität getrennt halten
Profile, Schnittstellen und der Austausch mit anderen Systemen ändern die Zweckbestimmung nicht automatisch, sie können sie aber schärfen. Wer nur Daten transportiert, ist oft kein Medizinprodukt. Wer die Daten für eine Entscheidung aufbereitet, fällt unter Regel 11. Mehr dazu auf Interoperabilität im Gesundheitswesen.
Was nach der Freigabe bleibt
Post-Market Surveillance bleibt beim Hersteller. Softwareänderungen, bekannte Fehler und SOUP-Updates müssen in diesen Prozess. Wir können die Änderung dokumentieren und den Test wiederholen. Die Meldung an die Behörde und der Bericht an die Benannte Stelle bleiben beim Hersteller. Ein Wartungsvertrag ist keine Kennzeichnung.
IEC 62304: Lebenszyklus der Softwareentwicklung
Die Norm 62304 beschreibt Prozesse, keine Risikoklasse der MDR. Die Software-Sicherheitsklasse A, B oder C legt fest, welche Aktivitäten entfallen dürfen. Klasse A ist die schmalste, Klasse C die strengste. Wartung ist ein eigener Prozess neben diesen acht Entwicklungsschritten. SOUP ist Software, die nicht unter diesem Prozess für das Produkt entstanden ist.
Software-Entwicklungsplan
Der Plan nennt Lebenszyklus, Software-Sicherheitsklasse A, B oder C, Werkzeuge und die SOUP-Liste. Ohne Klasse ist der spätere Nachweisumfang eine Schätzung. Ergebnis ist der Plan, nicht der Code.
ErgebnisPlan und Sicherheitsklasse
Software-Entwicklungsplan
Der Plan nennt Lebenszyklus, Software-Sicherheitsklasse A, B oder C, Werkzeuge und die SOUP-Liste. Ohne Klasse ist der spätere Nachweisumfang eine Schätzung. Ergebnis ist der Plan, nicht der Code.
ErgebnisPlan und Sicherheitsklasse
Software-Anforderungen
Jede Anforderung lässt sich zur Zweckbestimmung und zu einem Risiko nach ISO 14971 zurückverfolgen. Was die Software nicht tun soll, steht daneben. Damit endet der Wunschzettel.
ErgebnisAnforderungen mit Abnahme
Software-Architektur
Die Architektur trennt Einheiten, Schnittstellen und SOUP. Eine Einheit, die eine klinische Entscheidung vorbereitet, bleibt sichtbar. Sie verschwindet nicht in einer Bibliothek ohne Namen.
ErgebnisArchitektur und SOUP
Software-Feinentwurf
Für Sicherheitsklasse B und C beschreibt der Feinentwurf die Einheiten so, dass ein anderer sie prüfen kann. Klasse A darf diesen Schritt enger fassen. Die Norm erlaubt den Verzicht, das Risiko nicht.
ErgebnisEntwurf der Einheiten
Implementierung und Verifikation
Einheiten werden gebaut und gegen ihren Entwurf geprüft. Bekannte Fehler der SOUP-Komponenten werden bewertet, nicht nur aufgelistet. Ein bestandener Unit-Test ist noch kein Systemtest.
ErgebnisEinheiten und Protokolle
Integration und Integrationstest
Die Einheiten laufen zusammen, einschließlich SOUP. Der Integrationstest prüft Schnittstellen und Fehlerfälle, die eine einzelne Einheit nicht zeigt. Das Protokoll nennt die Fassung.
ErgebnisIntegrierte Fassung
Software-Systemtest
Der Systemtest prüft die Software gegen die Anforderungen und gegen die Zweckbestimmung. Ein grüner Build ohne Bezug zur Anforderung zählt hier nicht. Die Rückverfolgbarkeit endet in diesem Protokoll.
ErgebnisSystemtest
Software-Freigabe
Die Freigabe listet Fassung, Restfehler, SOUP und die offene Punkte. Sie ist die Übergabe an den Hersteller, nicht die CE-Kennzeichnung. Die Konformitätserklärung bleibt bei ihm.
ErgebnisFreigabeprotokoll
MDR-Regel 11 und die Risikoklassen
Regel 11 in Anhang VIII der MDR ordnet Software zu. Die linke Spalte ist die Klasse, die mittlere ein Beispiel, die rechte das, was eine Benannte Stelle in diesem Pfad üblicherweise prüft. Die endgültige Klasse steht in der Zweckbestimmung. Diese Tabelle ist eine Lesehilfe, kein Bescheid.
- Benannte Stelle prüft das Produkt
- Nur ein Teilaspekt oder ein zweites Verfahren
- Keine Stelle für das Produkt
Technische Dokumentation und CE-Kennzeichnung
Die Monate sind Planungskorridore aus der Praxis der Konformitätsbewertung, keine Fristen der MDR und kein Termin von WTT. Die Technische Dokumentation beschreibt Zweckbestimmung, Auslegung, Nachweise zu den grundlegenden Sicherheits- und Leistungsanforderungen, Risikomanagement und die klinische Bewertung. Die CE-Kennzeichnung setzt der Hersteller nach bestandener Bewertung. Wir stellen sie nicht aus.
Klasse I
Erklärung
6–12 Monate
- Konformitätserklärung des Herstellers
- Technische Dokumentation trotzdem vollständig
- Qualitätsmanagement, oft über ISO 13485
- Gebrauchstauglichkeit nach IEC 62366
- Post-Market Surveillance als Bericht
Klasse IIa
Stichprobe
12–18 Monate
- Benannte Stelle im Verfahren
- Stichprobe der Technischen Dokumentation
- Lebenszyklus nach IEC 62304
- Risikomanagement nach ISO 14971
- PSUR statt nur eines Berichts
Klasse IIb und III
Vollprüfung
18–30 Monate
- Prüfung der Technischen Dokumentation
- Klinische Bewertung im Fokus
- Software-Sicherheitsklasse oft C
- Änderungen laufen über die Stelle
- Keine Zusage eines Abschlussdatums
Stimmen von Auftraggebern
BRANCHENANERKENNUNG
Luklabs
Stellvertretende Geschäftsführerin
Das Team ist klug, kreativ, nett, ruhig und professionell, und sie sind Problemlöser.
WTT Solutions achtete auf Details. Die meisten ihrer ersten Iterationen waren sehr nah an unseren beabsichtigten Designs. Infolgedessen mussten wir in der QA-Phase nicht viele Überarbeitungen vornehmen.
Ich habe es sehr genossen, mit ihnen zu arbeiten.
Abgrenzung zwischen MDR und IVDR
Dieselbe Codebasis kann zwei verschiedene Produkte sein. Entscheidend ist, ob die Zweckbestimmung am Menschen ansetzt oder an einer Probe außerhalb des Körpers. Die IVDR (EU) 2017/746 hat eigene Klassen. Der Wortlaut steht bei EUR-Lex. Ein Produkt trägt nicht beide Verordnungen für denselben Zweck.
Probe außerhalb des Körpers
Software, die ein Laborergebnis oder einen Selbsttest auswertet, um eine Diagnose zu stützen, fällt in der Regel unter die IVDR. Die MDR-Regel 11 ist dann der falsche Schlüssel. Die Benannte Stelle braucht den IVDR-Anwendungsbereich.
Wirkung am Menschen
Software, die Vitalzeichen, Bilder oder einen klinischen Score für eine Entscheidung am Patienten aufbereitet, bleibt bei der MDR. Das Sepsis-Beispiel oben ist dieser Pfad. Die IVDR wird dadurch nicht zusätzlich fällig.
Zwei Zwecke, zwei Produkte
Berechnet dieselbe Software einmal einen Score auf der Station und einmal eine Diagnose aus einer Blutprobe, sind das zwei Zweckbestimmungen. Jede braucht ihre eigene Klasse, ihre Dokumentation und ihr Konformitätsverfahren.
Andere Klassen, gleiche Disziplin
Die IVDR kennt nicht I, IIa, IIb und III. Ihre Software landet oft in Klasse B oder C, sobald sie Informationen für eine Entscheidung liefert. IEC 62304, ISO 14971 und ISO 13485 bleiben trotzdem die Arbeitsnormen.
Transport ist noch kein Produkt
Eine Schnittstelle, die einen Laborwert nur weiterreicht und nichts interpretiert, ist oft kein Medizinprodukt und kein In-vitro-Diagnostikum. Sobald sie warnt, filtert oder eine Handlung vorschlägt, beginnt die Einordnung von vorn.
Sonderfall DiGA
01
CE ist nicht das Verzeichnis
Eine DiGA braucht eine CE-Kennzeichnung und zusätzlich einen Eintrag beim BfArM. Die Kennzeichnung allein öffnet das Verzeichnis nicht. Den Rahmen beschreibt das BfArM. Wir reichen den Antrag nicht ein.
02
Klasse I, IIa oder IIb
Seit dem DigiG können Anwendungen der Risikoklasse I, IIa oder IIb eine DiGA sein. Klasse III erfüllt die Grundanforderung nicht. Für IIb ist die Konformitätsbewertung abgeschlossen, und der medizinische Nutzen liegt mit dem Antrag vor. Die Zweckbestimmung entscheidet das vorher.
03
Positiver Versorgungseffekt
Für die dauerhafte Aufnahme muss der Hersteller einen positiven Versorgungseffekt nachweisen. Eine vorläufige Aufnahme über einen Studienplan gibt es für Klasse I und IIa, zeitlich begrenzt. Bei Klasse IIb liegt der medizinische Nutzen schon mit dem Antrag vor. Ein Softwaretest ersetzt ihn nicht.
04
Datenschutz und Interoperabilität
Die DiGAV verlangt Nachweise zu Datenschutz, Informationssicherheit und Interoperabilität, zusätzlich zur MDR. Diese Nachweise sitzen neben der Technischen Dokumentation, nicht darin versteckt. Die Prüfkriterien veröffentlicht das BfArM, wir erfinden sie nicht.
05
Was wir in diesem Pfad bauen
Wir bauen die Software, den Lebenszyklus nach IEC 62304 und die entwicklungsseitigen Nachweise. Gebrauchstauglichkeit nach IEC 62366 können wir vorbereiten. Den positiven Versorgungseffekt, den Verzeichniseintrag und die Kennzeichnung tragen Hersteller und die zuständige Stelle.
06
Keine Listungszusage
Ein abgeschlossener Systemtest ist kein Bescheid des BfArM. Wir sagen weder die vorläufige noch die dauerhafte Aufnahme zu. Steht die Zweckbestimmung in Klasse III, sagen wir das, bevor jemand einen Verzeichnisantrag plant.
Risikomanagement nach ISO 14971
ISO 14971 ist der Prozess, mit dem der Hersteller Gefährdungen erkennt, bewertet und beherrscht. Die Norm ist nicht die Risikoklasse der MDR und nicht die Software-Sicherheitsklasse A, B oder C der IEC 62304. Drei Skalen, drei Fragen. Den Normtext führen wir nicht ab. Er liegt bei ISO. Wir liefern die Software-Anteile in die Risikomanagementakte des Herstellers.
Risikomanagementplan
Der Plan nennt Kriterien für die Akzeptanz, Rollen und die Verbindung zur Zweckbestimmung.
Risikoanalyse
Gefährdungen entstehen aus der bestimmungsgemäßen Verwendung und aus vorhersehbarem Fehlgebrauch.
Risikobewertung
Jedes Risiko wird gegen die Kriterien des Plans bewertet, bevor jemand es für akzeptabel erklärt.
Risikobeherrschung
Maßnahmen ändern die Software, die Gebrauchsanweisung oder beides. Eine Maßnahme ohne Nachweis bleibt eine Absicht.
Restrisiko
Was nach der Beherrschung bleibt, wird bewertet. Es verschwindet nicht, weil der Test grün war.
Nutzen und Risiko
Der Hersteller wägt den klinischen Nutzen gegen das Restrisiko. Diese Abwägung unterschreiben wir nicht.
Herstellung und SOUP
Informationen aus Bau und bekannten SOUP-Fehlern fließen zurück in die Akte, nicht in ein Nebendokument.
Post-Market Surveillance
Erkenntnisse nach dem Inverkehrbringen öffnen die Akte wieder. Die Überwachung führt der Hersteller.
KI-Software: MDR und AI Act
KI-Software, die selbst ein Medizinprodukt ist oder eine Sicherheitskomponente eines Produkts und eine Benannte Stelle braucht, ist ein Hochrisiko-System nach Artikel 6 Absatz 1 der KI-Verordnung (EU) 2024/1689. MDR und IVDR stehen dafür in Anhang I. Nach dem geltenden Artikel 113 gilt für diesen Pfad der 2. August 2028. Klasse I ohne Benannte Stelle fällt nicht automatisch in denselben Topf. Die MDR-Pflichten laufen unabhängig davon weiter: Zweckbestimmung, Regel 11, IEC 62304, ISO 14971 und die Technische Dokumentation. Der Wortlaut der Verordnung steht bei EUR-Lex. Das ist eine Lesehilfe, keine Rechtsberatung, und keine Zusage, dass eine Kennzeichnung zu diesem Datum vorliegt.
OpenAI
Google Gemini
Anthropic Claude
LangChain
LlamaIndex
Perplexity API
RAG / Pinecone / Qdrant
PostgreSQL
MySQL
MongoDB
Redis
Docker
Kubernetes
Terraform
GitHub Actions
Hallo, ich bin Serge!
Geschäftsführer & Mitgründer bei WTT Solutions
Haben Sie ein neues Projekt? Oder wollen Sie mal "Hallo" sagen...
