AereA GmbH
Projekt besprechen

Projektbericht: Medizintechnik

Bedienoberflächen für ein medizintechnisches Lasersystem

Im regulierten Umfeld ist die Dokumentation kein Nebenprodukt der Entwicklung, sondern ein Teil des Produkts.

Branche
Medizintechnik, zulassungsrelevantes Umfeld
Systemtyp
Bedienoberflächen eines Lasersystems
Rolle von AereA
Entwicklung, Test, Dokumentation, Code Reviews
Zeitraum
über 4 Jahre

Ausgangslage

Planungs- und Behandlungsoberflächen eines Lasersystems, die nicht nur funktionieren, sondern ihre Funktion nachweisen müssen.

Lösungsansatz

Entwicklung in C++ und Qt, Erweiterung der zugehörigen Test-Tools, Unit-Tests, Code Reviews und durchgängige Testdokumentation in einer regulierten Toolchain.

Ergebnis

Über 4 Jahre begleitete Entwicklung mit über 4.000 dokumentierten Testfällen - inklusive sicherheitskritischer Updates im zugelassenen Bestand.

Ergebnisse auf einen Blick

  • Über 4 Jahre Begleitung des Produkts im zulassungsrelevanten Umfeld
  • Über 4.000 dokumentierte Testfälle mit Rückverfolgbarkeit bis auf die Anforderung
  • Entwicklung der Planungs- und Behandlungsoberflächen in C++ und Qt
  • Erweiterung der projektspezifischen Test-Tools - Testinfrastruktur als eigenes Arbeitsergebnis
  • Sicherheitskritische Updates im zugelassenen Bestand, jeweils mit eigenem Nachweisverfahren
  • Umsetzung von Cyber-Security-Anforderungen als Teil der regulatorischen Betrachtung

Ausgangslage

Ein Lasersystem im medizinischen Einsatz wird über die Bedienoberfläche geplant und gesteuert. Diese Oberfläche ist damit kein Frontend, sondern ein sicherheitsrelevanter Teil des Geräts.

Aufgabenstellung

Entwicklung, Test und Dokumentation der Planungs- und Behandlungsoberflächen, dazu die Erweiterung der zugehörigen Test-Tools und die Umsetzung sicherheitskritischer Updates im laufenden Produktlebenszyklus.

Vorgehen im regulierten Umfeld

Anforderungen liegen in DOORS, Reviews laufen über Fisheye/Crucible, Builds über Jenkins, Versionierung über SVN. Die Toolchain ist Teil der Nachweisführung: Änderungen sind bis auf die Anforderung zurückverfolgbar.

Entwickelt wurde in C++ mit Qt und Boost, gebaut über CMake, ergänzt um Python für die Test-Tools.

Qualitätssicherung

Unit-Tests und Code Reviews waren fester Bestandteil des Vorgehens, nicht optionale Ergänzung. Dazu kam die Erweiterung der projektspezifischen Test-Tools - in regulierten Umgebungen ist Testinfrastruktur selbst ein Arbeitsergebnis.

Cyber-Security

Anforderungen an Absicherung und Schwachstellenbehandlung sind Teil der regulatorischen Betrachtung geworden. Ihre Umsetzung gehörte zum Auftrag.

Fazit

Dieses Projekt ist unsere Referenz dafür, dass Nachweisführung und Entwicklungsgeschwindigkeit sich nicht ausschließen, wenn Testdokumentation von Anfang an mitläuft statt am Ende nachgezogen zu werden.

Technologien

  • C++
  • Python
  • Qt
  • Boost
  • CMake
  • Jenkins
  • DOORS
  • Fisheye/Crucible
  • SVN

Häufige Fragen

Haben Sie die Zulassung verantwortet?

Nein. Wir haben Entwicklung, Test und Dokumentation in der Form geliefert, die das Qualitätsmanagement des Herstellers für die Zulassung benötigt. Das Verfahren selbst liegt beim Hersteller.

Was bedeutet ein sicherheitskritisches Update hier?

Ein Vorgang mit eigenem Verfahren: Änderungsbewertung, Nachweisführung, Test gegen die spezifizierten Anforderungen und dokumentierte Freigabe - kein Deployment.

Kontakt

Ansprechpartner

Franziska Sprenger
Qualitätssicherung, Testmanagement & Unternehmensleitung

Wüstenstein 18, 91346 Wiesenttal · Mo-Fr 9:00-18:00 Uhr