Von der Idee zur CE-Kennzeichnung

Transkript

1 Von der Idee zur CE-Kennzeichnung R n B Medical Software Consulting GmbH Andreas Böhler Fachhochschule Linz office@rnb-consulting.at Idee bis CE 2015/12/02 1 / 34

2 Agenda Überblick Überblick 1 Das Problem 2 Die Idee 3 Die Umsetzung 4 Über Uns office@rnb-consulting.at Idee bis CE 2015/12/02 2 / 34

3 Das Problem Das Problem Schwere Krankheiten können jeden treffen Besonders tragisch bei kleinen Kindern Erst kurzes Leben womöglich Schmerzen eventuell langer Leidensweg Ziel der Palliativmedizin ist ein möglichst langes Erhalten einer möglichst hohen Lebensqualität Idee bis CE 2015/12/02 3 / 34

4 Das Problem Therapie Bei Krankheiten, die mit Schmerzen einhergehen, ist Schmerztherapie wichtig (direkter Einfluss auf Lebensqualität) Optimale Dosierung des Schmerzmittels erforderlich Möglichst keine Schmerzen Möglichst keine Nebenwirkungen Idee bis CE 2015/12/02 4 / 34

5 Das Problem Therapie Erwachsene Menschen können sich mit Worten äußern und Therapie optimal mit Therapeuten einstellen. Frage Kleine Kinder? Idee bis CE 2015/12/02 5 / 34

6 Die Idee Die Idee Smartphones und Tablets haben in viele Lebensbereiche Einzug gefunden Bereits kleine Kinder können sehr rasch mit einem Smartphone umgehen Symbole und Bilder helfen, sich ohne Lesen zurechtzufinden Die Idee Eine elektronische Tagebuch-App soll Kindern die Möglichkeit bieten, ihr Wohlbefinden ausdrücken zu können Idee bis CE 2015/12/02 6 / 34

7 Die Idee Die Idee Lupus Ein Avatar, Lupus, symbolisiert dabei einen Freund / einen Begleiter des Kindes Das Kind kann sein Wohlbefinden auf den Freund projizieren Tut ihm der Bauch weh, kann das durch antippen von Lupus Bauch symbolisiert werden Der interaktive Lupus bietet eine Möglichkeit, sich ohne Sprache auszudrücken office@rnb-consulting.at Idee bis CE 2015/12/02 7 / 34

8 Die Idee Die Idee Die Möglichkeit, sich besser zu artikulieren ist nur ein Teil der App. Weitere Funktionen sollen sein: Übertragung der Daten zum Arzt Beim nächsten Besuch Direkt online Darstellung des Therapieverlaufs durch Aufzeichnung der Daten Korrelation mit der Medikation Idee bis CE 2015/12/02 8 / 34

9 Die Idee Die Idee Arzt stellt Medikation auf Basis der Daten optimal ein Die Software analysiert die Daten Zeitlicher Verlauf Vorschläge zur Medikation Korrelation mit Ernährung Korrelation mit bestimmten Ereignissen Idee bis CE 2015/12/02 9 / 34

10 Software als Medizinprodukt Medizinprodukt? Bei jedem Produkt für den medizinischen Bereich muss geklärt werden Ist es ein Medizinprodukt? Wenn ja, welche Medizinprodukte-Klasse ist zutreffend? Welche Möglichkeiten des Zulassungsprozesses gibt es? Idee bis CE 2015/12/02 10 / 34

11 Software als Medizinprodukt Medizinprodukt? Richtlinie 93/42/EWG des Rates über Medizinprodukte Medizinprodukt alle einzeln oder miteinander verbunden verwendeten Instrumente, Apparate, Vorrichtungen, Software, Stoffe oder anderen Gegenstände, [...] die vom Hersteller zur Anwendung für Menschen für folgende Zwecke bestimmt sind: Erkennung, Verhütung, Überwachung, Behandlung oder Linderung von Krankheiten; [...] und deren bestimmungsgemäße Hauptwirkung im oder am menschlichen Körper weder durch pharmakologische oder immunologische Mittel noch metabolisch erreicht wird, deren Wirkungsweise aber durch solche Mittel unterstützt werden kann. Idee bis CE 2015/12/02 11 / 34

12 Software als Medizinprodukt Medizinprodukt Manchmal ist es schwierig, Software abzugrenzen MEDDEVs sind Dokumente der Europäischen Kommission Rechtlich nicht bindend Liefern gute Hilfestellungen MEDDEV 2.1/6 MEDDEV 2.1/6 enthält auf Seite 9 einen Entscheidungsbaum betreffend Software als Medizinprodukt 6_ol_en.pdf office@rnb-consulting.at Idee bis CE 2015/12/02 12 / 34

13 Software als Medizinprodukt Medizinprodukt Es handelt sich um ein Medizinprodukt, weil: der Verlauf einer Krankheit überwacht wird die Software Therapie-Empfehlungen gibt der Arzt seine Medikation auf den Informationen der Software aufbaut Tagebuch-App Wäre es eine reine Tagebuch-App ohne Medikationsempfehlung, würde es sich um kein Medizinprodutk handeln! Idee bis CE 2015/12/02 13 / 34

