IEC 82304 – Was die Norm zu „Health Software“ fordert
Die IEC 82304 liegt inzwischen vor. Ein guter Anlass, sich diese Norm zu „Health-Software-Products“ näher anzusehen.
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. Auch für Open-Source-Software gelten gesetzliche Anforderungen.
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 IEC 82304 liegt inzwischen vor. Ein guter Anlass, sich diese Norm zu „Health-Software-Products“ näher anzusehen.
Ein Mock-Objekt hilft beim Integrationstest, Teile eines Software-Systems zu ersetzen bzw. zu simulieren, solange bis diese Teile schrittweise dem System hinzugefügt werden. Lesen Sie in diesem Artikel, wie sich Mocks von Dummies und Stubs unterscheiden und ob Sie ein Mock-Objekt auch verifizieren müssen.
DetailsDie Health Breach Notification Rule legt fest, wann Anbieter von Health Records welche Probleme mit der Datensicherheit an wen, in welcher Frist und in welcher Form melden müssen. Dieser Artikel verschafft Ihnen eine schnelle Übersicht über die Forderung der US-amerikanischen Federal Trace Commission (FTC).
„Findet ein Software-Audit statt?“ lautet eine Frage, die mich über unser Micro-Consulting erreicht. „Und kann ich durch eine geeignete Wahl der Software-Sicherheitsklasse so ein Software-Audit vermeiden?“ Erst ist mir weder klar, was genau mit „Software-Audit“ gemeint, noch was die genaue Befürchtung ist. Doch dann verstehe ich und finde die Frage sehr bedeutsam für alle Medizinprodukte-Hersteller.
DetailsDie FDA hat ein Interoperability Guidance als Entwurf veröffentlicht. Es trägt den Titel „Design Considerations and Pre-market Submission Recommendations for Interoperable Medical Devices“ (hier zum Download). Lesen Sie hier, was die FDA damit bezweckt und auf welche Anforderungen Sie sich einstellen müssen.
DetailsEine Schichtenarchitektur ist ein Architekturstil, der häufig bei Software-Systemen Anwendung findet. Vielen Herstellern sind die Nachteile eine mehrschichtigen Architektur und eines Denkens in Layern nicht bewusst.
Unter einem Hotfix verstehen die meisten Medizinprodukte-Hersteller die kurzfristige Behebung eines dringenden Software-Bugs. Bei diesen Hotfixes unterlaufen den Herstellern gravierende Fehler. Auch regulatorische. Lesen Sie hier, wie Sie die Software Ihrer Medizinprodukte durch einen Hotfix schnell und ohne Overhead aber dennoch gesetzeskonform updaten können.
DetailsIT-Netzwerke in Krankenhäusern unterscheiden sich — auch wenn die verwendeten Produkte und Technologien die gleichen sind — von IT-Netzwerken in anderen Branchen:
Mit FHIR (gesprochen: Fire) hat HL7 einen modernen Interoperabilitätsstandard entwickelt, dem ich großes Zukunftspotenzial zutraue. Erfahren Sie mehr über Interoperabilität.
DetailsDer Satz in der IEC 62304, der wahrscheinlich zu den meisten Diskussionen führt, ist der zur Wahrscheinlichkeit bei Software: „Wenn die GEFÄHRDUNG davon herrühren könnte, dass das SOFTWARE-SYSTEM sich nicht entsprechend seiner Spezifikation verhält, muss die Wahrscheinlichkeit einer solchen Fehlfunktion als 100 Prozent angenommen werden.“ Solange die zweite Ausgabe der IEC 62304 diese missverständlich Aussage nicht…
DetailsSie sehen gerade einen Platzhalterinhalt von Hubspot Embedded Content. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von HubSpot. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von Hubspot Meetings. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von reCAPTCHA. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr Informationen