Medizinproduktehersteller müssen die Software-Anforderungen spezifizieren und dokumentieren, und zwar unabhängig von der Sicherheitsklasse dieser Software.
Inhalt
Diese Seite verschafft Ihnen einen schnellen Überblick und verlinkt zu weiterführenden Artikeln.
Eine Software-Anforderungsspezifikation (englisch: Software Requirements Specification, SRS) soll dem Software-Entwicklungsteam die Informationen geben, mit denen es möglichst ohne weitere Rückfragen die Software entwickeln kann.
Weder die IEC 62304 noch die FDA definieren den Begriff Software-Anforderungen (engl.: Software Requirements).
Die Definition des Begriffs „Anforderung“ in der ISO 9000:2015 ist nur bedingt hilfreich:
„Erfordernis oder Erwartung, das oder die festlegt, üblicherweise vorausgesetzt oder verpflichtend“
Aber Beispiele helfen, den Begriff Software-Anforderungen zu verstehen:
Eine Software-Anforderungsspezifikation (SRS) sollte beispielsweise beschreiben,
Beide Begriffe sind nicht identisch. Die Software-Anforderungen beschreiben die Anforderungen allgemein. Die Software-Spezifikation gibt vor, wie diese Anforderungen umgesetzt werden sollen. Hier einige Beispiele zur Erläuterung:
| Software-Anforderung | Software-Spezifikation |
| Das Software-System / die Software muss den Patientennamen anzeigen. | Das System zeigt den Patientennamen in 18 Punkt Arial 20 Pixel vom rechten Bildschirmrand (gemäß Mockup-Screen X) an. |
| Die Software muss die Daten per HL7 an angeschlossene Nachbarsysteme verschicken können. | Sobald ein neuer Patient erfasst wird, schickt das System über die Datenschnittstelle X eine HL7-V2.6 ADT-A01-Nachricht, wobei das System als „KIS“ im MSH Segment als sendendes System eingetragen ist. |
| Die Software muss die Daten mit 1024-Bit-Verschlüsselung intern ablegen. | — |
Wir empfehlen die Erstellung einer Software-Spezifikation, weil die Prüfungen (z. B. Tests) präzise Vorgaben benötigen.
MDR und IVDR fordern zwar nicht explizit eine Software-Anforderungsspezifikation, aber die Verifizierung der Software. Die ist nur möglich, wenn es eine Spezifikation gibt, gegen die der Hersteller verifizieren kann. Genau das sind Software-Spezifikation bzw. Software-Anforderungen.
Die IEC 62304 verpflichtet die Hersteller im Kapitel 5.2, die Software-Anforderungen zu spezifizieren und diese Spezifikation zu verifizieren (Tipps unten beachten).
Die Anforderungen an die Software müssen beispielsweise betreffen:
Die Vorgaben der IEC 62304 in Kapitel 5.2 sind suboptimal formuliert. Die Norm bringt die verschiedenen Aspekte der ISO 25010, auf der sie basiert, durcheinander. Sie verwechselt Stakeholder-Anforderungen und Software-Anforderungen, ebenso Software-Anforderungen und Vorgaben für die Software-Architektur.
Die FDA erkennt die IEC 62304 als „recognized standard“ an. Aber die relevantesten Vorgaben an die Software-Anforderungen formuliert die Behörde in ihrer Leitlinie zur Software Validation.
Das Guidance-Dokument Content of the premarket submission gibt vor, welche Unterlagen Hersteller einreichen müssen. Darin macht die FDA auch Vorgaben für die Software Requirements Specification.
Das Johner Institut empfiehlt, Software als Blackbox zu spezifizieren, d. h. über dessen externe Schnittstellen.
| Schnittstellentyp | Elemente der SRS |
| Benutzerschnittstelle (UI) | Spezifikation des statischen Aussehens der UI, z. B. mit Mockups und Styleguides
Beschreibung des dynamischen Verhaltens, z. B. mit interaktiven Mockups und Prototypen oder mithilfe von Diagrammen für den „Screen flow“ |
| Datenschnittstellen | Beschreibung aller vier Ebenen des Interoperabilitätsmodells
Angabe „nicht-funktionaler“ Aspekte wie Zeitverhalten und Umgang mit fehlerhaften Inputs (Fehlertoleranz) |
| Schnittstelle zur Laufzeitumgebung | Spezifikation aller erlaubten Kombinationen von Hardware (CPU, I/O, Festplatte, RAM, Bildschirmgrößen und Auflösungen etc.) und Software (Betriebssystem, Browsertypen und -versionen, Firewalls etc.) |
Hersteller können die Software Requirements Specification sogar gemäß dieser Aufteilung strukturieren (s. Tipp 4).
Die ISO 25010 bietet eine sehr hilfreiche Taxonomie der Qualitätseigenschaften von Software. Diese lässt sich gut als Checkliste nutzen, um die Vollständigkeit der Anforderungen zu überprüfen. Besonders wirksam ist diese Methode, wenn sie mit den Schnittstellentypen (s. Tipp 1) kombiniert wird.
Beispiel für eine Frage, die sich daraus ergibt:
„Ist für die Nutzungsschnittstelle festgelegt, wie schnell diese auf Benutzereingaben reagieren muss?“
Sie können sich diese Arbeit sogar sparen, wenn Sie die Checkliste des Johner Instituts heranziehen.
Sie können die Checkliste hier kostenfrei herunterladen.
Als Kapitelstruktur für die Software Requierements Specification empfehlen sich weder die Struktur des Kapitels 5.2 der IEC 62304 noch die Struktur der ISO 25010.
Hilfreicher ist die folgende Kapitelstruktur:
Nutzen Sie die Templates im Auditgarant. Mit diesen Mustern sparen Sie viel Zeit beim Strukturieren und Dokumentieren Ihrer Software-Anforderungen.
Eine SRS sollte so kurz wie möglich, aber so ausführlich wie nötig sein.
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 Produkte schnell in den Markt kommen.
Der TIR45 („Guidance on the use of AGILE practices in the development of medical device software“) ist ein Technical Information Report (daher TIR) der AAMI, der Association for the Advancement of Medical Instrumentation. Der 2012 erstmalig veröffentlichte TIR45 hat sich vor allem ein Ziel gesetzt: Medizinprodukte-Herstellern eine Anleitung zu geben, wie sie Software agil und…
WeiterlesenIEC 62304 2. Ausgabe: Selbst der Name der neusten Ausgabe der Norm ist derzeit noch unklar: Heißt sie wieder IEC 62304? Vielleicht IEC 62304 Version 2? Oder wird man sie unter dem Mantel der Health-Software-Normen als IEC 82304-2 publizieren? Was bereits teilweise feststeht, sind die Änderungen, die die 2. Ausgabe der IEC 62304 vorsieht. Welche das sind,…
WeiterlesenViele Medizinproduktehersteller schwören auf die agile Softwareentwicklung. Der nicht nur rechtlichen Implikationen ist man sich aber häufig nicht bewusst.
LOINC, 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.
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
WeiterlesenDie FDA hat das Guidance Dokument ‚Interoperable Medical Devices‘ am 6. September 2017 veröffentlicht. Die US-Behörde möchte damit der Tatsache Rechnung tragen, dass einerseits die Interoperabilität von Medizinprodukten immer wichtiger für die Gesundheitsversorgung wird. Andererseits führen Probleme mit mangelnder Interoperabilität immer häufiger zu Risiken. Dieser Beitrag verschafft Ihnen einen schnellen Überblick über die Anforderungen der FDA…
Weiterlesen
„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.
WeiterlesenSoftware-Systemtest: Was versteht man genau darunter? Wann sind sie vorgeschrieben? Was sollten Software-Systemtests testen? Auf welche Fallen sollten Sie achten? Antworten gibt Ihnen dieser Beitrag.
