Medizinische Apps smarte Helfer oder komplexe Medizinprodukte?

Transkript

1 White Paper Medizinische Apps smarte Helfer oder komplexe Medizinprodukte? Apps für Smartphones und Tablets können Diagnosen erleichtern und die Therapietreue steigern. Als medizinische Software können sie dabei unter das Medizinproduktegesetz bzw. die Medizinprodukterichtlinie fallen müssen es aber nicht. Entscheidend ist der bestimmungsgemäße Gebrauch, den der Hersteller festlegt. Doch was verlangt eine Zertifizierung und welche Gesetze müssen berücksichtigt werden? Das TWT-Digital-Health-White-Paper Medizinische Apps smarte Helfer oder komplexe Medizinprodukte? fasst den aktuellen Stand der Diskussion zusammen. Einleitung Für Hersteller und Anwender können medizinische Applikationen ( Medical Apps ) eine erhebliche Vereinfachung von Prozessen bedeuten, sie sind jedoch nicht ohne Risiko. Denn die europäischen Medizinprodukterichtlinien definieren, wann Software ein Medizinprodukt ist leider tun sie das sehr abstrakt und damit nur schwer nachvollziehbar. Auf der anderen Seite werden klare Vorgaben für solche Medizinprodukte definiert, mit erheblichen Auswirkungen auf die haftungsund wettbewerbsrechtliche Verantwortlichkeit des Herstellers. In diesem Spannungsfeld ist es für jede Firma wichtig, sich damit auseinanderzusetzen, ob eine in Verwendung befindliche Software hier betroffen ist. Dazu gehören nicht nur Bestandteile diagnostischer oder therapeutischer Systeme, sondern auch sogenannte Stand-alone- Software-Produkte, etwa Applikationen im Pharmabereich wo die Steigerung der Compliance das beherrschende Thema ist und im Self-Measurement-Bereich (Fitnesstracker). Das White Paper Medizinische Apps smarte Helfer oder komplexe Medizinprodukte? wirft zunächst einen Blick auf die rechtlichen Rahmenbedingungen auf Basis des Medizinproduktegesetzes (MPG) und der Medizinprodukterichtlinie (MDD) und stellt die relevanten Verordnungen vor vom Inverkehrbringen bis zur Marktbeobachtung und Meldung von Zwischenfällen. Im nächsten Abschnitt wird anhand konkreter Beispiele die Frage Medizinprodukt ja oder nein? erörtert. Anhand von Beispielen wird u.a. erläutert, wie eine Risikoanalyse aussieht, welche Schritte eine Inhalt Einleitung 1 Rechtliche Rahmenbedingungen 2 Medizinprodukt ja oder nein? 4 Normen für medizinische Software 6 Besondere Herausforderungen für Medizin-Software 7 Best Practice bei der Software-Entwicklung 7

2 2 Software im Laufe ihres Lebenszyklus durchläuft und welche Normen relevant sind. Abschließend stellen wir Ihnen anhand von Best-Practice- Beispielen vor, was es bei der Planung und Realisierung von Software- Projekten zu beachten gibt. Rechtliche Rahmenbedingungen Mit der Veröffentlichung der überarbeiteten Medizinprodukterichtlinie 93/42/EWG hat die EU im September 2007 Medizinprodukte klar definiert als Gegenstände, Instrumente, Software, die vom Hersteller zur Anwendung für Menschen mittels ihrer Funktionen zu folgenden Zwecken bestimmt sind : Erkennung, Verhütung, Überwachung, Behandlung oder Linderung von Krankheiten Erkennung, Überwachung, Behandlung, Linderung oder Kompensierung von Verletzungen oder Behinderungen Untersuchung, Ersetzung oder Veränderung des anatomischen Aufbaus oder eines physiologischen Vorgangs Empfängnisregelung In diese Kategorien fallen auch viele Applikationen, die von pharmazeutischen oder medizintechnischen Herstellern angeboten werden. Nicht alle sind aber Medizinprodukte im Sinne des MPG. Entscheidend ist der bestimmungsgemäße Gebrauch oder Intended Use, den der Hersteller festlegt. Die Zweckbestimmung beschreibt, wie das Produkt der Diagnose, Therapie oder Überwachung von Krankheiten oder Verletzungen oder physiologischer oder anatomischer Parameter dient und definiert darüber hinaus: die vorgesehene Patientengruppe (ggf. einschließlich Alter, Gesundheitszustand und Gewicht) die betreffende Körperregion (bzw. das betreffende Gewebe) erforderliche Benutzerkenntnisse (z.b. Beruf, Ausbildung, Fachund Sprachkenntnisse) den Benutzungskontext (Kernaufgaben, Häufigkeit der Anwendung, zu erzielende Ergebnisse) den Ort der Anwendung (Helligkeit, Temperatur, Luftfeuchtigkeit etc.) Die Zweckbestimmung beschreibt, wie das Produkt der Diagnose, Therapie oder Überwachung von Krankheiten oder Verletzungen oder physiologischer oder anatomischer Parameter dient. Daneben sind gegebenenfalls weitere benötigte Informationen zum Produktlebenszyklus erforderlich, etwa zu: Lagerung und Transport Installation Wartung und Reinigung

