Standalone-Software (eigenständige Software) bezeichnet die EU-Medizinprodukteverordnung „Produkte in Form einer Software“. Allerdings ist diese Verordnung nur bei einem Teil der Standalone-Software anwendbar.
Inhalt
Diese Seite verschafft einen kurzen Überblick und referenziert Fachartikel für weitere Hintergrundinformationen.
Standalone-Software-Anwendungen sind eigenständige Produkte, die ohne Hardware in den Markt gebracht werden, sei es als Download (z. B. über einen App Store) oder auf einem physischen Datenträger (z. B. Flashdrive).
Standalone-Software, die für das Gesundheitswesen gedacht ist, ist nicht deckungsgleich mit Health-Software. Sie ist auch nicht deckungsgleich mit Medical Device Software (s. Abb. 1).
Abb. 1: Die Standalone-Software für das Gesundheitswesen ist eine Teilmenge der Health-Software (alle vier Quadranten).
Beispiele für Standalone-Software sind:
Hersteller müssen klären, ob ihre Standalone-Software als Medizinprodukt zählt. Wann dies der Fall ist, beleuchtet der Artikel zur Qualifizierung und Klassifizierung von Software als Medizinprodukt.
Falls die Standalone-Software als Medizinprodukt zählt („qualifiziert“), muss sie die gesetzlichen und normativen Anforderungen erfüllen. Diese unterscheiden sich nicht von den Anforderungen an Software, die Teil eines Medizinprodukts ist.
Lesen Sie hier mehr zum Thema gesetzeskonforme Software-Entwicklung und IEC 62304.
Insbesondere bei webbasierten Medizinprodukten tun sich die Hersteller schwer mit der Festlegung, welcher Teil zum Medizinprodukt zählt und welcher zur Laufzeitumgebung. Gehört beispielsweise der Applikationsserver dazu?
Es ist wichtig, diese Festlegung explizit zu dokumentieren.
Abb. 2: Webbasierte Medizinprodukte bestehen aus vielen Ebenen. Ein Teil zählt zur Software (Medizinprodukt), ein Teil zu dessen Laufzeitumgebung. SOUP sind Teil des Medizinprodukts.
Wenn die Software über App Stores bereitgestellt wird, stellt sich die Frage, wann die Inverkehrbringung erfolgt. Beim Upload in den Store? Beim Freischalten durch den Betreiber? Oder erst beim Download?
Dieser Artikel zur Inverkehrbringung gibt Antworten.
Die Laufzeitumgebungen, auf denen die Standalone-Software installiert wird, unterscheiden sich. Kaum ein Rechner gleicht dem anderen. Das gilt sowohl für Notebooks und Server als auch für Smartphones. So gibt es Tausende von Android-basierten Endgeräten.
Dies macht es den Herstellern schwer, das korrekte Funktionieren ihrer Software auf diesen Endgeräten zu überprüfen. Daher müssen sie diese einschränken oder risikobasiert testen.
Diese Vielfalt betrifft nicht nur die technische Umgebung, sondern auch die Nutzungsumgebungen und Nutzer. Wie sollen die Hersteller gewährleisten, dass tatsächlich nur die in der Zweckbestimmung vorgesehenen Nutzer die Geräte nutzen? Wie sollen sie antizipieren, unter welchen Umständen (z. B. beim Fahren, nachts, während des Sports) ihre Produkte genutzt werden?
Hier ist eine systematische Post-Market Surveillance unerlässlich, um die tatsächliche Nutzung zu verfolgen und ggf. darauf zu reagieren.
Im Gegensatz zu vielen physischen Produkten muss und kann Software in kurzen Entwicklungszyklen auf den Markt gebracht werden. Dies ist schon deshalb notwendig, weil Security-Patches aufgespielt werden müssen.
Dem gegenüber stehen allerdings langwierige Verfahren der Zulassungs- und Konformitätsbewertung.
Das Johner Institut digitalisiert die regulatorischen Prozesse und arbeitet an einer Real-Time Regulation.
Nutzen Sie die Unterstützung des Johner Instituts:
Melden Sie sich gleich, damit wir die nächsten Schritte besprechen können. So stellen Sie sicher, dass die „Zulassung“ sicher gelingt und Ihre Software bzw. Ihre Produkte schnell in den Markt kommen.
Die Einbindung von KI bei Medizinprodukten hat große Fortschritte gemacht, z. B. bei der Diagnose von Krankheiten. Hersteller von Produkten mit Machine Learning stehen vor der Herausforderung, die Konformität ihrer Produkte nachweisen zu müssen. Auch wenn Sie die Gesetzte kennen – welche Normen und Best Practices sind zu berücksichtigen, um die Nachweise zu führen und…
Weiterlesen
Der Begriff „Medizinprodukte-PC“ ist nicht eindeutig definiert. Allerdings verstehen unter einem Medizinprodukte-PC die meisten Abhängig von den Konstellationen müssen die Hersteller unterschiedliche regulatorische Anforderungen erfüllen. Diese werden im vorliegenden Artikel vorgestellt.
WeiterlesenWie unterscheiden sich Verifizierung und Validierung und wie sind diese Begriffe definiert? Selbst Normen und Gesetze verwenden die Begriffe falsch oder missverständlich. Erfahren Sie hier, wie Sie Ihre Medizinprodukte sicher durch Zulassungen und Audits bekommen – dank präziser Verifizierung und Validierung.
WeiterlesenGesetze und Normen formulieren Anforderungen, wie Medizinproduktehersteller den Entwicklungsprozess festlegen und dokumentieren müssen. Diese Anforderungen prüfen Benannte Stellen bei Audits. Dieser Artikel zum Entwicklungsprozess gibt Ihnen Tipps zu dessen Gestaltung und zum Abgleich mit anderen Prozessen wie dem Risikomanagementprozess.
Weiterlesen
Die Hersteller medizinischer Software müssen die gesetzlichen Anforderungen an die Software-Komponenten erfüllen, um ihre Produkte „zulassen“ zu dürfen. Dieser Artikel stellt diese Anforderungen vor und gibt 7 Tipps, wie diese schnell und einfach zu erfüllen sind.
WeiterlesenDas IMDRF (International Medical Device Regulators Forum) möchte zur Harmonisierung der international unterschiedlichen Vorschriften beitragen und dadurch die Zulassung von Medizinprodukten vereinheitlichen und vereinfachen. Dazu veröffentlichen die Freiwilligen des IMDRF Leitfäden, die zwar nicht verbindlich sind, aber Hilfestellungen geben. Dieser Artikel stellt Ihnen ausgewählte Leitfäden vor.
WeiterlesenSeit 2020 ermöglicht der Gesetzgeber die Erstattung von Digitale Gesundheitsanwendungen (DiGA). Die DiGA-Hersteller müssen dafür einige Voraussetzungen erfüllen. Dieser Artikel beschreibt die dazu notwendigen Schritte.
WeiterlesenDie Cybersecurity-Norm IEC 81001-5-1 befasst sich damit, wie IT-Sicherheit im Software-Lebenszyklus berücksichtigt werden muss. Als spezielle Norm für Gesundheitssoftware ergänzt sie unter anderem die IEC 82304-1 bzw. die IEC 62304 und kann Lücken schließen, die dringend geschlossen werden müssen. Die EU plant die Harmonisierung der IEC 81001-5-1 derzeit mit Zieldatum 24. Mai 2024. In diesem Beitrag…
WeiterlesenDie Anforderungen an die Datensicherheit und den Datenschutz von DiGA (Digitalen Gesundheitsanwendungen) gehen weit über den Fragenkatalog der DiGAV hinaus. Unzählige weitere Vorschriften machen es den Herstellern (nicht nur) digitaler Gesundheitsanwendungen immer schwerer, den Überblick im regulatorischen Dschungel zu bewahren. Dabei sollten Hersteller möglichst keine Anforderungen übersehen. Andernfalls drohen Probleme bei der Zulassung ihrer Produkte.…
Weiterlesen
Die MDR enthält speziell für Software eine Klassifizierungsregel: Regel 11. Diese Regel 11 hat Sprengkraft! Sie hat das Potenzial, die Innovationskraft in Europa weiter zu schwächen. Hersteller sollten die Interpretation der MDCG kennen, um Fehlklassifizierungen von Software zu vermeiden und um der Argumentation benannter Stellen und Behörden folgen zu können. Diese Interpretation lernen Sie in…
Weiterlesen