Medizinische Software: entwickelt, zertifiziert, einsatzbereit.

Braucht mein Produkt eine MDR-Zertifizierung? Eine Entscheidungshilfe für den Graubereich

HTI Wissen · Regulatorische Strategie · August 2026

Die häufigste Frage in unseren Erstgesprächen lautet nicht „Wie kommen wir durch die Zertifizierung?", sondern eine Stufe früher: „Müssen wir überhaupt?" Und die ehrliche Antwort ist: Bei den meisten Software-Vorhaben ist das keine Ja/Nein-Frage, sondern eine Abwägung im Graubereich.

Die MDR knüpft den Medizinprodukt-Status an die Zweckbestimmung: Was sagt der Hersteller, wofür die Software gedacht ist? Dieselbe Funktion kann je nach Formulierung ein Klasse-IIa-Medizinprodukt sein — oder eine nicht regulierte Wellness-Anwendung. Wer diagnostiziert, therapiert oder Therapieentscheidungen beeinflusst, ist in der Regel drin. Wer nur dokumentiert, organisiert oder allgemeine Informationen anzeigt, oft nicht. Dazwischen liegt ein weites Feld, in dem die Formulierung der Zweckbestimmung entscheidet.

Deshalb ist die Frage im Kern eine Geschäftsentscheidung, keine juristische Fußnote. Zwei Strategien stehen sich gegenüber:

• Glaubwürdigkeit über das Zertifikat: Ein CE-Kennzeichen als Medizinprodukt öffnet Türen bei Ärzten, Kliniken und Kassen — kostet aber Zeit, Geld und laufende Pflege von QMS und Dokumentation.
• Geschwindigkeit ohne Medizinprodukt-Status: Schneller am Markt, früheres Nutzerfeedback — aber mit engen Grenzen bei Aussagen, Funktionen und Vertriebswegen, und dem Risiko einer späteren Umklassifizierung.

Der teuerste Fehler ist nicht die falsche Antwort, sondern die unbewusste: Teams, die aus Vorsicht zu früh volle MDR-Konformität aufbauen und Overhead bezahlen, bevor das Produkt seinen Markt bewiesen hat — oder Teams, die den Status ignorieren und später alles rückwirkend dokumentieren müssen. Beides haben wir gesehen. Das eine davon haben wir selbst erlebt.

Unsere Empfehlung: Treffen Sie die Entscheidung explizit, dokumentieren Sie die Begründung, und legen Sie fest, welches Ereignis eine Neubewertung auslöst. Wer im Graubereich gute Antworten auf die strategischen Fragen hat, trifft nur noch gute Entscheidungen.

MDR und EU AI Act gleichzeitig: Was für KI in medizinischer Software wirklich gilt

HTI Wissen · KI & Regulierung · August 2026

Wer eine KI-Funktion in ein Medizinprodukt einbaut, bekommt zwei Regulierungswelten auf einmal: die MDR für das Medizinprodukt und den EU AI Act für das KI-System. Die wichtigste Einordnung vorweg: KI in Medizinprodukten, die eine Konformitätsbewertung durch eine Benannte Stelle durchlaufen, gilt in der Regel als Hochrisiko-KI-System. Damit sind beide Regelwerke parallel anzuwenden.

Das klingt nach doppelter Arbeit — muss es aber nicht sein. Viele Anforderungen überlappen: Risikomanagement, Datenqualität, technische Dokumentation, Logging, menschliche Aufsicht. Wer beide Welten von Anfang an zusammen denkt, dokumentiert vieles nur einmal. Wer sie nacheinander abarbeitet, baut zwei getrennte Dokumentationsgebäude und zahlt doppelt.

Drei Punkte, die in Projekten regelmäßig unterschätzt werden:

• Zuständigkeit: Seit Inkrafttreten des deutschen KI-Durchführungsgesetzes (Juli 2026) ist die Bundesnetzagentur zentrale KI-Aufsicht — KI-Medizinprodukte bleiben aber bei der sektoralen Aufsicht, also beim BfArM. Wer sich an die falsche Behörde orientiert, plant an den falschen Anforderungen entlang.
• Lernende Systeme: Ein Modell, das sich im Feld weiterentwickelt, braucht einen definierten Änderungsrahmen. Ohne ihn wird jedes Modell-Update potenziell zur meldepflichtigen Änderung.
• Datenherkunft: Trainings- und Validierungsdaten müssen dokumentiert repräsentativ für die Zweckbestimmung sein — nachträglich ist das kaum zu heilen.

