Um Medizingeräte in einem medizinische Ökosystem aufzunehmen, müssten diese kommunizieren können. Dafür rüsten Hersteller ihre Geräte mit Connectivity-Funktionen auf. Allen voran sind Funktionen wie Over-the-Air-Updates, Fernmessungen und Remote-Alarmierung im Fokus des Retrofit. Wer die Modernisierung ohne sorgfältige Planung vorantreibt, riskiert dabei Nachteile durch eine erforderliche Rezertifizierung. Doch das muss nicht sein. Hier ein Überblick, wie Sie Innovationen strategisch planen und umsetzen, um Kosten und Time-to-Market gering zu halten.
Wenn Medizingeräte ihre Daten nur analog ausgeben, wie etwa die EKG-Kurven auf dem Papierstreifen, oder die Untersuchungsergebnisse nur manuell heruntergeladen werden können, dann ist das nicht mehr zeitgemäß. Die Digitalisierung im Gesundheitswesen schreitet unaufhaltsam voran. Denn Kostendruck und Personalmangel zwingen Kliniken, Pflegeheime und Praxen dazu, ihre Prozesse von unnötigen manuellen Handgriffen zu entschlacken und die Abläufe zu beschleunigen. Die größten Hebel auf diesem Weg sind Automatisierung und Vernetzung der Geräte.
Ungehinderte, aber sichere Datenübertragung, Bedienung aus der Ferne und eine automatische Alarmierung, wenn beim Monitoring von Vitaldaten Grenzwerte überschritten oder sonstige Gefährliche Zustände erkannt werden, gehören daher zu den wichtigsten Funktionen einer zeitgemäßen medizinischen Infrastruktur. Die Anbieter von MedTech stehen unter Druck, ihre Produkte an diese Anforderungen anzupassen und Schnittstellen zur Datenübertragung nachzurüsten, wo diese bislang fehlen.
Regulatorische Anforderungen und Hürden
Technisch gesehen kann die Integration von bidirektionalen Kommunikationsschnittstellen als bewältigbare Aufgabe gelten. Die wirklichen Herausforderungen liegen eher im Bereich der regulatorischen Vorgaben. Angesichts eines zunehmenden Software-Anteils moderner Medizingeräte verlangt die EU-Medizinprodukteverordnung (MDR 2017/745) beispielsweise ein Post-Market-Surveillance-System, das die Verantwortung für Softwarefehler und Sicherheitslücken fortlaufend adressiert.
Die Mechanismen zum Verteilen von Updates und Patches gelten dabei selbst als sicherheitsrelevanter Bestandteil der Geräteentwicklung. Mit Standards wie ISO 13485 (Qualitätsmanagement), ISO 14971 (Risikomanagement) und IEC 62304 (Software-Lebenszyklus) sind Gerätehersteller angehalten, Softwareänderungen und Sicherheitsupdates systematisch, nachvollziehbar und sicher zu verteilen.
Bei der Integration der OTA-Updatefunktion müssen sich Hersteller bewusst sein, dass unter Umständen die bestehende Konformitätsbewertung (CE) ihre Gültigkeit verlieren und eine Neubewertung erforderlich machen kann, wenn diese als „wesentliche Änderung“ gewertet wird. Die Neubewertung durch eine Benannte Stelle bedeutet einen zeitlichen Mehraufwand von 6 bis18 Monaten, verbunden mit erheblichen Kosten. Wer zusammen mit der nachgerüsteten Vernetzung bewusst einen Innovationssprung vollziehen will, kann die Folgen einer nötigen Rezertifizierung nicht vermeiden. Wer jedoch nur eine Anpassung an die neuen Anforderungen einer zeitgemäßen Medizin-Infrastruktur erreichen will, muss die Entscheidung über Entwicklungsziele und -umfang dagegen gründlich vorbereiten, um unnötige Zertifizierungsaufwände zu vermeiden.
Die „richtige“ Dosis Innovation
Anhand einer selbst durchgeführten Impact-Analyse können verschiedene Alternativen darauf überprüft werden, ob sie eine Rezertifizierung zwingend nach sich ziehen. Dafür gilt es, in Bezug auf die geplanten Veränderungen drei Kernfragen zu beantworten:
- Ändert sich die Zweckbestimmung?
- Ändert sich die Risiko- oder Softwareklasse?
- Entsteht ein neues klinisches Risiko?
Die Antworten liefern Aufschluss darüber, welcher Aufwand für den (erneuten) Marktzugang betrieben werden muss. Nur wenn eine dieser Fragen mit „Ja“ beantwortet wird, ist eine Rezertifizierung wahrscheinlich.
Hier ein paar typische Beispiele im Überblick:
Gerätehersteller, die auf der sicheren Seite sein und eine Rezertifizierung vermeiden wollen, sollten also bei der Modernisierung einige Grundsätze beachten, die vom Entwicklungsteam zu befolgen sind:
- Zweckbestimmung wahren: Das OTA-Update darf keine Funktion einführen, die die medizinische Zweckbestimmung verändert.
- Risikoprofil beibehalten: Jede Änderung muss nach ISO 14971 auf ihre Risikowirkung geprüft werden.
- Softwaretests nach IEC 62304: Regressionstests sind Pflicht, um unbeabsichtigte Nebeneffekte zu vermeiden.
- Cybersecurity sicherstellen: Updates müssen signiert, verschlüsselt und rückverfolgbar sein.
- Transparente Dokumentation: Änderungen müssen ins Qualitätsmanagementsystem (QMS) eingebunden werden – auch, wenn keine Rezertifizierung nötig ist.
Hier der Ausschnitt unseres Quick-Check-Formulars, mit der Sie selbst eine einfache Impact-Analyse erstellen und die nötigen Schritte ableiten können. Das vollständige Dokument ist Teil des ergänzenden Whitepapers.
Use-Case: OTA-Updates für ein EKG-Gerät
Wie sich dies in der Praxis auswirkt, soll am Beispiel eines EKG-Gerätes dargestellt werden, das bislang nicht über eine moderne Connectivity verfügt. Dieses soll fit gemacht werden für automatisierte Updates über eine drahtlose Kommunikationsschnittstelle (Over-the-Air-Updates, OTA). Dabei gilt es, eine ganze Reihe regulatorischer Anforderungen in Bezug auf die Sicherheit der Daten bzw. der Kommunikation zu beachten. Diese reichen auch weit über das eigene Gerät hinaus:
- Update-Server (Cloud): Es muss die Integrität und Authentizität jedes Updates durch eine sichere Signatur nachgewiesen werden. Ein strenges Änderungs- und Release-Management sowie die Dokumentation für die Technische Dokumentation (MDR) sind verpflichtend, da Updates die Sicherheit und Verwendbarkeit des Geräts direkt beeinflussen.
- OTA-Kanal (von der Cloud zum Gerät): Die Übertragung muss Ende-zu-Ende verschlüsselt und authentifiziert sein. Es muss nachgewiesen werden, dass Übertragungsfehler (durch Netzwerk-Failover, Retry-Mechanismen und Transaktionslogs) keinen Patientenschaden verursachen können. Zudem gelten hohe Cybersecurity-Anforderungen.
- Gateway / Edge: Wenn ein Gateway Aufgaben der Update-Distribution oder -Validierung übernimmt, wird es selbst zum Medizinprodukt oder -zubehör und unterliegt damit der Regulierung, inklusive Verantwortung für Risikominimierung und Versionsverwaltung.
- Gerät: Auf dem Gerät sind ein sicherer Bootloader, redundante Speicherpartitionen (A/B) für Fail-Safe-Mechanismen und ein sicheres Device-Identity-Management erforderlich. Der Software-Lebenszyklus muss nach IEC 62304 lückenlos dokumentiert sein. Zudem muss nachgewiesen werden, dass Updates keinen kritischen Zustand auslösen und die elektrische Sicherheit (z.B. nach IEC 60601) stets gewahrt bleibt.
- Rückmeldung / Telemetrie (Cloud): Für das Post-Market Surveillance (PMS) besteht die Pflicht, Fehler, Rückrollungen und Sicherheitsvorfälle zu dokumentieren und gegebenenfalls in PMS-Berichten oder Vigilanz-Meldungen (MDR) zu berichten.
Die wichtigsten Elemente für einen sicheren, zuverlässigen OTA-Update-Prozess
Daraus leiten sich eine Reihe von Entwicklungszielen und -anforderungen ab, die abgearbeitet werden müssen, um das OTA-Retrofitting auf der technischen Seite zu realisieren. Dabei zeigt sich: Datenkommunikation, Over-the-Air-Updates, Datenschutz und Cybersecurity sind allesamt software-getriebene Themen. Teils fehlt es Geräteherstellern hier schlicht an Kapazitäten, teils aber auch an Expertise, um die nötigen Innovationen voranzutreiben. Deshalb setzen sie auf die Zusammenarbeit mit externen Entwicklungsdienstleister, um bestehende Lücken zu füllen.
Externe Unterstützung finden
Aufgrund der Komplexität der Themen kommt es jedoch darauf an, sich einen Partner zu suchen, der alle benötigten Kompetenzen abbildet und entsprechend im Entwicklungsprozess berücksichtigen kann. Hier kann die EDAG Group mit ihrem umfangreichen Serviceportfolio und einem breiten Erfahrungsschatz punkten. Hier können Kunden sicher sein, dass sowohl regulatorische wie technische Belange adressiert und Lösungen entwickelt werden, die neben der Verbesserung des Gerätes auch dessen Integration in das medizinische Ökosystem auf Anwenderseite in den Blick nehmen.
So umfasst der technische Support unter anderem sichere Cloud-to-Chip-Architektur gemäß IEC 62304, ISO 14971, MDR Anhang I, 17.2, Nachrüstung bestehender Geräte (Retrofit), Gateway-Design für Kliniknetzwerke, Test- & Verifikationspakete (IEC 62304 / IEC 60601) und Cybersecurity & Datenschutz.
Ebenso können die EDAG-Experten weitreichenden Support auf prozessualer Ebene bieten, wo dies benötigt wird, wie etwa bei regulatorischen Impact-Assessments für jedes Update, ISO 13485-konformer QMS-Integration und Prozessvorlagen, Risikomanagement und klinischen Bewertungen gemäß ISO 14971 bzw. MDR, bei der Kommunikation mit Benannten Stellen und beim Audit-Support sowie bei Pilot-Rollouts und klinischen Safeguards.
Dabei profitieren Kunden von validierten Sicherheits- und Update-Strategien, die bereits normativ abgesichert sind, denn EDAG überträgt bewährte OTA-Konzepte aus sicherheitskritischen Branchen, wie etwa Automotive, in die MedTech-Domäne. In interdisziplinären Teams wird diese Kombination aus Engineering-Kompetenz sowie regulatorischem Know-how kultiviert. Sie tragen zu schnellen, effizienten Entwicklungsprozessen bei, die von Anfang an auf eine reibungslose Marktzulassung ausgerichtet sind.
Stehen Sie als Hersteller medizinischer Geräte ebenfalls vor der Aufgabe, in Ihrem Portfolio Connectivity-Funktionen zu integrieren, die nicht nur regulatorischen Anforderungen genügen, sondern auch die Erwartungen von Anwendern und Patienten an Sicherheit und Zuverlässigkeit erfüllen? Dann sprechen Sie mit Sinem Atilgan, Specialist Consultant für Digitale Transformation, Tobias Schunk, Projektmanager Software & Digitalisation oder Michael Kelnberger, Sales Manager Technical Sales bei EDAG.
Und laden Sie sich gleich hier unser Whitepaper „Wie Sie die Fallstricke bei der Entwicklung vernetzter Medizingeräte umgehen“ herunter. Hier finden Sie weitere Details zu den regulatorischen Anforderungen und wie Sie diese technisch umsetzen können, dazu ein Fallbeispiel zum OTA-Retrofits eines digitalen EKG-Gerätes. Und nicht zuletzt ist auch eine Checkliste für eine Impact-Analyse als Entscheidungshilfe für den Entwicklungsprozess angefügt. 