14 Klassifizierung Medizinprodukte-Klasse Die Klassifizierung richtet sich nach der Zweckbestimmung des Produktes. Lupus Die Software ist dazu bestimmt, Aufzeichnungen über die Schmerzbehandlung von Kindern zu machen. Auf Basis der Aufzeichnungen werden Therapieempfehlungen für den Arzt gegeben und eine Verlaufskontrolle ist möglich. Idee bis CE 2015/12/02 14 / 34

15 Klassifizierung Medizinprodukte-Klasse Anhang IX der Richtlinie 93/42/EWG enthält eine Reihe von Klassifikations-Regeln Eigenständige Software ist ein aktives Medizinprodukt Aktives diagnostisches Medizinprodukt Informationen über Überwachung oder Behandlung Regel 12: Alle anderen aktiven Produkte werden der Klasse I zugeordnet. Richtlinie 93/42/EWG &uri=CELEX:01993L office@rnb-consulting.at Idee bis CE 2015/12/02 15 / 34

16 Normen Ausgewählte Normen EN ISO 13485:2012 Medizinprodukte Qualitätsmanagementsysteme Anforderungen für regulatorische Zwecke EN ISO 14971:2012 Medizinprodukte Anwendung des Risikomanagements auf Medizinprodukte EN 62304:2006 Medizingeräte-Software Software-Lebenszyklus-Prozesse EN 62366:2008 Medizinprodukte Anwendung der Gebrauchstauglichkeit auf Medizinprodukte Idee bis CE 2015/12/02 16 / 34

17 Normen EN Die EN macht kaum konkrete Vorgaben Der Hersteller ist selbst verantwortlich für die Auswahl und Implementierung von einem äußeren QM-System einer geeigneten Organisationsstruktur einem geeigneten Software-Lebenszyklusmodell den einzelnen Aktivitäten und Aufgaben Sie liefert damit Rahmenvorgaben für die Entwicklung medizinischer Software Idee bis CE 2015/12/02 17 / 34

18 Normen Bezug zum Risikomanagement Die EN fordert einen Risikomanagementprozess nach EN ISO In vielen Bereichen der Norm ist Risikomanagement gefordert Herangehensweise an Planung, Design, Umsetzung, Implementierung, Testen,... ist risiko-basierend Der Risikomanagementprozess in der EN findet immer begleitend statt Es wird von Seiten der EN auf das Risikomanagement nach EN ISO verwiesen Idee bis CE 2015/12/02 18 / 34

19 Normen Bezug zur EN ISO Die EN setzt ein bestehendes Qualitätsmanagementsystem voraus Dieses muss nicht zwangsweise nach EN ISO sein Die EN ISO ist jedoch im medizinischen Bereich weit verbreitet Sie baut auf der ISO 9001 auf Sämtliche Prozesse, Aktivitäten und Aufgaben finden eingebettet in ein QM-System statt Idee bis CE 2015/12/02 19 / 34

20 Software-Sicherheitsklassifizierung Software-Sicherheitsklassifizierung Ähnlich der Medizinprodukte-Klassen gibt es Sicherheitsklassen für Software Richten sich ebenfalls nach dem Gefährdungspotential der Software für Patient Bediener Andere Personen Sind nach außen hin (im Gegensatz zur Medizinprodukte-Klasse) nicht sichtbar (zb im Handbuch) Idee bis CE 2015/12/02 20 / 34

21 Software-Sicherheitsklassifizierung Software-Sicherheitsklassifizerung Zur Abgrenzung werden die drei Software-Sicherheitsklassen mit Buchstaben bezeichnet A Keine Verletzung oder Schädigung der Gesundheit ist möglich B Keine schwere Verletzung ist möglich C Tod oder schwere Verletzung ist möglich Rührt die Gefährdung daher, dass das Software-System sich nicht entsprechend seiner Spezifikation verhält, muss die Wahrscheinlichkeit einer solchen Fehlfunktion als 100 Prozent angenommen werden Durch Hardware-Kontrollmaßnahmen kann die Sicherheitsklasse um eine Klasse verringert werden office@rnb-consulting.at Idee bis CE 2015/12/02 21 / 34

22 Software-Sicherheitsklassifizierung Software-Sicherheitsklassifizerung Allgemein gilt für die Software-Sicherheitsklassen: A nur einige Teile der EN sind anzuwenden B die meisten Aspekte der EN sind anzuwenden C alle Teile der EN sind anzuwenden Im Anhang der Norm findet sich eine Tabelle, die die anwendbaren Aktivitäten für die jweilige Software-Sicherheitsklasse auflistet office@rnb-consulting.at Idee bis CE 2015/12/02 22 / 34