Der Zeitfaktor kommt dazu: Die Aufsichtsbehörden beginnen, Transparenz- und Governance-Pflichten durchzusetzen, und die Nachfrage nach Prüfungen für klinische KI steigt. Wer jetzt ein KI-Medizinprodukt plant, sollte die Konformität mit beiden Regelwerken als eine gemeinsame Architekturaufgabe behandeln — nicht als zwei Compliance-Projekte.

1.500 Seiten später: Woran Technische Dokumentationen bei der Benannten Stelle scheitern

HTI Wissen · Technische Dokumentation · August 2026

Wir haben die Technische Dokumentation für ein Klasse-IIa-Produkt selbst geschrieben — als Entwicklungspartner des Herstellers, über 1.500 Seiten, die eine Benannte Stelle geprüft und akzeptiert hat. Aus dieser Erfahrung und aus Projekten, die wir sanieren durften, kennen wir die Muster, an denen Dokumentationen scheitern. Es sind selten fehlende Kapitel. Es ist fast immer fehlende Konsistenz.

• Die Zweckbestimmung franst aus. In der klinischen Bewertung steht eine andere Formulierung als im Risikomanagement und wieder eine andere in der Gebrauchsanweisung. Prüfer lesen quer — jede Abweichung erzeugt eine Rückfrage.
• Traceability reißt ab. Anforderung → Architektur → Implementierung → Test → Risikomaßnahme: Wenn diese Kette nicht durchgängig nachvollziehbar ist, gilt die Software als nicht ausreichend verifiziert — egal wie gut sie tatsächlich ist.
• Das Risikomanagement lebt nicht. Eine ISO-14971-Tabelle, die einmal befüllt und nie wieder angefasst wurde, erkennt jeder Auditor. Risiken müssen mit jeder Designentscheidung mitwachsen.
• Software-Lebenszyklus nur auf dem Papier. IEC 62304 verlangt gelebte Prozesse: Wer im Audit nicht zeigen kann, wie ein Bugfix durch Klassifizierung, Review und Regression läuft, hat ein Prozessproblem, kein Doku-Problem.
• Nachgelagerte Dokumentation. Der Klassiker: erst entwickeln, dann dokumentieren. Rückwirkend geschriebene Doku ist teurer, schlechter und im Zweifel erkennbar.

Die gemeinsame Wurzel: Dokumentation wird als Pflicht nach der Entwicklung behandelt statt als Teil von ihr. Zertifizierbarkeit kann man nicht nachträglich einbauen — man baut sie von Tag 1 ein, oder man bezahlt sie doppelt: einmal in Nacharbeit, einmal in verlorener Zeit bei der Benannten Stelle.

Benannte Stellen bleiben der Engpass: Was die Insolvenz einer Benannten Stelle für Hersteller heißt

HTI Wissen · Zertifizierung · August 2026

Im August 2026 wurde eine skandinavische Benannte Stelle insolvent — nur wenige Monate nach ihrer Übernahme. Für die betroffenen Hersteller bedeutet das: Benannte Stelle wechseln, Technische Dokumentation neu einreichen, Zeitplan neu schreiben. Der Einzelfall ist ärgerlich; das Muster dahinter ist die eigentliche Nachricht.

Die Kapazität der Benannten Stellen ist seit Jahren der strukturelle Engpass der MDR — und der Markt konsolidiert sich weiter. Gleichzeitig fordern die Benannten Stellen selbst mehr datengetriebene Aufsicht: Post-Market-Überwachung und Vigilanz rücken stärker in den Fokus. Für Hersteller heißt das zweierlei:

• Die Benannte Stelle ist ein Projektrisiko wie jedes andere — mit Eintrittswahrscheinlichkeit und Plan B. Wer heute ein Zertifizierungsprojekt aufsetzt, sollte Wartezeiten realistisch einplanen, die wirtschaftliche Stabilität des Anbieters im Blick behalten und die Dokumentation so führen, dass ein Wechsel kein Neustart wäre.
• Eine saubere, konsistente Technische Dokumentation ist die beste Versicherung. Wer seine Akte jederzeit vollständig, versioniert und nachvollziehbar vorlegen kann, verliert bei einem erzwungenen Wechsel Wochen. Wer sie erst zusammensuchen muss, verliert Quartale.

Unsere praktische Empfehlung für Projektleiter: Behandeln Sie „NB-Wechsel" als Szenario in Ihrem Risikomanagement, prüfen Sie Ihre Einreichungsfähigkeit einmal pro Quartal, und verhandeln Sie Zeitpuffer in Roadmap und Finanzierung, bevor der Engpass sie erzwingt. Der Engpass ist planbar — wenn man ihn als Konstante akzeptiert statt als Überraschung.

