Willkommen bei emtronik.at, der Website von
Dipl.-Ing. Michael Kandler
dem Experten für Embedded Entwicklungen speziell im regulierten Umfeld
In meiner langjährigen Berufserfahrung in der Medizinprodukt-Entwicklung habe ich die Erfahrung und Beobachtung gemacht, dass die oftmals auftretenden Probleme in der Produktentstehung und im Projektablauf in den wenigsten Fällen in der technischen Umsetzung begründet waren.
Vielmehr hatten die Probleme meistens ihren Ursprung in unvollständiger Planung, in nicht berücksichtigten Arbeitspaketen, lückenhaften Spezifikationen, rudimentärem Systemdesign, fehlenden Integrationsplänen und zu spät durchgeführten Verifikationen. Diese Faktoren führten in einer späten Projektphase zu ungeplanten Aufwänden durch die notwendigen Korrekturen, Fehlerbehebungen und Spezifikationsänderungen.
Derartige Missgeschicke sind leicht zu vermeiden wenn ich meine Erfahrung und Kenntnis in Ihre Projekte oder in Ihre Organisation einbringe. Sie werden Ihre Produkte schneller und sicherer entwickeln und fertigstellen können.
Dipl. Ing. Michael Kandler
CEO & Founder
Embedded Entwicklung, Planung, Management, Dokumentation und Beratung
Die im Folgenden dargestellten Elemente und Etappen im Entwicklungsablauf habe ich schwerpunktmäßig danach ausgewählt bei denen ich erfahrungsgemäß Defizite oder Herausforderungen sehe und für die ich die passenden Unterstützungsleistungen anbieten kann.
Disclaimer: die folgenden Punkte stellen keine vollständige Darstellung und Aufzählung der Elemente des Entwicklungsablaufes dar!
In der Medizinproduktentwicklung beziehungsweise bei der Entwicklung von sicherheitskritischen Systemen werden höhere Anforderungen an die Entwicklungsqualität gestellt und die Einhaltung internationaler Standards vorausgesetzt.
So wird ein Qualitätsmanagementsystem vorausgesetzt, ein definierter Entwicklungsprozess verlangt und über die darin definierten Aktivitäten wird das Produkt schrittweise entwickelt. In definierten Entwicklungsphasen werden die geplanten Arbeitspakete erarbeitet, geprüft, in die vorangegangenen Arbeitspakete integriert bzw. aufgebaut und am Ende der Phase in einem Entwicklungsreview freigegeben.
Ein zentrales Element dabei ist, dass in allen Schritten geplant und nachverfolgbar vorgegangen werden muss.
Diese Denkweise wird in der klassischen Ausbildung zu technischen Berufen oft nur rudimentär vermittelt und ist einem typischen Entwickler nur wenig bewusst.
Dieses Defizit zu beheben und ihr Team entsprechend zu „enablen“ ist Ihr Benefit.
Der Produktdefinition kommt, obwohl ganz am Anfang der Produktentstehung und noch weitgehend theoretisch abgehandelt, eine besonders bedeutende Stellung zu: Aus den kommerziellen Anforderungen, der Produktidee, den Anforderungen aus dem Systemumfeld (wenn das Produkt in ein System eingebettet werden soll) werden im Diskurs mit den technischen Machbarkeitsstudien wird das Basiskonzept und die Grundanforderungen („Customer Requirements“) für das Produkt erstellt.
Dabei werden entscheidende Weichen gestellt; Zu hochfliegende Wünsche gepaart mit zu optimistischen technischen Realisierungsvorstellungen oder einer fehlenden Machbarkeitsstudie führen spätestens bei der Projektplanung zur Ernüchterung und je nach Bereitschaft der Finanzierung zu einem Projektabbruch oder zu einer Neukonzeptionierung des Produkts.
Als Ergebnis einer professionell durchgeführten Produktdefinition sollten mindestens:
– das Machbarkeitskonzept und ein grundlegendes technisches Konzept
– das „Lastenheft“ bzw. die „Customer Requirements“
– eine grobe Aufwandsabschätzung und
– das FTO („Freedom To Operate“) = rechtliche Realisierbarkeit
zur Entscheidung vorliegen.
Mein Angebot zur Unterstützung der Produktdefinition:
Aufbauend auf der Produktdefinition wird in diesem Schritt die Konzeptionierung durchgeführt:
Es wird ein technisches Konzept erstellt, das einen guten Überblick über die zu erwartende Umsetzung gibt. Weiters werden die technischen Inhalte mit den zu realisierenden Funktionen und Features abgeglichen bzw. „verhandelt“.
So können bei guter technischer Expertise Kosten und Aufwand für die Entwicklung und auch die Kosten in der Herstellung pro Feature / Funktion abgeschätzt werden.
Der Produktmanager kann darauf basierend entscheiden welche Funktionen und Features in die Entwicklung aufgenommen werden und welche aus Kosten-Nutzensicht besser nicht realisiert werden.
Wichtig in diesem Schritt ist, das Klarheit und Einigkeit zum Entwicklungsumfang und zum Entwicklungsergebnis herrscht.
Ein konsolidiertes Lastenheft (CRS) und ein Pflichtenheft-Entwurf (=technische Anforderungen) werden fixiert und freigegeben
Mein Angebot zu Ihrer Konzeptfindung:
Die Einhaltung eines definierten und vorher gut geplanten Entwicklungsprozesses zur Medizinproduktentwicklung wird von der MDR und allen relevanten Normen gefordert.
Keinen festgelegten Prozess zu haben ist ein großes Risiko für die Produktentwicklung und für den Medizinprodukthersteller.
Umgekehrt ist ein gut definierter Entwicklungsprozess der Schlüssel zu effizienter und hochqualitativer Entwicklung:
So entstehen parallel zu den Entwicklungsinhalten die zur Qualitätssicherung notwendigen Aufzeichnungen und Dokumentationen, die Planung der Verifikation und die begleitendenden Untersuchungen, Reviews und Tests. Änderungen in Anforderungen oder im System oder sonstige Veränderungen werden im Change Management System bearbeitet und dokumentiert.
Die entwicklungsbegleitende Qualitätssicherung kann weitgehend unangenehme Überraschungen bei der finalen Verifikation verhindern und kostspielige Entwicklungsschleifen verhindern.
Mein Angebot zur Planung des passenden Entwicklungsablaufs und der Ergebnisse:
An das Anforderungsmanagement werden für Medizinprodukte und sicherheitskritische System höhere Anforderungen gestellt:
Grundsätzlich kommt gutes Anforderungsmanagement jeder Produktentwicklung zugute, da ja nach einer möglichst vollständigen und präzisen Festlegung der Anforderungen das System geplant und zielgerichtet entwickelt werden kann.
Ein unvollständiger Satz an Anforderungen führt zwingendermaßen zu „late Requirements“. Diese verursachen – da sie im System ungeplant und unvorgesehen sind – in weiterer Folge schwere Störungen und Verzögerungen im Projektablauf.
Bei Medizinprodukten oder in sicherheitskritischen Systemen wird aber nicht nur auf die Vollständigkeit der Spezifikationen Wert gelegt, es muss zudem eine durchgängige Ableitung und Beziehung der Anforderungen in ihrer Hierarchie erkennbar sein. Und noch wichtiger: Allen Anforderungen müssen entsprechende Verifikationen zugeordnet werden. Damit wird sichergestellt, dass das Produkt systematisch in auf einander aufbauenden Tests verifiziert wurde. Umgekehrt müssen auch alle Verifikationen und Validierungen auf übergeordnete Anforderungen zurückverfolgbar sein können, um darstellen zu können gegen welche Spezifikation geprüft wurde und dass die definierten Abnahmekriterien erfüllt wurden.
Diese Systematik der Vor- und Rückverfolgbarkeit wird „Traceabilty“ genannt und wird bei allen Audits und Prüfungen vorausgesetzt.
Mein Angebot zur systematische Erarbeitung aller Spezifikationen:
Das Risikomanagement nimmt in der Medizinproduktentwicklung und bei sicherheitskritischen Systemen eine ganz zentrale Rolle ein. Auch in den entsprechenden Regularien, Direktiven und Normen wird auf gewissenhaftes Risikomanagement hoher Wert gelegt. Das Risikomanagement ist ein begleitender Prozess, der über die gesamte Projektdauer – von der Definition bis zur Freigabe – parallel laufen muss.
Ein Risikomanager verantwortet üblicherweise den Prozess. Er muss aber das gesamte Team mit einbinden, da zur Identifikation möglicher Risiken das technische Wissen, Systemwissen, Fachwissen und das Wissen über das Anwendungsgebiet und Systemumfeld erforderlich ist.
Oft wird Risikomanagement zu punktuell betrieben. Das Risikomanagement und die Risikomanagementakte müssen stets aktuell gehalten werden: Würden die Risikobetrachtungen nur am Projektanfang getan werden, so würden Risiken die während der Entwicklung (z.B. beim Systemdesign) oder bei Tests erkannt werden können nicht mehr berücksichtigt und die entsprechenden Maßnahmen zur Risikovermeidung nicht einfließen können. Werden aber die Risikobetrachtung erst zu Projektende gemacht (oder aktualisiert), so werden Risiken erst viel zu spät im Projektablauf erkannt und entsprechende Gegenmaßnahmen könnten nur mehr schwer oder schlimmstenfalls gar nicht mehr umzusetzen sein.
Auf die weitere Bearbeitung der Maßnahmen aus den Risikobetrachtungen wird besonderer Wert gelegt: So müssen entsprechende Anforderungen abgeleitet, in die Spezifikationen aufgenommen und speziell gekennzeichnet („Traceability“) werden.
Über Verifikation und Validierung muss nachgewiesen werden, dass die gesetzten Maßnahmen effektiv und wirksam sind.
Die Erstellung der Systemarchitektur ist ein wesentlicher Schritt im Entwicklungsprozess und sollte keinesfalls leichtfertig übergangen werden.
Die Aussage „Das System entsteht ja dann ohnehin während der Entwicklung“ ist zwar nicht ganz falsch, es sollte aber wie auch alle anderen Tätigkeiten und Inhalte vorab gut entworfen und geplant werden. Ohne zu Grunde liegende Systemarchitektur ist die systematische Erstellung eines Produktes nur schwer möglich.
Wir können uns diesen Sachverhalt am Bild eines Hausbaues veranschaulichen: Ohne Plan werden die Gewerke zwar ihre Teile anliefern können aber am Einbau (=Integration) scheitern weil ja nicht definiert ist wo und in welcher Reihenfolge der Einbau stattfinden soll.
Erst die Systemarchitektur und das darauf aufbauende Systemdesign ermöglichen die Projektplanung mit der Anordnung der Arbeitspakete für Design, Implementierung, Integration und Verifikation. Auch baut die finale Systemvalidierung auf die Systemarchitektur auf.
Mein Angebot zur Schaffung einer optimalen Systemarchitektur:
Die Projektplanung baut auf die Entwicklungsplanung bzw. den Entwicklungsprozess auf. Die Projektplanung ist jedoch wesentlich detaillierter, da in ihr die spezifischen Arbeitspakete geplant und entsprechend ihrer Abhängigkeiten voneinander, dem geplanten Ressourceneinsatz und den gesetzten Meilensteinen auf der Zeitachse angeordnet werden. Parallel dazu werden die bereits in „Entwicklungsablauf – Deliverables“
Mein Angebot zur Unterstützung der Planung Ihres Projekts:
Die Implementierungsaktivitäten und das Projektmanagement für Medizinprodukte und Produktentwicklungen, die einem definierten Entwicklungsablauf folgen müssen unterscheiden sich nicht grundsätzlich von „normalen“ Produktentwicklungen. Dennoch sollte darauf geachtet werden, dass die im Entwicklungsablauf definierten Abfolgen eingehalten werden. Oft ist man versucht Tätigkeiten vorzuziehen oder bei Verzögerungen Meilensteine oder Integrationsschritte zu verschieben und dennoch Arbeitspakete aus nachfolgenden Projektphasen zu beginnen. Grundsätzlich ist dies im Projektmanagement üblich und gelebte Praxis wenn es das Projekt erlaubt.
Bei Produktentwicklungen, die einem definierten Entwicklungsablauf folgen müssen ist bei derartigen Entscheidungen im Projektmanagement darauf zu achten, dass nicht notwendige Abfolge-Ketten aufgebrochen werden und Tätigkeiten gestartet werden, die zwingend einen abgeschlossenen und freigegeben Input benötigen der noch nicht vorhanden UND freigegeben ist.
Verifizierung und Validierung sind entscheidend für die Zulassung von Medizinprodukten und sicherheitskritischen Systemen und für die Einhaltung von Normen und Vorschriften. Durch gewissenhafte Verifizierung und Validierung können Sie sicherstellen, dass Ihre Produkte den höchsten Qualitätsstandards entsprechen und den Anforderungen der Anwender und den Auftraggebern gerecht werden.
Der Verifikationsprozess sollte möglichst früh starten und das Projekt bis zum Abschluss begleiten. Die Verifizierung ist ein parallel laufender Prozess (so wie z.B. auch der Risikomanagementprozess, das Qualitätsmanagement oder Regulatory Affairs).
Die Verifikation (Testung) darf also nicht – wie leider oft angenommen wird – erst am Ende des Projekts mit dem „fertigen“ Produkt stattfinden, sondern muss auch alle vorgelagerten Teil- oder Zwischenergebnisse umfassen. Erst die „Validierung“ schließt am Ende des Verifikationsprozesses die Produktentwicklung ab und ist die Grundlage für die Freigabe und Zulassung des Produkts,
Neben dem (Medizin-) Produkt selbst und seinen Komponenten müssen auch die Entwicklungsdokumente durch Reviews verifiziert werden.
Wird z.B. das Systemdesign überprüft spricht man von einem „Design Review“ (FDA – General Principles of Software Validation).
Da die fertig integrierte Software nicht mehr umfassend geprüft werden kann und damit die Gefahr verdeckter Fehler gegeben ist, verlangen die Normen ein aufbauendes Vorgehen bei der Software – Verifikation: Es müssen bereits die kleinsten Einheiten (Funktionen, Objekte etc.) – so genannte „Units“ – auf Funktion und Fehlerfreiheit durch Code Review, Coding Rule Checker und Unit Tests überprüft werden, bevor sie in das Softwaresystem integriert werden. Für diese laufenden Testungen bieten sich automatisierte Testsysteme besonders an: Es ist nämlich wichtig bereits durchgeführte Tests mit fortschreitender Integration immer wieder zu wiederholen (= „regression testing“), da die Gefahr besteht dass durch Kreuzeffekte mit neu integrierten Komponenten Fehler in bereits getesteten SW-Teilen auftreten. Die Automatisierung kann dabei die Effizienz wesentlich verbessern und die vor allem die Wiederholbarkeit sicherstellen.
Eine umfassende Dokumentation aller V&V-Aktivitäten sowie eine lückenlose Nachverfolgung zwischen Anforderungen, Tests und Ergebnissen sind entscheidend für die regulatorische Einhaltung und Transparenz, auch dabei können automatisierte Systeme unterstützen.
Und nicht zuletzt darf bei dem Einsatz von qualitätssichernden Tools nicht auf deren Beweis zur Eignung (=Toolvalidation“) vergessen werden.
Es muss nachgewiesen und dokumentiert werden, dass die eingesetzten Werkzeuge geeignet sind alle Fehler aufzuspüren und keine neuen Fehler in das System einbringen können.
Mein Angebot zur Planung und Unterstützung der konformen Systemvalidierung:
Wenn das Entwicklungsprojekt kurz vor der Zulassung steht, sollten alle bisher genannten Punkte abgeschlossen sein und die Ergebnisse finalisiert vorliegen. Es muss überprüft werden, ob die Entwicklungsakte vollständig ist und schlüssig aufgebaut ist. Sollten noch Lücken vorhanden sein müssen diese unbedingt geschlossen werden bevor man zur Zulassung bei der benannten Stelle antritt um unnötigen Ärger und Verzögerungen zu vermeiden.
Bei gröberen Defiziten sollte ein Plan erstellt werden um die Tätigkeiten zielgerichtet und effizient auf die Zulassung auszurichten.
Mein Angebot zur systematischen Dokumentation und zur erfolgreichen Zulassung:
Auch die Produktion von Medizinprodukten hat einem höheren Qualitätsstandard zu folgen. Die Produktion darf nicht nachgeschaltet und isoliert betrachtet werden. Die Anforderungen an die Produktion müssen schon im Entwicklungsstadium mitberücksichtigt und geplant werden.
So gilt es die Prüfmittel, die Schnittstellen und den Prüfablauf zu planen, zu Entwickeln und zu verifizieren.
Es ist auch der Nachweis zu erbringen, dass die Prüfmittel tauglich sind die erforderlichen Leistungsdaten des Produkts zu gewährleisten und die Freiheit von Fehlern garantieren können.
Für Medizinproduktente wird von der MDR die Überwachung der Produkte im Markt (Post-Market Surveillance) verlangt.
Bei Vorkommnissen sind notwendigerweise entsprechende Korrektur- und Vorbeugemaßnahmen (CAPA = Corrective And Preventive Action) vorzunehmen. Sowohl der Prozess dafür als auch die Verantwortlichen zur Umsetzung der Maßnahmen, wie auch ein Wartungsplan für das Produkt sollten schon vor Freigabe des Produkts erstellt sein.
Für ein schon länger auf dem Markt befindliches Medizinprodukt könnten im Zuge einer Produktänderung, Fehlerbehebung oder Produktaktualisierung noch weitere Arbeitspakete notwendig werden, da für das Produkt immer die aktuellen Standards einzuhalten sind und die neuen Standards mehr fordern als dies zum Zeitpunkt der Produktzulassung der Fall war. So könnten z.B. neue Dokumentationsteile erforderlich sein und erstellt werden müssen, Prüfungen wiederholt werden und neue Prüfungen durchgeführt werden müssen (z.B. durch geänderte EMV-Normvorgaben).
Besonderer Wert wird heute auf „Traceability“ (Nachvollziehbarkeit der Verifikation und Validierung) gelegt – wenn diese fehlt muss sie neu aufgebaut werden, was zudem weitere Lücken (fehlende Tests, unspezifische Anforderungen…) aufdecken könnte, die dann in weiterer Folge geschlossen werden müssen.