3 3 Handelt es sich bei dem Produkt nicht um eine In-vitro-Diagnostik oder ein aktiv implantierbares Gerät, findet die Medizinprodukterichtlinie für Medical Devices (Medical Device Directive, MDD, 93/42/EWG) Anwendung. Sie umfasst sehr unterschiedliche Kategorien, daher sind die grundlegenden Anforderungen nicht sehr spezifisch, sie verweist stattdessen auf Normen. Im Anhang IX der Richtlinie sind Klassifizierungsregeln beschrieben. Inverkehrbringen Der Lebenszyklus eines Produktes beginnt mit der ersten Idee zu diesem Produkt und der daraus resultierenden Zweckbestimmung. Sobald die anzuwendenden Richtlinien und die Klassifizierung eines Produktes feststehen, muss ein Konformitätsbewertungsverfahren durchgeführt werden. Dabei werden die zu erfüllenden grundlegenden Anforderungen ermittelt sowie die Strategie zum Nachweis ihrer Erfüllung festgelegt. Das ausgewählte Konformitätsbewertungsverfahren legt auch fest, ob der Hersteller zur Feststellung der Konformität eine sogenannte benannte Stelle hinzuziehen muss. Handelt es sich um Medizinprodukte der Klasse I, darf der Hersteller selbst die Konformität mit der Medizinprodukterichtlinie erklären. Bei Medizinprodukten höherer Klassen muss er eine benannte Stelle beteiligen, die u.a. den Entwurf und die Fertigung überprüft. Diese Stelle muss entsprechend akkreditiert sein, in Deutschland wird diese Aufgabe häufig vom TÜV übernommen. Sobald die anzuwendenden Richtlinien und die Klassifizierung eines Produktes feststehen, muss ein Konformitätsbewertungsverfahren durchgeführt werden. Das Verfahren zur Konformitätsbewertung muss frühzeitig in der Produktentwicklung verankert sein, denn viele Aspekte wie die technische Dokumentation müssen bereits während der Entwicklung erstellt werden. Seit Inkrafttreten der neuen Richtlinie im Jahr 2010 ist eine klinische Bewertung für jedes Produkt ein zwingend erforderlicher Teil der Konformitätsbewertung eines Medizinproduktes. Sie kann im einfachsten Fall auf vorhandener Literatur basieren, wenn die zugrunde liegenden Daten für ein sowohl technologisch als auch bezüglich der Zweckbestimmung vergleichbares Produkt erhoben wurden. Ansonsten ist eine klinische Prüfung erforderlich. Abschluss der Konformitätsbewertung ist die Konformitätserklärung, mit der ein Hersteller versichert, alle geltenden Bestimmungen für das Produkt berücksichtigt und erfüllt zu haben. Bei Geräten kann er das durch Anbringung der CE-Kennzeichnung deutlich machen. Letzter Schritt vor dem Inverkehrbringen ist dann die Registrierung des Produkts, in Deutschland ist dafür das DIMDI (Deutsches Institut für Medizinische Dokumentation und Information) zuständig. Danach darf das Produkt in der EU verbreitet werden.

