Matthias Hölzer-Klüpfel

Diplom-Physiker, M.SC.

Telefon +49 176 60857994
matthias@hoelzer-kluepfel.de

Vorträge

Hier finden Sie eine Reihe von Vorträgen, die ich in den letzten Jahren gehalten habe.

PDF-Signaturen für Entwicklungsdokumente

Vortrag

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

Vortrag herunterladen

Medical SPICE - Was bringt die neue VDI-Richtlinie 5702?

Vortrag

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

Vortrag herunterladen

Medical SPICE - Was bringt die neue VDI-Richtlinie 5702?

Vortrag

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

Vortrag herunterladen

IEC 62304 - was bringt das Amendment 1?

Vortrag

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

Vortrag herunterladen

Medizinprodukt 1.0 – Lehren aus der Entwicklung von Medizinprodukte-Software

Vortrag

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

Vortrag herunterladen

Testautomatisierung - Schritthalten mit agiler Software-Entwicklung

Vortrag

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

Vortrag herunterladen

Validierung von Software-Werkzeugen

Vortag

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

Vortrag herunterladen

Standalone-Software als Medizinprodukt

Vortag

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

Vortrag herunterladen

SPICE in der medizinischen Software-Entwicklung

Vortag

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

Vortrag herunterladen

Funktionale Sicherheit von Medizinprodukten

Vortag

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

Vortrag herunterladen

Safety Assurance Cases

Vortag

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

Vortrag herunterladen

Weniger Review-Aufwand durch Statische Codeanalyse

Vortrag

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

Vortrag herunterladen