Als ein deutscher Medizinproduktehersteller die 15 Jahre alte Software seines Kontrastmittelinjektors ersetzen musste, ging es um weit mehr als eine routinemäßige Neuentwicklung. Das Gerät verabreicht Kontrastmittel direkt in Patienten während CT-Untersuchungen – ein Kontext, in dem Softwarefehler keine Option sind.
Abschnitte in diesem Artikel:
Die Herausforderung | Was wir geliefert haben | Teams und Zusammenarbeit | Softwarearchitektur und -design | Technologie-Stack | IEC-62304-Lebenszyklus-Konformität | Praktische technische Rahmenbedingungen | Testen und Validierung | Audit und Aufsicht | Warum das wichtig ist
Projekt im Überblick
| Gerätetyp | Kontrastmittelinjektor für die CT-Bildgebungsdiagnostik |
| Risikoklassifizierung | Klasse C – höchste Risikokategorie nach IEC 62304 |
| Umfang | Vollständige Neuentwicklung der Konsolenanwendung (primäre + sekundäre/Remote-Konsole) |
| Standard | IEC 62304:2015 |
| Dauer | ~ 1.5 Jahre |
| Kunde | Seleon GmbH, Germany |
| Teams | Rumänien (Softwareentwicklung) – Deutschland (Kunde, Koordination) – Republik Moldau (Firmware) |
Sie benötigten eine vollständige Neuentwicklung der Konsolenanwendung innerhalb des formalen IEC 62304-Rahmens für Medizinproduktesoftware der Klasse C. Diese Fallstudie beschreibt, wie die Neuentwicklung umgesetzt wurde, welche Rahmenbedingungen sie prägten und was nötig war, um ein sicherheitskritisches System in jeder Phase auditbereit zu halten.
Die Herausforderung
Ein deutscher Medizinproduktehersteller musste die Software seines Kontrastmittelinjektors vollständig ersetzen – ein Gerät, das in der CT-Bildgebung eingesetzt wird, um Kontrastmittel während diagnostischer Untersuchungen präzise in Patienten zu verabreichen.
Die bestehende Anwendung war über 15 Jahre alt, in C und C++ geschrieben und lief auf veralteten Betriebssystemen und veralteter Hardware. Der Anspruch des Herstellers ging über eine reine Softwareauffrischung hinaus: Parallel wurde der zugrunde liegende Einplatinencomputer auf einen schnelleren Prozessor mit mehr Arbeitsspeicher umgestellt, und die Software musste innerhalb eines formalen IEC 62304-Rahmens – der internationalen Norm für den gesamten Lebenszyklus von Medizinproduktesoftware – von Grund auf neu entwickelt werden.
Team-Einblick Die Ausgangslage war eindeutig: Es handelte sich um ein Gerät der Klasse C, der höchsten Sicherheitsklassifizierung nach IEC 62304. Ein Softwareausfall während eines Eingriffs lässt sich nicht auf die gleiche Weise beheben wie bei einer Desktop-Anwendung. Das fertige System musste architektonisch fundiert, vollständig dokumentiert und nachweislich sicher sein. |
Was wir geliefert haben
RomSoft lieferte die Konsolenanwendung für den Kontrastmittelinjektor – sowohl die primäre Konsole neben dem Gerät als auch eine sekundäre Konsole, die vom Assistenten in einem separaten Raum genutzt wird. Wir waren zudem verantwortlich für die Pflege einer strukturierten und aktuellen Dokumentation gemäß den Anforderungen der IEC 62304 Klasse C während des gesamten Entwicklungszyklus. Die untergeordnete Firmware zur Steuerung von Pumpen, Motoren und Sensoren wurde von einem separaten Drittanbieter-Team entwickelt. Die Software von RomSoft steuerte diese Hardware, führte Injektionsprogramme aus und übernahm Überwachung sowie Fehlermanagement. Das System befindet sich nun in Produktion und im aktiven klinischen Einsatz.
Architektur der Kontrastmittelinjektor-Konsole
Teams und Zusammenarbeit
Das RomSoft-Team umfasste acht Spezialisten: einen Team Lead, einen Architekten, fünf Entwickler und einen Tester. RomSoft stimmte sich direkt mit einem kundenseitigen Team in Deutschland ab – zwei Entwicklern und einem Team Lead/Architekten –, das wiederum ein Partnerteam in der Republik Moldau koordinierte. Die Zusammenarbeit mit Deutschland war eng und kontinuierlich: gemeinsame Reviews, Dokumentation, Anforderungs- und Testbesprechungen. Der Kontakt zum Team in Moldau war informell und diente hauptsächlich dazu, die Firmware-/Hardware-Schnittstelle zu verstehen, die die Software von RomSoft nutzen musste.
| STANDORT | ROLLE |
|---|---|
| Rumänien | Entwicklung der Konsolenanwendung, Dokumentation von Anforderungen und Architektur, Detailentwurf, Prozessführung gemäß IEC 62304 (Reviews, Freigaben) |
| Deutschland | Kunde und Hersteller; Gesamtsystemarchitektur und Anforderungen, Projektmanagementverantwortung, regulatorische Schnittstelle, Tooling/Validierung/Versionskontrolle, teamübergreifende Koordination |
| Republik Moldau | Partnerteam, Firmware-Entwicklung (Low-Level-Software zur Steuerung von Pumpen, Motoren, Sensoren) |
Eine wichtige Rolle innerhalb des RomSoft-Teams war die Verantwortung für das Requirements-Engineering-Management – die Definition und Pflege der Anforderungen, der Beitrag zur detaillierten Entwurfsdokumentation sowie die Sicherstellung, dass der Prozess selbst im Tagesgeschäft eingehalten wurde: dass Reviews in der richtigen Reihenfolge stattfanden, Dokumente verfasst, überarbeitet und freigegeben wurden und das Team bei der IEC 62304-Dokumentationspflicht diszipliniert blieb.
Die Rolle des Gesamtsystem-Architekten/Projektleiters für das gesamte Gerät lag beim deutschen Team Lead/Architekten, der auch das Team in der Republik Moldau koordinierte.
Softwarearchitektur und -design
Die Architektur wurde für einen deterministischen, ausfallsicheren Betrieb konzipiert. Angesichts der Rolle des Geräts bei tatsächlichen Patienteneingriffen wurde die Software so entwickelt, dass Hardwarezustände – Pumpenverhalten, Fehlerbedingungen, Display-Interaktionen, Injektorsteuerungen – ohne Mehrdeutigkeit in den Fehlermodi verarbeitet werden.
Die Benutzeroberfläche lief auf einer Touchscreen-Konsole, die auf einem speziell gehärteten Windows-IoT-Image basierte. Aus Sicherheitsgründen waren die Anschlüsse deaktiviert, sodass keine Peripheriegeräte angeschlossen werden konnten (USB-Speicher, Maus usw.). Unterhalb der Konsole befand sich die Injektorhardware sowie die Firmware, die sie direkt steuerte.
Technologie-Stack
- Programmiersprache: C#, WPF
- Technologie-Frameworks: .Net 4.5, WPF, AutoFac, MSTest, Entity Framework, CanOpen
- Kommunikationsprotokolle: RS 232, RS 485, CiA 425
- Betriebssystem: Windows 10 IoT
- Geräteprozessor: Intel Core i5/Quad core
- CI/CD: TeamCity
- Anforderungs- und Fehlerverfolgung: Polarion, Jira
- Architekturentwurf: Enterprise Architect 13
Die Hauptanwendung lief auf einem Einplatinencomputersystem. Dies ermöglichte dem Team den Einsatz einer ausgereiften, ausdrucksstarken Sprache mit dem für das Gerät erforderlichen Embedded-Performance-Profil, ohne dabei auf Open-Source-Bibliotheken angewiesen zu sein, die die regulatorischen Nachverfolgbarkeitsanforderungen nicht erfüllt hätten.
IEC-62304-Lebenszyklus-Konformität
Jede Entwicklungsphase wurde gemäß den Anforderungen der IEC 62304:2015 Klasse C durchgeführt und dokumentiert, nach einem Wasserfallprozess mit klar abgegrenzten Verantwortlichkeiten, Terminen und Ergebnissen in jeder Phase:
- Entwicklungsplanung: Dokumentation der Lebenszyklusaktivitäten, Rollen und Ergebnisse auf Projektebene
- Anforderungsanalyse: vollständige Rückverfolgbarkeit von Systemanforderungen zu Softwareanforderungen
- Architekturentwurf: dokumentierte Zerlegung der Softwarekomponenten und ihrer Schnittstellen
- Detailentwurf: Design-Dokumentation auf Einheitenebene für jede Softwareeinheit
- Einheitenimplementierung und -verifizierung: Code-Review und Unit-Tests mit dokumentierten Ergebnissen
- Integration und Integrationstests: schrittweise Integration mit vollständiger Testdokumentation
- Systemtests: durchgängige Validierung gegenüber den Anforderungen
- Freigabe: formale Freigabedokumentation und Versionskontrollartefakte
Die Gesamtsystemarchitektur und die ursprünglichen Anforderungen wurden größtenteils vor Beginn der Implementierungsphase festgelegt. Der Beitrag von RomSoft bestand darin, diese Grundlage zu verfeinern, zu aktualisieren und umzusetzen. Da der Prozess im Wasserfallmodell von Anfang an sorgfältig geplant war, verlief die Lieferung mit wenigen Überraschungen – Änderungen beschränkten sich auf kleinere, schrittweise Anpassungen von Architektur und Anforderungen im Projektverlauf, nicht auf grundlegende Neugestaltungen aufgrund unvorhergesehener Risikoerkenntnisse.
⚠ KLASSE C Das Projekt unterlag der IEC 62304 – Klasse C, die für Software gilt, bei der ein Ausfall oder eine Fehlfunktion zu schweren Verletzungen oder zum Tod führen könnte. Jede Lebenszyklusaktivität – Anforderungen, Architektur, Einheitenimplementierung, Integration, Tests und Wartung – muss vollständig dokumentiert und rückverfolgbar sein. Zusätzlich angewandter Standard: ISO 14971 – definiert das Risikomanagement von Medizinprodukten über deren gesamten Lebenszyklus. |
Tooling, Validierung und Versionskontrolle lagen in der Verantwortung des Kundenteams in Deutschland. Innerhalb des eigenen Liefer-Teams von RomSoft wurden einige agile Praktiken – insbesondere tägliche Stand-ups – zusätzlich zur Wasserfall-Governance eingesetzt, um die tägliche Arbeit koordiniert zu halten.
Praktische technische Rahmenbedingungen
Über den regulatorischen Rahmen hinaus gab es einige praktische technische Rahmenbedingungen, die das Projekt prägten und unser Team dazu zwangen, sich an die Gegebenheiten vor Ort anzupassen:
- UI-Parität: Der Kunde verlangte, dass die neue Anwendung die bestehende grafische Oberfläche eins zu eins nachbildet. Jede Abweichung hätte eine Neuzertifizierung sowie eine Nachschulung des klinischen Personals ausgelöst, das das System bedient. Der gestalterische Spielraum für das Frontend war somit von Anfang an festgelegt und keine typisch offene UX-Fragestellung.
- Bestehende Laborinfrastruktur: Leistungsfähigere Kommunikationsprotokolle wären technisch verfügbar gewesen, doch die Verkabelung zwischen dem Patientenraum und dem Kontrollraum des Assistenten konnte nicht ohne Weiteres ersetzt werden – eine Entscheidung, die bei der medizinischen Einrichtung und nicht beim Hersteller lag. Die Software musste über die bestehende LAN/TCP-Verkabelung zuverlässig funktionieren.
- Zwei-Konsolen-Architektur mit Spiegelung: Da das Personal den Patientenraum während des Eingriffs nicht betreten durfte, verfügte das System über eine primäre Konsole neben dem Gerät und eine sekundäre Konsole im Raum des Assistenten. Beide führten eine gespiegelte Version der Anwendung aus und mussten über dieselbe bestehende Verkabelung in Echtzeit synchron bleiben, sodass der Assistent zusätzliche Kontrastmittelinjektionen aus der Ferne auslösen konnte, während er den CT-Feed beobachtete.
Team-Einblick Bei Medizinsoftware der Klasse C ist ein Framework- oder Abhängigkeits-Update kein routinemäßiger Wartungsvorgang. Es kann eine Änderung darstellen, die umfangreich genug ist, um eine Neuvalidierung des gesamten Systems auszulösen. Das Team verwaltete den Software-Stack unter der Designvorgabe langfristiger Stabilität und dokumentierte die Begründung für alle Entscheidungen zu Drittkomponenten sowie deren regulatorische Auswirkungen. |
Testen und Validierung
Die Tests umfassten sowohl Simulatorumgebungen als auch physische Gerätetests – Letztere mit direkter Interaktion mit der Injektorhardware zur Validierung realer Grenzfälle.
Team-Einblick An einem Punkt deckte die Risikoanalyse ein Szenario auf, das das Team ursprünglich nicht eingeplant hatte: Daten von einem externen Gerät konnten unvollständig, fehlerhaft oder im falschen Format eintreffen. Die Funktion selbst hätte gemäß den ursprünglichen Anforderungen funktioniert. Glücklicherweise ergab die formale Risikoprüfung, dass die Verarbeitung fehlerhafter Daten zu falschen Ergebnissen in der weiteren Kette führen könnte. Dieser einzelne Befund führte zu einer Reihe von Risikokontrollmaßnahmen: Eingabevalidierung, Prüfungen der Nachrichtenintegrität, explizite Fehlerbehandlung und Warnmeldungen, wenn etwas nicht stimmte. Daraufhin wurden Anforderungen, Tests und Verifizierungsunterlagen aktualisiert, um deren Wirksamkeit nachzuweisen. Dies ist ein gutes Beispiel dafür, wie der Prozess ein reales Risiko bereits in der Entwurfsphase aufdeckte – lange bevor es sich bei der Integration oder, schlimmer noch, im Feldeinsatz hätte zeigen können. |
Alle Testergebnisse wurden als formale Aufzeichnungen im Rahmen des IEC-62304-Lebenszyklus dokumentiert. Seit der Inbetriebnahme wurden RomSoft keine kritischen Softwareprobleme gemeldet, und das System befindet sich weiterhin im aktiven klinischen Einsatz.
Audit und Aufsicht
RomSoft wurde als externes Partnerunternehmen während des gesamten Projekts direkt vom Kunden auditiert – der Kunde hält die regulatorische Zertifizierung des Geräts und ist selbst dafür verantwortlich, die Anforderungen der benannten Stelle zu erfüllen.
Warum das wichtig ist
Software für Medizinprodukte der Klasse C gehört zu den anspruchsvollsten technischen Umgebungen in regulierten Branchen. Die Folgen eines Softwareausfalls während einer aktiven CT-Untersuchung, bei der einem Patienten Kontrastmittel verabreicht wird, lassen keinen Spielraum für Mehrdeutigkeit in Design, Tests oder Dokumentation.
Die erfolgreiche Umsetzung dieses Projekts erforderte mehr als reine Softwareentwicklungskompetenz. Sie erforderte ein Team, das wusste, wie man innerhalb eines formalen Sicherheits-Lebenszyklus arbeitet, in jeder Phase auditbereite Dokumentation erstellt und technische Entscheidungen unter Berücksichtigung langfristiger regulatorischer Auswirkungen trifft.
RomSoft übernahm dies als primäres Entwicklungsteam, das für die Konsolenanwendung verantwortlich war.
Auf der Suche nach einem Partner, der Compliance als Ingenieursaufgabe versteht?Wir suchen MedTech-Unternehmen und angrenzende Firmen, die Software entwickeln oder pflegen, bei der regulatorische Konformität strukturell verankert ist – fest eingebettet in Architektur, Lebenszyklus und Teamkultur. Wenn Ihre Situation eines der folgenden Merkmale aufweist, sollten wir sprechen:
Kontakt aufnehmen: office@rms.ro |