Ihr Softwareteam für die Medizintechnik

Vernetzter Sensor mit Patienten-App und Dashboard für medizinisches Fachpersonal

Ein Unternehmen für digitale Gesundheit baut ein Fernüberwachungssystem aus Sensor, mobiler App für Patienten und Web-Dashboard für Klinikpersonal, als Medizinprodukt, je nach Zweckbestimmung (was der Hersteller als Verwendung der Software angibt) zum Beispiel der Klasse IIa oder IIb nach der EU MDR (Anhang VIII, Regeln 10 und 11) und der Klasse II für die FDA.

Ein Entwicklungsplan deckt die Firmware, die App, das Cloud-Backend und das Dashboard ab. Das Softwaresystem erhält seine Software-Sicherheitsklasse (A, B oder C, je nach Schaden, den ein Softwarefehler verursachen könnte) aus den Gefährdungen, zu denen es beitragen kann. In der Architektur getrennte Software-Elemente können eine niedrigere Klasse tragen, wenn die Trennung verifiziert und die Begründung festgehalten ist. Bluetooth-Verbindung, Datenfluss und Cloud-Grenze liegen in einem Threat Model (eine strukturierte Analyse, wie das Gerät angegriffen werden könnte), und die Arbeit zur Gebrauchstauglichkeit umfasst Patienten und Klinikpersonal.

Wir beginnen bereits im ersten Sprint mit der Verifizierung. Die Nachweise dienen anschließend als Grundlage für die technische Dokumentation und die FDA-Einreichung.

Bereits eingesetzte Software nachträglich dokumentieren und weiterentwickeln

Eine App, ein Cloud-Backend und ein Dashboard sind bereits im Einsatz, bislang jedoch außerhalb des Geltungsbereichs der MDR. Nun sollen sie als Medizinprodukt weitergeführt werden. Dafür muss zunächst die erforderliche Softwaredokumentation entstehen, bevor die Weiterentwicklung nach MDR-Anforderungen fortgesetzt werden kann.

Zuerst bestätigen wir die Zweckbestimmung, die Einstufung als Medizinprodukt und die Klasse. Eine Gap-Analyse (eine Prüfung, was gegenüber der Norm fehlt) dokumentiert dann das Produkt, wie es heute läuft. Aufzeichnungen, die nie erstellt wurden, werden nicht rückdatiert: Die Lücken schließen wir mit neuer Risikoanalyse und neuer Verifizierung, und die Neuentwicklung folgt dem Lebenszyklus, sodass jede neue Funktion mit Anforderung, Risikobewertung und Tests entsteht.

Startup mit Prototyp und abgeschlossener Finanzierungsrunde

Ein Medizintechnik-Startup hat die Finanzierung gesichert und verfügt über einen funktionsfähigen Prototyp. Diesen hat ein externer Entwickler oder einer der Gründer programmiert. Nun muss daraus Software entstehen, die sich für eine erste Einreichung nach EU MDR oder bei der FDA eignet.

Mit einer Gap-Analyse prüfen wir den Programmcode des Prototyps. Für jedes Softwareelement entscheiden wir, ob wir es übernehmen, überarbeiten oder neu entwickeln. Wir beginnen mit Entwicklungsplan, Sicherheitsklassifizierung und Risikoanalyse. Danach führen wir die Entwicklung bis zur Einreichung fort.

Medizinisches Instrument mit Firmware und klinischer PC-Anwendung

Ein medizinisches Instrument der Klasse IIb verfügt über Firmware zur Hardwaresteuerung und eine PC-Anwendung für medizinisches Fachpersonal. Beide Softwareteile müssen wir gemeinsam entwickeln und als Bestandteile desselben Geräts dokumentieren.

Eine Architektur deckt beides ab. Das System erhält seine Software-Sicherheitsklasse aus den Gefährdungen, und die Firmware oder die Anwendung kann nur dort eine niedrigere Klasse tragen, wo die Trennung es begründet. Die Schnittstelle zwischen beiden wird als Schnittstellenanforderung spezifiziert, in identifizierten Software-Elementen umgesetzt und im Integrationstest verifiziert. Die Verifizierung beider Teile fließt in eine Rückverfolgbarkeitsmatrix (eine Tabelle, die jede Anforderung mit Design, Tests und Risikobeherrschungsmaßnahmen verknüpft) und in ein Release.