Zur medizinischen Software zählt alle Software, die für das Gesundheitswesen eingesetzt wird, insbesondere Software für Medizinprodukte bzw. Medizingeräte (Embedded Software) und Software, die selbst ein Medizinprodukt ist (Standalone-Software).
Die IEC/CD1 82304-1 (Health Software – Part 1: General requirements for product safety) unterscheidet folgende Begriffe:
Damit wird klar, dass medizinische Software ein Medizinprodukt sein kann, aber nicht muss.
Abb. 1: Medizinische Software umfasst auch Medical Device Software und Software as a Medical Device (zum Vergrößern klicken).
Es stellt sich oft die Frage, wann medizinische Software der Definition des Begriffs Medizinprodukt entspricht. Eine weiterführende Diskussion dazu finden Sie im Artikel zur Klassifizierung von Software als Medizinprodukt sowie im Artikel zur Qualifizierung und Klassifizierung von IVD-Software.
Software, die ein Medizinprodukt oder ein Teil dessen ist, muss die regulatorischen Anforderungen erfüllen:
Lesen Sie hier mehr zum Thema gesetzeskonforme Software-Entwicklung und IEC 62304. Beachten Sie auch den Podcast zum Thema medizinische Software. Beachten Sie auch den Artikel zu den klinischen Informationssystemen z.B. zu den Patientendaten-Managementsystemen (PDMS).
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.
Gemeinsam mit dem TÜV SÜD, dem TÜV Nord und mit Unterstützung von Dr. Heidenreich (Siemens) hat das Johner Institut am 21.11. einen Leitfaden zur IT-Sicherheit speziell für Medizinproduktehersteller veröffentlicht.
Die IEC 62443-4-1 ist Teil einer Normenfamilie zur „IT-Sicherheit für industrielle Automatisierungssysteme“. Dieser Artikel stellt Ihnen den Teil 4-1 vor, der Anforderungen an den Lebenszyklus (Entwicklung, Wartung) von sicheren Produkten stellt. Er untersucht auch, ob diese Norm für Hersteller von Medizinprodukten sinnvoll anwendbar ist.
WeiterlesenLOINC, die Logical Observation Identifiers Names and Codes, sind ein vom Regenstrief Institute gepflegtes System, um v.a. Laborparameter und Vitaldaten semantisch eindeutig zu verschlüsseln. Zunehmend findet das System auch in Deutschland Beachtung, auch von den Medizintechnik-Unternehmen. Die FDA legt diesen semantischen Standard besonders den IVD-Herstellern nahe. Mit Recht! Inhaltsübersicht Ziele von LOINC » Achsen » Zusammenspiel…
WeiterlesenSoftware-Systeme sollten aus Komponenten bestehen, die über Software-Schnittstellen miteinander kommunizieren. Dieser Artikel beschreibt, wie Sie Software-Schnittstellen dokumentieren können. Dabei zeigt er Konzepte, die sich nicht nur auf interne und externe Software-Schnittstellen, sondern auch auf Hardware-Schnittstellen übertragen lassen.
WeiterlesenFuzz-Testing ist eine Methode zur Identifizierung bisher nicht-erkannter Schwachstellen und Sicherheitslücken in Software (stand-alone oder embedded), die die Schnittstellen der Systeme automatisiert mit korrekten oder falschen Werten testet.
Unter einem Security Patch versteht man eine Nachbesserung an einer Software, um eine Sicherheitslücke zu stopfen. Für einen Security Patch gelten teilweise andere regulatorische Anforderungen als an andere Software Updates. Auf was Sie achten müssen, erfahren Sie in diesem Beitrag.
Der UL 2900-2-1 nennt sich „Particular Requirements for Network Connectable Components of Healthcare and Wellness Systems“. Er zählt zur UL-2900-Familie, der Normenfamilie zur IT-Security. Lesen Sie in diesem Artikel, welche Schwächen der Standard hat und unter welchen Umständen er Ihnen dennoch nützlich sein kann.
WeiterlesenDie IEC 62304 hat das Konzept der Sicherheitsklassifizierung eingeführt, damit Medizinproduktehersteller den Aufwand für die Software-Dokumentation an den Grad möglicher Schäden anpassen können, die durch einen Softwarefehler verursacht würden. Dieser Artikel hilft Ihnen, die Sicherheitsklassen zu bestimmen und IEC 62304 konform zu dokumentieren. Update: Keine Konformitätsvermutung mehr bei Sicherheitsklasse A? Mehr…
WeiterlesenDieser Artikel beschreibt die Anforderungen der In-vitro Diagnostic Regulation IVDR an die Entwicklung und Dokumentation der Software. Die Anforderungen betreffen sowohl Software, die Teil eines IVDs ist (embedded Software), als auch Software, die selbst ein IVD darstellt (standalone Software). Ebenso finden Sie in diesem Beitrag einen Vergleich der Anforderungen der MDR und der IVDR an die Software.
WeiterlesenLegacy Software definiert die IEC 62304 in deren neuen Ammendment I als Software (Teil eines Medizinprodukts oder eigenständige Software), die zum damaligen Zeitpunkt legal in Verkehr gebracht wurde, aber heutigen Anforderungen (insbesondere der IEC 62304) nicht mehr genügt. Update: Abgrenzung von Legacy Software, SOUP und OTS
Weiterlesen