Projektentwicklung mit klar vereinbarten Ergebnissen

Software eines Laborgeräts an einem Universitätsklinikum verifizieren

Ein europäisches Universitätsklinikum hat für eine Studie unter einer FDA IDE ein Laborgerät entwickelt. Die Software funktioniert bereits. Sie besteht aus einer Python-Anwendung auf einem PC und MicroPython-Firmware auf einem ESP32. Es fehlen jedoch Tests und Aufzeichnungen nach IEC 62304.

Ein Projekt mit definiertem Umfang, zwei Ingenieuren und einem Projektleiter, die remote mit dem Team des Krankenhauses arbeiten. Es umfasst ein Code-Review beider Teile, ein Refactoring der PC-Anwendung für die Testbarkeit, automatisierte Tests sowie die Benutzer- und Softwareanforderungen, die Validierungs- und Verifizierungspläne, den Testbericht und die Rückverfolgbarkeitsmatrix (eine Tabelle, die jede Anforderung mit Design, Tests und Risikobeherrschungsmaßnahmen verknüpft).

Firmware eines Herzgeräts der höchsten Risikoklasse überarbeiten

Ein kardiologisches Therapiesystem gehört sowohl nach EU MDR als auch bei der FDA zur Klasse III. Es umfasst eine Steuerkonsole und eine Sonde mit zwei STM32-Mikrocontrollern. Vor den nächsten regulatorischen Schritten muss die Firmware wieder mit ihrer Designspezifikation übereinstimmen.

Die Arbeit beginnt mit einer Gap-Analyse der Designspezifikation gegen den Code (ein Abgleich mit dem, was nach der Norm fehlt), einer Prüfung nach MISRA C und SOUP und einem Workshop vor Ort. SOUP steht für Software unbekannter Herkunft, also Code von Dritten im Produkt. Die Behebung läuft danach in schriftlich vereinbarten Phasen: Bereinigung, kritische Korrekturen, schwerwiegende Fehler und Unit-Tests, jede Phase mit eigener Abnahme durch das Qualitätsteam des Kunden. Jede Korrektur durchläuft die Change Control des Kunden mit einer Auswirkungsanalyse. Die Software-Sicherheitsklassifizierung, die Verifizierung auf Systemebene und die Freigabeentscheidung bleiben beim Kunden.

FDA-Softwaredokumentation für ein fertiges nRF52-Gerät erstellen

Ein Ingenieurbüro braucht die FDA-Softwaredokumentation für das batteriebetriebene Gerät eines Kunden auf Basis eines Nordic nRF52 mit Zephyr und BLE (Bluetooth Low Energy), bei bereits fertiger Firmware.

Ein Dokumentationsprojekt, das mit einer Gap-Analyse (eine Prüfung, was gegenüber der Norm fehlt) der vorhandenen Nachweise beginnt und aus dem Code und den Vorlagen des Kunden geschrieben wird. Wo Anforderungen oder Testnachweise fehlen, wird die fehlende Verifizierung mit dem Kunden als gesonderte Arbeit vereinbart. Die Dokumente sind: Software Design Specification, SOUP-Bewertung, Systemtestspezifikation, Cybersicherheitsbericht, Threat Model (eine strukturierte Analyse, wie das Gerät angegriffen werden könnte), SBOM (Software Bill of Materials, die Liste aller Softwarekomponenten im Build) und die Firmware-Updates zur Gefährdungsanalyse, mit Blick auf die Erwartungen von IEC 62304, ISO 14971 und FDA Abschnitt 524B.

Ein etabliertes Bildarchiv von Win32 und MFC lösen

Eine Software zur Bildarchivierung und Befundung basiert auf C++ und MFC. Sie nutzt DCMTK für DICOM und PostgreSQL als Datenbank. Das System ist an Ultraschall-, Endoskopie-, CT-, MR- und Röntgengeräte angebunden. Während der Modernisierung muss das Produkt unter ISO 13485 und der MDR auf dem Markt bleiben.

Wir teilen die Modernisierung in klar abgegrenzte Projekte auf. Zuerst erneuern wir die Benutzeroberfläche und die Komponente zur Dokumentenerstellung. DICOM-Backend und Datenbank bleiben erhalten. Vor jedem Release verifizieren wir, ob das bisherige Verhalten erhalten bleibt. Eine Aufnahme-App derselben Produktfamilie stellen wir außerdem von spezieller Kamerahardware auf Android-Standardgeräte mit CameraX um.

Eine Engine für dentale Bildverarbeitung hinter einer API

Eine Plattform für die Planung von Zahnimplantaten braucht eine Engine, die CBCT-Volumen segmentiert, intraorale STL-Scans importiert und die zwei registriert. Über eine API gibt sie Meshes, die Transformation und eine Genauigkeitsangabe zurück.

Das Projekt beginnt mit einer Machbarkeitsphase an anonymisierten Fällen des Kunden und endet in einer funktionierenden Pipeline mit ITK und VTK, einem Bericht zur gemessenen Genauigkeit sowie einer Architektur und einem Regulatory-Plan für ein Produkt der Klasse IIa, wobei die Klassifizierung nach MDR Regel 11 aus der Zweckbestimmung (was der Hersteller als Verwendung der Software angibt) abgeleitet wird. Die Produktions-Engine folgt als zweites Projekt.

Ein Spenderprogramm auf mehrere Länder ausweiten

Eine Zell- und Gewebebank weitet ihr Spenderprogramm auf mehrere Länder aus und braucht ein Backoffice-System mit einer Zwei-Wege-API zu einem Webshop. Dazu kommen Bestand und Buchung in Echtzeit sowie Kontingente pro Land.

Wir teilen das Vorhaben in drei Teile auf: Backoffice-System, Webshop auf einer Standardplattform und Integration beider Systeme. Für jeden Teil vereinbaren wir eigene Ergebnisse und erstellen eine eigene Aufwandsschätzung.