Unser teuerster Fehler: zu früh auf volle MDR-Konformität

HTI Wissen · Aus unserer Praxis · August 2026

Wenn wir heute Gründern raten, die Medizinprodukt-Frage als Geschäftsentscheidung zu behandeln, dann nicht aus dem Lehrbuch — sondern weil wir die Folgen eines zu frühen „Ja" selbst durchlebt haben.

In unserem Kernprojekt — einem Klasse-IIa-Produkt, das wir als Entwicklungspartner für unseren Kunden gebaut haben — fiel früh die Entscheidung für den vollen MDR-Weg: Qualitätsmanagement nach ISO 13485, Risikomanagement nach ISO 14971, Entwicklung nach IEC 62304, vollständige Technische Dokumentation. Aus Überzeugung — und aus Vorsicht. Wir haben diesen Apparat operativ aufgebaut und betrieben. Was dabei unterschätzt wurde: der laufende Overhead, den dieser Apparat erzeugt, bevor das Produkt seinen Markt bewiesen hat. Jede Produktidee, jedes Experiment, jede kleine Änderung lief durch Prozesse, die für ein reifes Produkt gebaut sind. Es wurde Konformität bezahlt, als Markttest gebraucht worden wäre.

Am Ende ist das Produkt zertifiziert — die Substanz hat sich ausgezahlt, die Dokumentation hat der Benannten Stelle standgehalten. Aber der Weg war teurer und langsamer, als er hätte sein müssen. Heute wissen wir: Es gibt einen richtigen Zeitpunkt für volle Konformität — und er liegt selten am Anfang.

Was wir daraus für unsere Kunden ableiten:

• Erst die Strategie, dann der Apparat. Die Frage „Medizinprodukt: ja/nein/wann?" verdient eine explizite, dokumentierte Entscheidung — kein Bauchgefühl in die eine oder andere Richtung.
• Konformität skaliert mit. Man kann regulatorisch sauber arbeiten (Architektur, Traceability, Dokumentationsdisziplin), ohne vom ersten Tag den vollen QMS-Apparat zu betreiben — wenn man den Übergang von Anfang an mitplant.
• Übervorsicht ist auch ein Risiko. Sie fühlt sich verantwortungsvoll an, kostet aber genau das, was junge Produkte am wenigsten haben: Geschwindigkeit und Geld.

Diesen Fehler machen Sie mit uns nicht — wir haben ihn schon durchlebt.

Inhouse entwickeln, extern absichern: Wie Software-Validierung nach ISO 13485 Ihr Projekt rettet

HTI Wissen · Team & Prozesse · August 2026

Nicht jedes Unternehmen will oder soll seine Softwareentwicklung auslagern. Oft ist das interne Team fachlich das beste für das Produkt — es fehlt nicht an Können, sondern an regulatorischer Absicherung: Wer validiert die Software nach ISO 13485? Wer prüft, ob die Technische Dokumentation der Benannten Stelle standhält? Wer merkt rechtzeitig, dass die Traceability-Kette gerissen ist?

Genau hier setzt projektbegleitender Support an — das Modell, das wir intern „Arzt an der Seitenlinie" nennen: Ihr Team entwickelt und bleibt am Steuer. Wir sichern parallel ab. Konkret heißt das:

• Software-Validierung nach ISO 13485 — auch für Ihre Werkzeugkette: Nicht nur das Produkt, auch Entwicklungs- und QM-Werkzeuge müssen validiert sein. Das wird regelmäßig übersehen und fällt im Audit auf.
• Reviews der Technischen Dokumentation in festen Abständen — Konsistenz von Zweckbestimmung, Risikomanagement und Tests, bevor die Benannte Stelle sie prüft.
• Zertifizierungsfahrplan mit klaren Meilensteinen: Was muss wann einreichungsfähig sein, und wo steht das Projekt wirklich?

Der Effekt geht über das einzelne Projekt hinaus: Ihr Team lernt an echten Review-Ergebnissen mehr über IEC 62304 und MDR-Dokumentation, als jede Schulung leisten kann — und das Wissen bleibt im Haus. Gleichzeitig trägt niemand das Zertifizierungsrisiko allein.

Für viele unserer Kunden ist das der kleinste sinnvolle Einstieg: kein Großprojekt, keine Umstellung der Entwicklung — sondern eine zweite, erfahrene Instanz, die genau dort hinschaut, wo Projekte scheitern. Absicherung ist am billigsten, bevor man sie braucht.