4 4 Postmarket Evaluation Auch nach der Markteinführung muss ein Hersteller das Produkt solange weiter beobachten, bis das letzte Gerät bzw. die letzte Anwendung außer Betrieb genommen wurde. Er muss u.a. sicherstellen, dass er Rückmeldungen von Kunden erhält, diese bewertet und bei Bedarf Reaktionen in die Wege leitet. Dazu existiert ein nationales Meldesystem am BfArM (Bundesinstitut für Arzneimittel und Medizinprodukte). Hersteller müssen die dort veröffentlichten Meldungen proaktiv sichten und ggf. Maßnahmen einleiten. Haftung Wenn der Hersteller Anforderungen ignoriert oder Software nicht korrekt evaluiert, kann er gemäß Medizinproduktegesetz sanktioniert werden. Zudem kann das Inverkehrbringen eines Medizinproduktes ohne entsprechende Kennzeichnung ein Verstoß gegen das Gesetz gegen den unlauteren Wettbewerb (UWG) bedeuten. Risiko Das Risiko eines Medizinproduktes ergibt sich aus der Kombination des Schweregrads eines Schadens und der Wahrscheinlichkeit seines Auftretens. Man unterscheidet: niedrige, d.h. akzeptable Risiken (z.b. reversible Schädigung wie Hautjucken ohne die Notwendigkeit einer ärztlichen Behandlung) zu hohe, d.h. nicht akzeptable Risiken (z.b. eines schweren Hautekzems, das einer ärztlichen Behandlung bedarf) den Zwischenbereich, dessen Risiko man oft als ALARP bezeichnet (as low as reasonable possible) Die Schwere eines Risikos ist auch vom Einsatzbereich abhängig, so hat ein Dialysegerät immer ein höheres Risiko als z.b. eine Gehhilfe. Medizinprodukt ja oder nein? Die FDA in den USA definiert Software-Anwendungen als Mobile Medical Applications (Apps) unabhängig davon, ob sie über eine drahtlose Verbindung (WLAN oder 4G/3G) verfügen oder nicht. Aus dieser Definition entwickelte sich ebenfalls unabhängig vom Zugangsweg auch eine halbwegs praktikable Unterscheidung in Anwendungen, die als Medizinprodukte registriert werden müssen und andere. Medizinprodukte dienen der Diagnostik, der Therapie und der Überwachung von Vitalparametern.

5 5 Apps, die als Medizinprodukte zu klassifizieren sind, haben demnach folgende Anwendungen: dient der Diagnostik dient der Therapie dient der Überwachung von Vitalparametern Apps, die NICHT als Medizinprodukte zu klassifizieren sind, haben z.b. folgende Anwendungen: dient nur der Dokumentation bzw. Abrechnung dient der Ausbildung bzw. Schulung sind nicht spezifisch für Medizin (z.b. digitale Lupe) Zur weiteren Klärung der Einordnung von Software als Medizinprodukt hat die EU-Kommission am 12. Januar 2012 mit dem MEDDEV-Leitfaden 2.1/6 eine entsprechende Empfehlung abgegeben. Aber auch bei konsequenter Anwendung aller Kriterien gibt es Beispiele für Apps, die in einen Graubereich fallen und einzeln zu bewerten sind. Dazu gehören: Apps, die Patienten im Alltag unterstützen (z.b. bei der Einnahme von Medikamenten) Apps, mit denen Patienten Werte dokumentieren und verfolgen (z.b. Blutdruck, Schmerzen) Apps, die Patienten spezifische Informationen über ihre Krankheit zur Verfügung stellen Apps, mit denen Patienten mit ihren Ärzten kommunizieren oder die Zugriff auf klinische Informationssysteme erlauben Apps, die einfache Berechnungen durchführen (Score-Rechner, z.b. BMI-Rechner) Zusammengefasst heißt das: Die Entscheidung, ob eine App ein Medizinprodukt ist, obliegt zunächst einmal allein dem Hersteller. Rechtsverbindliche Entscheidungen treffen die Aufsichtsbehörden, wie Regierungspräsidien. Benannte Stellen beraten nur. In der Praxis ist es aktuell so, dass die Behörden ihrer Pflicht zur Marktüberwachung eher schleppend nachkommen. Das heißt aber nicht, dass Sie als Hersteller hier ohne Gefahr auf erforderliche Schritte in Sachen Qualitätssicherung und Konformität verzichten können. Denn letztlich hängt der Ruf eines Unternehmens gerade von solchen Faktoren ab. Sie sollten sich also schon bei der Planung unbedingt fachkundig beraten lassen. Die Entscheidung, ob eine App ein Medizinprodukt ist, obliegt zunächst einmal allein dem Hersteller.

