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.

  1. Grundlagen (z. B. was Software-Anforderung und Software-Spezifikation unterscheidet)
  2. Regulatorische Anforderungen
  3. Tipps zum Spezifizieren der Software-Anforderungen
  4. Möglichkeiten der Unterstützung

1. Grundlagen

a) Ziele

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.

b) Definition

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:

Definition:  Anforderung

„Erfordernis oder Erwartung, das oder die festlegt, üblicherweise vorausgesetzt oder verpflichtend“

Quelle: ISO 9000:2015 (3.6.4)

Aber Beispiele helfen, den Begriff Software-Anforderungen zu verstehen:

Eine Software-Anforderungsspezifikation (SRS) sollte beispielsweise beschreiben,

  • welche Daten die Software einlesen, entgegennehmen bzw. verarbeitet muss,
  • welche Outputs sie in welcher Form wie schnell erzeugt,
  • wie sie die Daten verarbeiten muss,
  • wie die grafische Schnittstelle aussehen und sich bei Interaktion mit den Anwendern verhalten soll und
  • in welcher technischen Umgebung (z. B. Hardware) die Software lauffähig sein muss.

b) Abgrenzung von Software-Anforderungen und Software-Spezifikation

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.

2. Regulatorische Anforderungen

a) Europa

EU-Richtlinien

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.

IEC 62304

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:

  • Inputs und Outputs, z. B. die Benutzungsschnittstelle
  • Technische Umgebung wie Hardware
  • IT-Sicherheit
Vorsicht!

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.

b) USA

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.

3. Fünf Tipps für die Software-Anforderungen

Tipp 1: Blackbox-Modell nutzen

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).

Tipp 2: ISO 25010 verwenden

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?“

Tipp 3: SRS-Checkliste nutzen

Sie können sich diese Arbeit sogar sparen, wenn Sie die Checkliste des Johner Instituts heranziehen.

Download

Sie können die Checkliste hier kostenfrei herunterladen.

Tipp 4: Nicht die Struktur von IEC oder ISO übernehmen

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:

  1. Metainformationen
  2. Benutzerschnittstelle
  3. Datenschnittstellen
  4. Laufzeitumgebung
  5. Anforderungen an weitere Entwicklungsphasen
  6. Sonstige Anforderungen
Zusatz-Tipp

Nutzen Sie die Templates im Auditgarant. Mit diesen Mustern sparen Sie viel Zeit beim Strukturieren und Dokumentieren Ihrer Software-Anforderungen.

Tipp 5: Möglichst knapp spezifizieren

Eine SRS sollte so kurz wie möglich, aber so ausführlich wie nötig sein.

  • Nicht die Zweckbestimmung in der SRS wiederholen
  • Abkürzungsverzeichnis nur referenzieren und nicht wiederholen
  • Keine langen Metainformationen (z. B. über die Ziele der SRS)
  • Statt langer Anforderungslisten, wie eine UI aussehen soll, besser ein Link auf ein versioniertes Mock-up
  • Bilder und Diagramme statt viel Text

4. Unterstützung

Nutzen Sie die Unterstützung des Johner Instituts:

  • Mit dem Auditgarant lernen Sie anhand von Videotrainings, wie Sie Schritt für Schritt eine schlanke und IEC-62304 konforme „Software-Akte“ erstellen. Ein vollständiger Satz an Templates nimmt Ihnen viel Arbeit ab.

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.


TIR 45: Agile Software-Entwicklung für Medizinprodukte

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…

Weiterlesen

LOINC — Logical Observation Identifiers Names and Codes

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…

Weiterlesen

IVD Software-Hersteller aufgepasst

Dieser 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.

Weiterlesen

FDA Guidance ‚Interoperable Medical Devices‘

Die 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
Software-Audit: Gibt es das?

Software-Audit: Auf was es wirklich ankommt

„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.

Weiterlesen