23 Software-Sicherheitsklassifizierung Software-Sicherheitsklassifizierung Der Kontext der Anwendung muss bei der Bestimmung der Sicherheitsklasse mitbeachtet werden Kernfrage: Wie kritisch ist eine Anomalie der Software? Team Beantwortung der Frage nur im Team mit Medizinern möglich! Idee bis CE 2015/12/02 23 / 34

24 Software-Entwicklungsprozess Planung der Software-Entwicklung Software- Risikomanagement Dokumentation Software- Konfigurationsmanagement Software- Entwicklungsplan Normen, Methoden und Werkzeuge der Entwicklung Software- Integration und Integrationsprüfung Software- Verifizierung Idee bis CE 2015/12/02 24 / 34

25 Software-Entwicklungsprozess Software-Anforderungen spezifizieren Hilfsmittel wie User Stories oder Use-Cases liefern Eingaben für die Software-Anforderungen Endgültige Software-Anforderungen sollten zunächst nicht zu detailliert ausfallen Diese Anforderungen sind Teil des Lastenheftes Später werden sie als Teil des Pflichtenheftes genauer definiert Beispiele SRQ1 SRQ2 SRQ3 SRQ4 Eingabemöglichkeit für Ausmaß der Schmerzen Eingabemöglichkeit für den Ort der Schmerzen Darstellung der Schmerzen über die Zeit (Verlauf) Eingabemöglichkeit für die Medikation Idee bis CE 2015/12/02 25 / 34

26 Risikomanagement Risikomanagement Risikomanagement findet immer begleitend statt Ganz am Anfang Initiale Risikoanalyse Es können sich daraus neue Anforderungen ergeben Risikomanagement Datenübertragung zum Arzt funktioniert nicht Versehentliche Eingabe falscher Daten Fehlerhafte Darstellung im Verlauf Idee bis CE 2015/12/02 26 / 34

27 Verifikation und Validierung Verifikation & Validierung Verifikation Testen gegen das Pflichtenheft Am I building the thing right? Validierung Testen gegen das Lastenheft Am I building the right thing? office@rnb-consulting.at Idee bis CE 2015/12/02 27 / 34

28 Klinische Bewertung Klinische Bewertung Notwendigkeit abgeleitet aus Richtlinie 93/42/EWG Anhang I (Grundlegende Anforderungen): Klinische Bewertung muss mit eingeschlossen werden Anhang X detailliert den Ablauf der klinischen Bewertung Drei mögliche Abläufe Kritische Bewertung der verfügbaren wissenschaftlichen Literatur Kritische Bewertung sämtlicher durchgeführter klinischer Studien Eine Kombination aus beiden Das nationale Gesetz verweist, zumindest in Österreich, nur auf die Richtlinie office@rnb-consulting.at Idee bis CE 2015/12/02 28 / 34

29 Freigabe und Follow-Up Freigabe Ist das Produkt fertig entwickelt und sind alle Dokumente vollständig Freigabe Idee bis CE 2015/12/02 29 / 34

30 Freigabe und Follow-Up Post-Market Phase Nach der Markteinführung ist der Hersteller noch nicht aus der Pflicht Muss seine Dokumente aktuell halten: Risikomanagement Klinische Bewertung Marktbeobachtung (Vorfälle mit ähnlichen Produkten,...) Ein Vigilanz-System ist daher erforderlich Idee bis CE 2015/12/02 30 / 34

31 Zusammenfassung Zusammenfassung Überblick über die Entwicklung einer neuen App Regulatorische Rahmenbedingungen Planung der Software-Entwicklung Klinische Bewertung Freigabe Post-Market Phase Idee bis CE 2015/12/02 31 / 34

32 Über Uns R n B Medical Software Consulting GmbH R n B Medical Software Consulting GmbH DI(FH) Dr. Michael Ring DI(FH) Dr. Andreas Böhler, MLBT Starker technischer Hintergrund Mehrjährige Erfahrung in der Entwicklung und Zulassung medizinischer Software Breites Fachwissen in Medizin, Technik und Recht office@rnb-consulting.at Idee bis CE 2015/12/02 32 / 34

33 Über Uns Leistungen Leistungen Individuelle Schulungen Praxisnahe Vermittlung regulatorischer Grundlagen Begleitende Dokumentenprüfung und Prozessanalysen Unterstützung bei der klinischen Bewertung Hilfestellung bei Einführung und Validierung von Werkzeugen für die Entwicklung Begleitung der Einführung neuer Technologien Klärung datenschutzrechtlicher Probleme Philosophie Wir verstehen uns als langfristige Begleiter während des gesamten Lebenszyklus medizinischer Software Idee bis CE 2015/12/02 33 / 34

34 Über Uns Leistungen Fragen Für weitere Fragen stehen wir gerne zur Verfügung! DI(FH) Dr. Andreas Böhler, MLBT R n B Medical Software Consulting GmbH Grillparzerstraße Linz andreas.boehler@rnb-consulting.at office@rnb-consulting.at Idee bis CE 2015/12/02 34 / 34