Wie bei der bekannten Technik der Nierendialyse geht es bei der Leberdialyse darum, die Funktion eines beschädigten Organs durch ein externes Gerät zu ersetzen. Wie die Niere reinigt auch die Leber das Blut, leider muss hierbei teures Humanalbumin verwendet werden. Ein neues Aufreinigungsverfahren erlaubt einen vollständigen funktionalen Ersatz der Leber über einen längeren Zeitraum, ohne dass ständig das teure Humanalbumin erneuert werden muss. Für eine Zulassung ist eine Programmierung und Dokumentation gemäß DIN EN 62304 erforderlich, wobei Standard-Tools und modulare Rechnerplattformen zum Einsatz kommen.
Anders als die Niere kann die Leber sich sehr gut regenerieren, sodass bei einer kurzfristigen Vergiftung die Chance besteht, durch die Überbrückung mit der Leberdialyse den Patienten wieder gesund zu entlassen.
Die Funktionsweise dieses Verfahrens zeigt Bild 1.
Auf den ersten Blick ist zu erkennen, dass für die Funktion dieses Gerätes sehr hohe Sicherheitsanforderungen bestehen.
Sicherheitsrelevante Aspekte sind international einheitlich in drei Klassen unterteilt, in Europa ist die relevante Norm DIN EN 62304. Diese Klassen sind:
Frühe Versionen der Entwicklungsumgebung »Labview« von National Instruments wurden immer mit einem deutlichen Hinweis ausgeliefert, dass dieses Werkzeug nicht für die Programmierung von Systemen geeignet ist, die Menschen gefährden können. Das gilt bis heute für jede Art von Windows-Software, unabhängig davon, mit welchem Werkzeug sie erstellt wurde.
Nachdem Leberdialyse offensichtlich zur Klasse »C« gehört, da bei einer Fehlfunktion der Patienten erheblich geschädigt wird, sieht es auf den ersten Blick so aus, als ob die Aufgabe mit Labview nicht zu lösen wäre. An dieser Stelle hilft ein Trick. Externe redundante Überwachungssysteme und ein Dialysegerät, für das eine Zulassung besteht, überwachen die wichtigsten Parameter:
Verschiedene Prototypen
Für den Aufbau der Prototypen wurde die »CompactRIO«-Plattform (cRIO) gewählt, weil das modulare System es ermöglicht, eine Vielzahl von unterschiedlichen Signaltypen zu verarbeiten und jederzeit weitere Module hinzuzufügen (Bild 2).
Eingesetzt wurde der Controller »cRIO-9024« mit »VxWorks« als Betriebssystem, einem 800-MHz-Prozessor, 512 MByte RAM und 4 GByte Flash-Speicher. Die Backplane »cRIO-9118« hat Steckplätze für bis zu acht Module.
Bild 3 zeigt, dass diese Steckplätze vollständig ausgenutzt werden. Die Software besteht aus drei Teilen: einer Windows-Applikation, die ausschließlich als Bedienoberfläche und Visualisierung dient und nicht in die Regelung eingreifen kann, einem »Labview RT«-Programm, das im cRIO-Controller läuft und die Regelung ausführt, sowie einem FPGA-Code, der Ausgabewerte des Controllers in PWM-Signale umsetzt (Bild 4, siehe auch Tabelle 1).
Tool/Umgebung | »A« | »B« | »C« | Stromverbrauch |
---|---|---|---|---|
Windows, Labview auf Windows |
Ja |
NEIN |
NEIN |
5 µA |
Labview RT auf VxWorks | Ja | Ja | NEIN | 0,7 mA |
Labview FPGA | Ja | Ja | (1) | 5 mA |
Mechanischer Schutz, SPS |
Ja |
Ja |
Ja |
Tabelle 1: Zertifizierungsmöglichkeiten nach DIN EN 62304 (1). Eine Zertifizierung für die höchste Schutzklasse »C« für FPGA-Code ist nicht grundsätzlich ausgeschlossen, aber an verschiedene Bedingungen geknüpft. Die Verifikation erfolgt dann nicht nur auf dem Labview-Quellcode, sondern auch mit dem als Zwischenstufe erzeugten VHDL-Code.
Um ein Chance zu haben, Programmcode zu zertifizieren, ist eine sehr ordentliche Gliederung in sogenannte »Units« und »Items« erforderlich. Da diese Unterteilung sich in der Dokumentation und in den erforderlichen Testwerkzeugen niederschlägt, ist es hier sehr wichtig, genau abzuwägen, wie man sein System unterteilen kann und will. Insbesondere ist darauf zu achten, dass die Labview-Diagramme übersichtlich und nicht zu groß werden und die zuvor gewählte Struktur klar abbilden.
In Bild 5 sind oben im Code gestrichelte Linien zu sehen, also Objektreferenzen. Die objekt-orientierte Programmierung ist auch im RT-System möglich, sie wird hier nicht verwendet, um von Vererbung oder ähnlichen Mechanismen zu profitieren, sondern nur, weil sich auf diese Weise große Cluster mit Daten transferieren lassen, ohne das Frontpanel so weit »aufzublasen«, dass das Editieren sehr langsam wird.
Vom Schwein zum Mensch
Die Erprobung des Gerätes begann mit Tierversuchen an Schweinen, deren Organe dem Menschen sehr ähnlich sind, und wurde dann nach Bestehen der erforderlichen Abnahmen unter ärztlicher Aufsicht in einer Klinik an Menschen fortgeführt (Bild 6). Die Ergebnisse dieser Versuche haben dazu geführt, dass nun mit dem Bau von Seriengeräten begonnen wird.
Für die Seriengeräte kommt das Single-Board-RIO »sbRIO-9612« zum Einsatz. Dieses System verfügt über wesentlich weniger Rechenleistung (400 MHz, 400 MByte RAM, 256 MByte Flash), kann dafür aber 110 digitale Leitungen extrem schnell direkt aus dem FPGA heraus ansprechen. Bei der Portierung der Software können große Teile übernommen werden, sodass auch die bereits vorhandene Dokumentation nicht komplett neu zu erstellen ist.
Für die Seriengeräte ist auch eine CE-Zertifizierung erforderlich. Mit Hilfe der Labview-Werkzeuge ließ sich die Entwicklung der Prototypen in einer Zeit realisieren, die erheblich unter dem kalkulierten Rahmen geblieben ist. Durch die Zulassung des TÜV Süd und dem erfolgreichen Abschluss der Tests an Tieren und Menschen wurde nachgewiesen, dass dieses Verfahren nicht nur funktioniert, sondern auch den strengsten Abnahmekriterien der Medizintechnik genügt.
Hepa Wash konnte mit diesem Prototyp das »Proof of Concept« des Verfahrens am Menschen erreichen. Für die schnelle Realisierung der Prototypen war die Flexibilität des modularen cRIO-Systems wichtig, für den Aufbau der Seriengeräte ist die sbRIO-Plattform mit preiswerten Systemen geeignet. Es besteht eine realistische Chance, mit der FPGA-Programmierung auch eine Zertifizierung als »Klasse C«-System zu erreichen.
Über die Autoren:
Holger Chap ist CTO von Hepa Wash, Andreas Zimmer ist Geschäftsführer von XOn Software.