Vorträge
Hier finden Sie eine Reihe von Vorträgen, die ich in den letzten Jahren gehalten habe.
Wahl der Qual - Entwickeln oder entwickeln lassen?
Regelmäßig stehen Hersteller von Medizinprodukten vor der Frage, ob sie die Software - oder zumindest einen Teil der Software - für ihre Produkte selbst entwickeln sollten, oder stattdessen auf die Dienste eines externen Software-Entwicklungsdienstleisters zurückgreifen sollen.
Im Zuge dieser Entscheidung stellen sich eine ganze Reihe von Fragen:
- Haben wir die Kapazität und die Kompetenz, um eine komplexe Software selbst entwickeln?
- Finden wir einen Dienstleister, den wir diese wichtige Aufgabe anvertrauen können?
- Wer übernimmt später die Wartung der Software?
- Wissen wir eigentlich schon ganz genau, welche Anforderungen die Software hat, die wir in Auftrag geben möchten?
- Was kostet uns der ganze Spaß?
Neben diesen Fragen nimmt der Vortrag auch mögliche Strategien für die Zusammenarbeit zwischen Medizinprodukteherstellern und Software-Entwicklungsdienstleistern in den Blick. Wann ist es sinnvoll, in eine langfristige Entwicklungspartnerschaft zu investieren, wann reicht es aus, sich kurzfristig Kapazität auszuleihen, und wann sollte der Aufbau eigener Kompetenzen im Mittelpunkt stehen?
Vortrag im Rahmen der MedConf 2023, Mai 2023
Process as Code
Prozesse für die Software-Entwicklung zu definieren gleicht einer Produktentwicklung: Anforderungen müssen erfasst, eine Prozessarchitektur muss erstellt werden, Schnittstellen wollen definiert sein, und am Ende soll alles in einen ausführbaren Workflow implementiert, getestet und validiert werden. Und dem Problem nähern wir uns gewöhnlich mit den bewährten Werkzeugen, die traditionell auch in der Produktentwicklung zum Einsatz kommen: Word und Excel…
Das es auch effektiver geht, soll in diesem Vortrag demonstriert werden. Wir wollen einen Ansatz vorstellen, der sich näher am Vorgehensmodell einer Software-Entwicklung orientiert:
- Anforderungen werden in Epics, Features und Tasks erfasst
- Die Erstellung der Prozessarchitektur wird von einem Meta-Modell geleitet
- Die Prozesse selbst werden redundanzfrei in einem XML-Dialekt modelliert
- Dokumente wie SOPs, Arbeitsanweisungen oder Checklisten werden automatisch und konsistent generiert
- Änderungen werden kontrolliert und automatisch auf Konsistenz geprüft
Und natürlich ist die Entwicklungsumgebung vollständig virtuell und cloud-basiert. Damit ist es leicht möglich, aus den Betroffenen Beteiligte zu machen und gemeinsam an der Prozessdefinition zu arbeiten.
Vortrag gemeinsam mit Dr. Jan Dörrenbächer, Fresenius Medical Care, im Rahmen der MedConf 2020, November 2020
Documentation as Code
Dokumentierst Du noch, oder programmierst Du schon?
Die Dokumentation wird von vielen Entwicklern immer noch als zweitrangig angesehen. Im Mittelpunkt steht das Programmieren einer lauffähigen Software für das Medizinprodukt. Die Dokumentation ist ja eh nur für die Zulassung relevant, und kann dann bequem später erstellt werden, sobald wieder Zeit ist…
Natürlich weiß jeder, dass man seine Arbeit frühzeitig dokumentieren sollte. Aber es gibt so viele Gründe, dies nicht zu tun: immerwährender Zeitdruck, die viel größere Faszination des Quellcodes und nicht zuletzt die für Entwickler so “andersartigen” Werkzeuge, die man zur Dokumentation verwenden muss.
Ein Weg, um Dokumentationsaufgaben in der Entwickleralltag zu integrieren besteht darin, Werkzeuge zu verwenden, die sich nahtlos in die Entwicklungsumgebung einbinden lassen. “Documentation as code” ist dabei bisher vor allem im Bereich des detaillierten API-Designs schon lange im Einsatz.
In diesem Vortrag werden Überlegungen weiter verfolgt, die Teilnehmer des Open-Spaces 2018 zum Thema Dokuntation entwickelt haben, und die zeigen, dass sich dieses Konzept auch auf Software-Architektur, Design und Test anwenden lässt. Nicht einmal vor den Requirements müssen die Mutigen zurückschrecken!
Vortrag im Rahmen der MedConf 2019, November 2019
Risikoanalyse - reloaded
Wenn Sie für ein neues Produkt eine neue Risikoanalyse erstellen müssen, dann sind Sie fein raus. Schließlich finden Sie in der EN 14971 alles, was Sie zu tun haben. Und es gibt reichlich Literatur und viel Erfahrungswissen dazu, wie Sie die Anforderungen der Norm umsetzten können.
Wenn Sie aber vor der Aufgabe stehen, zahlreiche einzelne Risikoanalysen für ein seit langem am Markt erhältliches Produkt konsolidieren zu wollen, dann sind Sie ziemlich auf sich alleine gestellt.
Dieser Vortrag berichtet von Erfahrungen, die wir im Rahmen der Neuzulassung eines bewährten Produktes mit der Risikoanalyse gemacht haben. Besondere Herausforderungen dabei waren:
- Risikoanalysen, die nach verschiedenen Ausgaben der EN 14971 erstellt waren
- Vermischung von technischen und medizinischen Fragestellungen in der Bewertung eines Risikos
- Verwechslung von Ursachen und Gefährdungen
Vor allem aber: der große Umfang der vorhandenen, nicht ganz redundanz-freien, Risikoanalysen.
Sie werden erfahren, mit welchem Informationsmodell Risiken systematisch erfasst werden können, wie sich eine Risikoanalyse sogar in DOORS modellieren und wie sich die Rolle der medizinischen Experten von denen der Techniker trennen läßt.
Vortrag gemeinsam mit Nadine Langguth, Regulatory Affairs Manager bei WITTENSTEIN intens im Rahmen der MedConf 2018, Oktober 2019
Cybersecurity - haben wir ein Problem mit der SOUP?
Inzwischen berichten die Medien fast täglich über Sicherheitslücken in Computersystemen mit teilweise verheerenden Auswirkungen. Computersysteme in Kliniken sind davon ebenso betroffen wie Medizinprodukte.
Fragt man sich nach den Ursachen für diese Probleme, so findet man die Schuld in der Regel bei “den Anderen”: die IT-Abteilung hat die Software nicht rechtzeitig aktualisiert, Microsoft hat die Software nicht rechtzeitig gepatcht, die NSA hat zu lange geschwiegen. Bezogen auf Medizinprodukte kann man kurz sagen: Die meisten Probleme verursacht die SOUP.
Damit sind wir leider nicht aus dem Schneider, denn als Hersteller von Medizinprodukten sind wir natürlich auch für die SOUP-Komponenten in unseren Systemen, und damit auch für die Korrektur von Sicherheitslücken in diesen Komponenten verantworlich.
Dieser Vortrag diskutiert die Security-Aspekte, die sich aus dem - teilweise massiven - Einsatz von SOUP in Medizinprodukten ergeben sowie über erste Erfahrungen mit dem Versuch, diese angemessen zu behandeln und dabei vor allem den Vorstellungen der FDA gerecht zu werden.
Vortrag im Rahmen der MedConf 2017, Oktober 2017
PDF-Signaturen für Entwicklungsdokumente
Regulatorische Anforderungen für Medizinprodukte enthalten immer auch Dokumentationsanforderungen. Bei der Entwicklung von Medizinprodukten entstehen besonders viele Dokumente: Anforderungsspezifikationen, Architekturbeschreibungen, Testpläne und -protokolle sind nur wenige Beispiele. All diese Dokumente müssen geschrieben, überarbeitet, freigegeben und archiviert werden.
Meist werden diese Dokumente elektronisch erstellt, für die Freigabe dann aber ausgedruckt und händisch unterschrieben. Zur Ablage landet das Papier meist in einem Ordner im Archiv; zur Verwendung kommt dann aber doch eher ein eingescanntes, im Netzwerk verteilbares Dokument - und läuft so Gefahr, nicht rechtsverbindliche Dokumente zu benutzen.
Da kommt schnell der Wunsch auf, die Dokumente doch gleich komplett elektronisch zu führen. Doch dann sind unter anderem die Anforderungen des amerikanischen Gesetzes “21 CFR Part 11 (Electronic Records, Electronic Signatures)” zu beachten. Dieses Gesetz beschreibt, wann die FDA elektronische Dokumente anstelle von Papierdokumenten akzeptiert. Dabei kommt der Validierung der eingesetzten Werkzeuge und Verfahren eine zentrale Bedeutung zu, und die Hürden sind nicht gering. Alle in der Entwicklung eingesetzten elektronischen Werkzeuge nach Part 11 zu validieren, scheitert daher meist schon am dafür notwendigen Aufwand.
Aber ist auch gar nicht unbedingt notwendig, all die Anforderungsdatenbanken, UML-Modellierungstools und Testwerkzeuge zu validieren - wenn am Ende doch nur ein einfaches Dokument freigegeben werden soll. Ein in der Praxis bewährter Weg besteht darin, aus den Entwicklungswerkzeugen Dokumente im PDF-Format zu generieren, und diese dann elektronisch zu signieren und zu archivieren. Notwendig sind dazu nur Tools, die Sie wahrscheinlich schon auf Ihrem Rechner haben - und die richtige Vorgehensweise, um nicht mit den Vorgaben des Part 11 in Konflikt zu geraten.
Vortrag gemeinsam mit Marc Holfelder, Geschäftsführer der LA2 GmbH im Rahmen der MedConf 2016, Oktober 2016
Medical SPICE - Was bringt die neue VDI-Richtlinie 5702?
Die Entwicklung medizinischer Software ist sehr stark reglementiert. Alleine in der EU nehmen fünf harmonisierte Normen Einfluss auf die Gestaltung der Entwicklungsprozesse. Hersteller von Medizinprodukten verwenden sehr viel Aufwand darauf, die Konformität mit diesen Normen sicherzustellen.
Die Konformität alleine ist allerdings noch lange kein Garant für einen praxistauglichen Entwicklungsprozess, der qualitativ hochwertige Ergebnisse liefert. Reifegradmodelle wie CMMI oder SPICE, die hier weiterhelfen können, sind in der Medizintechnik noch wenig verbreitet. Unter anderem, weil die gängigen Assessment-Modelle die Besonderheiten bei der Entwicklung medizinischer Software nicht berücksichtigen.
Im Mai 2016 erscheint die Richtlinie VDI 5702 (Medical SPICE) im Gründruck. Nach den Vorgaben der ISO 15504-2 aufgebaut, stellt das Modell alles bereit, was notwendig ist, um SPICE-konforme Assessments der Entwicklung medizinischer Software durchzuführen.
Die Durchführung eines solchen Assessments bietet dem Hersteller von medizinischer Software nicht nur die Möglichkeit, seine Konformität mit den einschlägigen Normen zu belegen, sondern darüber hinaus Anhaltspunkte für seine Prozessreife und Verbesserungspotentiale zu erhalten. Zudem bildet dieses Assessment-Modell die Grundlage für die Arbeit des Fachausschusses „Software-Qualität in der Medizintechnik“ im VDI.
Dieser Vortrag vermittelt, welche Inhalte mit „Medical SPICE“ zur Verfügung stehen und wie dieses Modell für Konformitätsbewertungen und die Bestimmung von Reifegraden genutzt werden kann.
Vortrag im Rahmen der Arbeitskreis Medizintechnik des VDI/VDE, Mai 2016
Medical SPICE - Was bringt die neue VDI-Richtlinie 5702?
Die Entwicklung medizinischer Software ist sehr stark reglementiert. Alleine in der EU nehmen fünf harmonisierte Normen Einfluss auf die Gestaltung der Entwicklungsprozesse. Hersteller von Medizinprodukten verwenden sehr viel Aufwand darauf, die Konformität mit diesen Normen sicherzustellen.
Die Konformität alleine ist allerdings noch lange kein Garant für einen praxistauglichen Entwicklungsprozess, der qualitativ hochwertige Ergebnisse liefert. Reifegradmodelle wie CMMI oder SPICE, die hier weiterhelfen können, sind in der Medizintechnik noch wenig verbreitet. Unter anderem, weil die gängigen Assessment-Modelle die Besonderheiten bei der Entwicklung medizinischer Software nicht berücksichtigen.
Ein exakt auf die Bedürfnisse der Medizintechnik zugeschnittenes Assessment-Modell ist in den letzten Jahren unter dem Namen „Medical SPICE“ beim Verein Deutscher Ingenieure (VDI) entstanden. Nach den Vorgaben der ISO 15504-2 aufgebaut, stellt das Modell alles bereit, was notwendig ist, um SPICE-konforme Assessments der Entwicklung medizinischer Software durchzuführen.
Die Durchführung eines solchen Assessments bietet dem Hersteller von medizinischer Software nicht nur die Möglichkeit, seine Konformität mit den einschlägigen Normen zu belegen, sondern darüber hinaus Anhaltspunkte für seine Prozessreife und Verbesserungspotentiale zu erhalten.
Zudem bildet dieses Assessment-Modell die Grundlage für die Arbeit des Fachausschusses „Software-Qualität in der Medizintechnik“ im VDI, und damit auch für die Vorträge dieses Tracks.
Vortrag im Rahmen der MedConf, Oktober 2015
IEC 62304 - was bringt das Amendment 1?
Nach fast zehn Jahren wurde im Juni 2015 die erste Änderung an der IEC 62304 - das Amendment 1 - veröffentlich.
Dieser Vortrag diskutiert einige der Probleme, die sich in der Praxis bei der Anwendung der IEC 62304 immer wieder ergeben und untersucht, welche Abhilfe das Amendment 1 schafft.
Vortrag im Rahmen des Kompetenzpool Zulassung, September 2015
Medizinprodukt 1.0 – Lehren aus der Entwicklung von Medizinprodukte-Software
Wer schon jahrelang Software für ein Medizinprodukt entwickelt, sollte eigentlich alle Fallstricke kennen, die einem Projekterfolg im Wege stehen. Normen und ihre teils schwierige Auslegung, Programmiersprachen und ihre Feinheiten, Projektmanagement-Methoden und der Umgang mit engen Zeitplänen sind bekannt und in einem guten Qualitätsmanagement-System abgebildet.
Wenn Sie aber vor der Aufgabe stehen, die Software für eine allererste Version eines Medizinproduktes zu entwickeln, werden Sie mit ganz neuen Herausforderungen konfrontiert: Erfahrungen mit der Technologie sind sehr beschränkt; die Hardware, auf der die Software einmal laufen soll, gibt es höchstens als Schaltplan; die Entwickler, die die Software programmieren sollen, müssen Sie erst noch finden; der Entwicklungsprozess für die Software existiert noch nicht. Eigentlich scheint nur eines fest zu stehen: der Endtermin.
In diesem Vortrag sollen eigene Erfahrungen aus verschiedenen Projekten reflektiert werden, in denen ein Medizinprodukt von der Idee bis zur Marktreife gebracht wurde. Besonders geht es dabei um die folgenden Fragestellungen:
Besondere Anforderungen: wie unterstützen Sie die Entwicklung und den Test des Gesamtsystems? Software-Architektur: was müssen Sie beachten, damit Sie auch noch eine Version 2.0 Ihrer Medizingeräte-Software auf den Markt bringen können? Team-Aufbau: wie bauen Sie schnell ein Software-Entwicklungsteam auf, mit dem Sie lange arbeiten können? Software-Qualitätsmanagement: Wie können Sie sicherstellen, dass Ihre junge Software nicht nur „irgendwie funktioniert“, sondern auch den notwendigen Qualitätslevel erreicht?
Vortrag auf der MedConf, Oktober 2014
Testautomatisierung - Schritthalten mit agiler Software-Entwicklung
Wenn Sie die Entwicklung einer eingebetteten Software für ein Medizinprodukt von einer Wasserfall-artigen Vorgehensweise auf agile Software-Entwicklung umstellen möchten, dann kommt eine ganze Reihe von Herausforderungen auf Sie zu: ein geeignetes Entwicklungsteam muss etabliert, Prozesse an die neuen Arbeitsweisen angepasst und Werkzeuge müssen eingeführt werden.
Dieser Vortrag berichtet über die Erfahrungen bei einem Hersteller von Medizinprodukten, der genau diesen Schritt gegangen ist und ein Software-Entwicklungsprojekt, das von einem externen Dienstleister klassisch abgewickelt wurde, auf ein internes Team transferiert hat, welches die Entwicklung nach Scrum durchführt.
Dabei bestand einer der wesentlichen Schritte darin, die Durchlaufzeit der Software-Systemtests von drei Monaten auf eine Woche zu reduzieren. Dies ist nur durch die nahezu vollständige Automatisierung der Software-Tests möglich. Die Antwort auf die Frage, wie dies auch für ein eingebettetes, verteiltes und echtzeitfähiges Software-System zu erreichen ist, steht im Mittelpunkt dieses Vortrags.
Vortrag auf der AgileMed, Februar 2014
Validierung von Software-Werkzeugen
Die Entwicklung von Medizinprodukten ist heute ohne Software-Werkzeuge kaum noch vorstellbar. Sowohl das Design von Geräten als auch bei der Programmierung der Software in den Medizinprodukten sind werden durch Hilfsmittel wie Anforderungsdatenbanken, Bugtracker, CAD-Systeme oder Entwicklungsumgebungen unterstützt. Und die Entwickler müssen sich auf diese Werkzeuge verlassen können, um keine unerfreulichen Überraschungen erlebt und um Risiken für die Patienten und Anwender zu reduzieren. Daher müssen alle diese Werkzeuge vor ihrer Verwendung validiert werden. So fordern es zumindest die Normen ISO 13485 und IEC 60601-1.
Allerdings schweigen sich die einschlägigen Normen, inklusive der für die Software-Entwicklung besonders relevanten IEC 62304, darüber aus, wie genau eine solche Überprüfung auszusehen hat. Fallbeispiele aus aktuellen Projekten zeigen, dass es ein großes Spektrum an Meinungen darüber gibt, was zur Validierung eines Entwicklungswerkzeuges zu tun ist. In diesem Vortrag soll daher die Frage diskutiert werden, wie sich Software-Werkzeuge für die Entwicklung von Medizinprodukten systematisch validieren lassen, sodass der Aufwand angemessen ist und die maximale Wirkung auf die Qualität der Entwicklungsergebnisse entfaltet.
Dazu wird eine Vorgehensweise zur Qualifikation von Software-Werkzeugen, die mit der Norm ISO 26262 („Road vehicles – Functional safety“) für die Automobilindustrie verbindlich ist, auf die Besonderheiten der Medizintechnik adaptiert. Diese Vorgehensweise geht vom Einfluss des Software-Werkzeuges auf die Risiken des Medizinproduktes aus und betrachtet anschließend die Wahrscheinlichkeit der Entdeckung einer möglichen Fehlfunktion dieses Werkzeuges. Darüber hinaus wird auch die Sicherheitsklasse der betroffenen Software-Komponenten in die Betrachtung mit einbezogen. Aus diesen Faktoren lassen sich dann die notwendigen Qualifizierungsverfahren für das Software-Werkzeug ableiten.
Für die Praxis bietet dieses Vorgehen den Vorteil, eine klare und nachvollziehbare Begründung zu liefern, welcher Aufwand für die Validierung eines Software-Werkzeuges angemessen ist. Damit lassen sich sowohl im Entwicklungsteam als auch im Audit langwierige Diskussionen vermeiden.
Vortrag auf der MedConf, Oktober 2013
Standalone-Software als Medizinprodukt
Spätestens mit der Novellierung der Medizinprodukte-Richtlinie aus dem Jahr 2007 ist klar, dass auch eigenständige Software als Medizinprodukt klassifiziert werden muss, wenn sie eine medizinische Zweckbestimmung hat. Allerdings ist nicht jede Software, die in Kontext des Gesundheitswesens verwendet wird, automatisch ein Medizinprodukt. Beispielsweise werden Abrechnungssysteme, mit denen Krankenhäuser ihre Rechnungen erstellen, nicht als Medizinprodukt angesehen.
Unklar wird die Abgrenzung aber schnell, wenn die Systeme neben rein buchhalterischen Aufgaben auch Patientendaten verwalten. Labordaten-Programme, elektronische Gesundheitsakten und digitale Radiologiearchive können, je nach Ausprägung, unter die Medizinprodukte-Richtlinie fallen oder aber als nicht reglementierte Software gelten.
Mit der im Januar 2012 veröffentlichten Guidline „MEDDEV 2.1/6“ der EU-Kommision steht nun endlich ein Leitfaden zur Verfügung, der es Herstellern erlauben soll, mehr Klarheit bei der Einstufung ihrer Produkte zu erlangen. Auch wenn diese Guideline nicht alle Fragestellungen zur Klassifikation beantworten kann, bietet sie doch einen Weg an, um einige Anwendungstypen eindeutig einordnen zu können.
In diesem Vortrag steht die Analyse einer eigenständigen Software hinsichtlich der Anwendbarkeit der Medizinprodukte-Richtlinie im Mittelpunkt. Darüber hinaus wird untersucht, welche Auswirkungen die neue Guideline auf die Gestaltung medizinischer Software hat, und welche Besonderheiten bei der Entwicklung eigenständiger Software als Medizinprodukt zu beachten sind.
Vortrag auf der MedConf, Oktober 2012
SPICE in der medizinischen Software-Entwicklung
Die Entwicklung medizinischer Software ist sehr stark reglementiert. Alleine in der EU nehmen fünf harmonisierte Normen Einfluss auf die Gestaltung der Entwicklungsprozesse. Hersteller von Medizinprodukten verwenden sehr viel Aufwand darauf, die Konformität mit diesen Normen sicherzustellen. Die Konformität alleine ist allerdings noch lange kein Garant für einen praxistauglichen Entwicklungsprozess, der qualitativ hochwertige Ergebnisse liefert. Reifegradmodelle wie CMMI oder SPICE, die hier weiterhelfen können, sind in der Medizintechnik noch wenig verbreitet. Unter anderem, weil die gängigen Assessment-Modelle die Besonderheiten bei der Entwicklung medizinischer Software nicht berücksichtigen.
Einen Ausweg aus dieser Situation bietet ein an die Normen der Medizintechnik angepasstes Assessment-Modell nach ISO 15505. Dieses Modell muss Base Practices und Work Products für die Forderungen der Normen ISO 13485, ISO 14971, IEC 62304, IEC 62366 und IEC 60601-1 bereitstellen. Dabei müssen die Überschneidungen dieser Normen beseitigt werden.
Ein solches Assessment-Modell steht unter dem Namen ‚Medical SPICE‘ zur Verfügung. Nach den Vorgaben der ISO 15504-2 aufgebaut, stellt das Modell alles bereit, was notwendig ist, um SPICE-konforme Assessments der Entwicklung medizinischer Software durchzuführen.
In der Anwendung verhält sich das Medical SPICE Assessment-Modell wie andere Assessment-Modelle, beispielsweise Automotive SPICE. Die Durchführung eines solchen Assessments bietet dem Hersteller von medizinischer Software nicht nur die Möglichkeit, seine Konformität mit den einschlägigen Normen zu belegen, sondern darüber hinaus Anhaltspunkte für seine Prozessreife und Verbesserungspotentiale zu erhalten.
Neben des offensichtlichen Einsatzes des PAM als Assessment-Modell für Unternehmen der Medizintechnik, bildet es eine Grundlage für die Arbeit des Fachausschusses „Software-Qualität in der Medizintechnik“ im VDI. Dort werden für die Base-Practices des Modells Vorschläge zur Umsetzung, Best-Practices, erarbeitet. Diese sollen in Zukunft als VDI-Richtlinie zur Verfügung gestellt werden.
Vortrag auf der MedConf, Oktober 2012
Funktionale Sicherheit von Medizinprodukten
Medizinprodukte müssen einen nachweisbaren Nutzen für den Patienten bieten; dazu müssen Sie natürlich medizinisch wirksam sein. Vor allem aber verlangt der Gesetzgeber, dass Medizinprodukte sicher sind. Diese Forderung ist die zentrale grundlegende Anforderung für jedes Medizingerät.
Medizinprodukte können nur dann sicher entworfen werden, wenn eine ganze Reihe von Aspekten beachtet wird. Das Risikomanagement, beschrieben in der ISO 14971, ist ein wesentlicher Baustein auf dem Weg zum sicheren Produkt und hilft, Gefährdungen für den Patienten, Anwender und die Umwelt zu erkennen und zu beherrschen. Bei der Entwicklung medizinischer Software muss eine Klassifikation nach Sicherheitsklassen vorgenommen werden, die Auswirkung auf die Gestaltung des Software-Entwicklungsprozesses und der zu erstellenden Dokumentation hat. Und die Grundsätze der funktionalen Sicherheit, beispielsweise die Forderung nach Erstfehlersicherheit, müssen dabei stets beachtet werden.
Bei der Umsetzung all dieser Forderungen kommt es auf die richtige Vorgehensweise an. So erlaubt es die IEC 62304 beispielsweise, die Sicherheitsklasse einer Software-Komponente durch eine Hardware-Maßnahme zu reduzieren. In der Praxis ist dies oftmals eine sehr sinnvolle Maßnahme. Folgt man den Vorgaben aus der Norm allerdings blind, dann entstehen mitunter Systemarchitekturen, die nicht funktional sicher sind!
Ziel dieses Vortrags ist es, einen Überblick über die maßgeblichen Regeln auf dem Feld der funktionalen Sicherheit zu geben und anhand von Beispielen aus Entwicklungsprojekten zu veranschaulichen, wie diese eingesetzt werden können, um zu einem nachweisbar sicheren Entwurf für ein Medizinprodukt samt der eingebetteten Software zu gelangen.
Vortrag auf dem Medical Device Day , Juni 2012
Safety Assurance Cases
Im Rahmen einer Sicherheitsinitiative, die sich zuerst an die Hersteller von Infusionspumpen richtet, fordert die FDA die Einreichung eines strukturierten Sicherheitsnachweise, eines Safety Assurance Case.
Dieser Nachweis ist in anderen Branchen, etwa dem Schiffsbau und der Kraftwerkstechnik, schon seit langem gebräuchlich. Indem er Gefährdungen, Gegenmaßnahmen, Sicherheitskonzepte und Testnachweise miteinander verknüpft, liefert er Argumente für die Aussage “das Medizinprodukt ist sicher”. Eine grafische Notation hilft dabei, den Überblick über die umfangreichen Einreichungen zu behalten und für die FDA den Review-Prozess zu vereinfachen.
Auf die Hersteller von Medizinprodukten kommt damit ein neues Instrument zu, das sie in Zukunft beherrschen müssen. Aber der Safety Case-Ansatz ist mehr als nur eine weitere Dokumentationshürde. Sinnvoll eingesetzt, lässt sich damit der Prozess des Risikomanagements zielgerichtet gestalten.
Dieser Vortrag führt in die Methodik der Erstellung und Dokumentation von Safety Assurance Cases ein.
Vortrag auf der MedConf, Oktober 2011
Weniger Review-Aufwand durch Statische Codeanalyse
Die Testautomatisierung hat sich bei der Reduzierung von Testaufwänden längst als effektives und effizientes Werkzeug durchgesetzt. Bei der Verifikation von Sourcecode ist dagegen oftmals noch ein vollständiges Codereview das Mittel der Wahl. Dabei gelten Codereviews als mühsam, schwierig und fehleranfällig. Vor allem, wenn es darum geht, die Einhaltung von Coding-Guidelines wie MISRA C oder MISRA C++ zu überwachen, stößt man mit Code-Reviews schnell an Kapazitätsgrenzen.
Durch den Einsatz automatisierter, statischer Code-Analysen lassen sich die Aufwände für manuelle Codereviews deutlich reduzieren und vor allem auf die wirklich kritischen Bereiche einer Software konzentrieren. Dabei helfen auch Code-Metriken, die bei der statischen Code-Analyse erhoben werden können. Mithilfe dieser Metriken lassen sich unter anderem die Bereiche des Codes identifizieren, die einem manuellen Review unterzogen werden sollten.
Die Herausforderung beim Einsatz statischer Code-Analysen besteht weniger in der Installation eines entsprechenden Werkzeuges oder der Integration in den Build-Prozess. Vielmehr ist es entscheidend, aus der Vielzahl möglicher Prüfverfahren diejenigen auszuwählen, die geeignet sind, die Qualität der entwickelten Software bestmöglich sicherzustellen. Hier hat sich in der Praxis ein abgestuftes Vorgehen bewährt, das sich auch an der Sicherheitsklasse der untersuchten Software orientiert.
Der Vortrag zeigt, wie sich Verifikationsaufgaben mit statischer Code-Analyse automatisieren lassen, und gibt Tipps für den praktischen Einsatz entsprechender Werkzeuge.
Vortrag auf der MedConf, Oktober 2011