6 6 Normen für medizinische Software Ist eine App ein Medizinprodukt, dann kommen die folgenden Normen zur Anwendung: Qualitätsmanagementsystem ISO Software- Lebenszyklus-Prozesse IEC Risikomanagement ISO Gebrauchstauglichkeit IEC Relevante Normen für die Entwicklung von Medizin-Software Qualitätsmanagement (EN ISO 13485) Die Norm EN ISO ist eine für Medizinprodukte-Hersteller angepasste Version der allgemeinen Qualitätsnorm ISO Sie legt Mindestanforderungen für Design und Entwicklung, Produktion und Installation sowie die Instandhaltung von Medizinprodukten und zugehörigen Dienstleistungen fest. Risikomanagement (EN ISO 14971) Die Norm EN ISO legt einen Prozess fest, mit dessen Hilfe die mit einem Medizinprodukt verbundenen Gefährdungen für Patienten, Anwender und Dritte identifiziert und beherrscht werden können. Risikomanagement-Aktivitäten müssen über den gesamten Lebenszyklus eines Medizinproduktes durchgeführt werden. Software-Lebenszyklus-Prozesse (EN 62304) Die Norm EN beschreibt Prozesse zur Herstellung und Wartung von Software. Ein wichtiger Teil ist die Wartung und Änderung von Software, für die die Norm eigene Prozesse beschreibt. Gebrauchstauglichkeit (EN 62366) Die EN legt Forderungen für die Analyse, Spezifikation, Entwicklung sowie Verifizierung und Validierung der Gebrauchstauglichkeit von Medizinprodukten fest. Sie berücksichtigt dabei nur sicherheitsrelevante Aspekte.

7 7 Besondere Herausforderungen für Medizin-Software Während Medizingeräte-Hersteller ihre eingebettete Software für genau eine Laufzeitumgebung (z.b. Hardware, Betriebssystem) entwickeln, müssen App-Entwickler eine Vielzahl an Plattformen unterstützen. Diese Vielfalt betrifft: Hardware (Rechenleistung, Bildschirmgröße und auflösung) Betriebssysteme (Probleme vor allem bei Android-Geräten) Runtime-Umgebungen (Java,.NET etc.) weitere Software (gleiche Plattform mit anderen Apps führt zu Problemen) Ihr Ansprechpartner Klaus Mueller Telefon Auch verschiedene Sprachen, Kulturkreise, intellektuelle und körperliche Fähigkeiten haben schwer vorhersagbare Auswirkungen auf das Nutzungsverhalten und damit auf Risiken. Werden Server-Funktionalitäten genutzt, kommen erweiterte Anforderungen an den Datenschutz sowie die Integrität und Verfügbarkeit der Daten hinzu. Sobald der Hersteller auch den Server betreibt (oder betreiben lässt), muss er auch die gesetzlichen Vorschriften beachten, die sich an die Betreiber wenden (z.b. Medizinproduktebetreiberverordnung). Best Practice bei der Software-Entwicklung Um die vielen Direktiven, Gesetze, Verordnungen, Richtlinien und Normen bei der Entwicklung medizinischer Software zu berücksichtigen, sollten Sie einem erfahrenen Partner wie TWT Digital Health vertrauen. Wir sind zertifiziert nach EN ISO und damit zugelassen für die Entwicklung und das Inverkehrbringen von Software und Apps im Gesundheitswesen. Unsere Leistungen umfassen: Anforderungsanalyse (nach ISO 13485) Software-Entwicklung (nach IEC 62304): Software-System-Requirements Software-Architektur Code-Review Tests Risikomanagement (nach ISO 14971) Klinische Evaluation (nach MDD, ISO 14971) Usability-Akte (nach IEC 62366) Dokumentation und Konformitätsbewertung (MDD) Inverkehrbringer von Software und Apps im Auftrag unserer Kunden Hosting und Betrieb Darüber hinaus werden wir unterstützt und beraten durch Prof. Dr. Christian Johner, Institut für IT im Gesundheitswesen Konstanz. Über TWT Digital Health TWT Digital Health steht für zukunftsweisende E-Health-Lösungen, medizinische Software, Healthcare- Apps und Gesundheitsmarketing. Mit einem erfahrenen Team aus Beratern, Entwicklern und Kreativen realisieren wir Prozesse, die Ihre Botschaft mit State-of-the-art-Technologie zur relevanten Zielgruppe bringen und die gleichzeitig den hohen Pharmastandards genügen. Und das seit TWT Digital Health