Ressourcen · Beispieldokumente

Beispieldokumente für IEC 62304 und Cybersicherheit

Silurus Software veröffentlicht neun Beispieldokumente, wie sie eine Benannte Stelle, ein FDA-Prüfer oder Ihre eigene QA-Leitung erwarten. Dazu gehören ein SOUP-Inventar, eine Rückverfolgbarkeitsmatrix, eine CycloneDX-SBOM, eine STRIDE-Bedrohungstabelle und eine Testfallvorlage. Hinzu kommen die Gliederung einer FDA Pre-Submission und drei Aufzeichnungen zu klinischer KI für Krankenhäuser. Alle neun Beispiele dienen der Veranschaulichung und beziehen sich auf ein fiktives Gerät.

Dokumente
9, in HTML, ohne Download-Formular
Inhalt
Fiktiv, zur Veranschaulichung
Beispielgerät
Fiktiver Monitor für den Heimgebrauch, Software-Sicherheitsklasse B
Normen
IEC 62304:2006+A1:2015 · ISO 14971:2019 · IEC 81001-5-1:2021
Hintergrund

Die Aufzeichnungen selbst

Wer einen Lieferanten für ein reguliertes Produkt bewertet, verlangt die zugehörigen Aufzeichnungen. Eine Prozessbeschreibung allein reicht dafür nicht aus.

Die Beispiele 01 bis 06 zeigen Auszüge aus Aufzeichnungen für Medizinproduktesoftware nach IEC 62304:2006+A1:2015, ISO 14971:2019, IEC 81001-5-1:2021 und der FDA-Guidance zur Cybersicherheit von Medizinprodukten. Die Beispiele 07 bis 09 zeigen Aufzeichnungen, die Krankenhäuser bei der Auswahl und Validierung eines klinischen KI-Tools nutzen. Jedes Beispiel enthält einige Zeilen oder Felder der vollständigen Aufzeichnung. Die Zeilen wurden eigens für diese Seite verfasst. Sie stammen nicht aus Kundenprojekten und enthalten weder Kundendaten noch Produktnamen oder Dokumentnummern.

Das fiktive Beispielgerät ist ein vernetzter Monitor für den Heimgebrauch. Es besitzt eine Sensoreinheit mit FreeRTOS und ein Linux-Gateway mit Touch-Display und Cloud-Upload. Die Software gehört nach IEC 62304 zur Sicherheitsklasse B. Das SOUP-Inventar und die SBOM enthalten reale Open-Source-Komponenten mit tatsächlichen Versionsnummern. Jeder Eintrag lässt sich daher überprüfen.

Über die IDs sind die fünf Aufzeichnungen miteinander verknüpft. Eine Anforderung in der Rückverfolgbarkeitsmatrix verweist auf eine Risikobeherrschungsmaßnahme. Eine Bedrohung in der STRIDE-Tabelle verweist auf eine Anforderung und einen Test. Ein SOUP-Element verweist auf seinen SBOM-Eintrag.

Aufbau

Das ist allen Beispielen gemeinsam

Jede Zeile hat eine eindeutige ID

Jede Zeile der Geräteaufzeichnungen hat eine ID, auf die andere Aufzeichnungen verweisen. So kann ein Auditor eine Anforderung von der Spezifikation bis zum Testergebnis zurückverfolgen.

Version oder Build sind angegeben

Für jedes SOUP-Element ist die Version angegeben. Jedes Testergebnis ist dem Build zugeordnet, mit dem der Test ausgeführt wurde.

Verweis auf die Risikomanagementakte

Jede Zeile des SOUP-Inventars, der Rückverfolgbarkeitsmatrix und der Bedrohungstabelle verweist auf einen Eintrag in der Risikomanagementakte nach ISO 14971. Dieser beschreibt eine Gefährdung, eine Bedrohung oder eine Risikobeherrschungsmaßnahme. Fehlt ein solcher Eintrag, ist dies begründet.

Rückverfolgbarkeit

So hängen die ersten fünf Aufzeichnungen zusammen

Die fünf Aufzeichnungen bilden eine Kette. Ihre Verknüpfung erfolgt über die IDs in der Rückverfolgbarkeitsmatrix.

SOUP-Inventar und SBOM beschreiben dieselben Komponenten von Drittanbietern für zwei verschiedene Leser. Die SOUP-Aufzeichnung enthält die Sicht nach IEC 62304 mit Zweck, Anforderungen, veröffentlichten Anomalien und Risiko. Die SBOM enthält die maschinenlesbare Sicht, die ein Schwachstellenscanner und eine FDA-Einreichung nutzen.

Aus der STRIDE-Tabelle ergeben sich Sicherheitsanforderungen. Jede Kontrollmaßnahme erhält als Sicherheitsanforderung eine eigene ID. In der Matrix steht diese Anforderung neben der zugehörigen Risikobeherrschungsmaßnahme und dem Test, der ihre Erfüllung nachweist.

Die Testfallvorlage legt fest, wie die Tests in der Testspalte dokumentiert werden. Für jeden ausgeführten Testfall werden der Build, das Ergebnis und die dadurch aufgetretene Anomalie festgehalten.

Beispiel 01

Auszug aus dem SOUP-Inventar

Beispiel, fiktive Inhalte zur Veranschaulichung. Fünf Komponenten von Drittanbietern des fiktiven Geräts, identifiziert nach IEC 62304 Abschnitt 8.1.2, mit den Anforderungen nach Abschnitt 5.3.3 und der Prüfung der Anomalien nach Abschnitt 7.1.3.

IDKomponente und VersionQuelle und LizenzZweck im GerätAnforderungen an das ElementVeröffentlichte AnomalienRisiko und BegründungSBOM-Eintrag
SOUP-001FreeRTOS-Kernel V11.3.1freertos.org, MITTask-Scheduling auf der SensoreinheitFührt die 10-ms-Messaufgabe ohne verpasste Deadlines aus. Erkennung von Stack-Überläufen aktiviert.Release Notes und Issue-Tracker für den Cortex-M4-Port geprüft, zuletzt am 30.09.2026. Keine offenen Einträge betreffen die verwendeten Scheduler-Funktionen.Trägt zu HAZ-04 bei (verzögerter Alarm). Risikobeherrschung durch den Hardware-Watchdog RC-07.SBOM der Sensoreinheit, pkg:github/FreeRTOS/FreeRTOS-Kernel@V11.3.1
SOUP-002OpenSSL 3.5.9 (LTS)openssl.org, Apache 2.0TLS für den Cloud-Upload auf dem GatewayNur TLS 1.2 oder höher, Serverzertifikat mit Certificate Pinning und zusätzlichem Backup-Pin, keine TLS-Renegotiation.Sicherheitshinweise monatlich geprüft, zuletzt am 30.09.2026 nach dem Update von 3.5.8. LTS-Zweig mit Support bis zum 8. April 2030.Mindert THR-03. Bei einem Fehler wird der Upload blockiert. Die Daten bleiben auf dem Gateway.SBOM des Gateways, pkg:github/openssl/openssl@openssl-3.5.9
SOUP-003SQLite 3.53.4sqlite.org, gemeinfreiLokale Speicherung der Messdatensätze auf dem GatewayAtomarer Commit im WAL-Modus mit synchronous=FULL. Integritätsprüfung bei jedem Start.Release-Log und CVE-Liste geprüft, zuletzt am 30.09.2026. Korrekturen bis Version 3.53.4 enthalten. Keine offenen Einträge betreffen die verwendeten Funktionen.Trägt zu HAZ-09 bei (verlorene Datensätze). Risikobeherrschung durch RC-09, verifiziert mit dem Stromausfalltest STC-044.SBOM des Gateways, pkg:generic/sqlite@3.53.4
SOUP-004zlib 1.3.2zlib.net, zlib-LizenzKomprimierung der Log-Archive vor dem UploadKomprimiert und dekomprimiert Archive bis 50 MB verlustfrei. Dies entspricht dem größten Tageslog aus dem Lasttest LT-02.Changelog und CVE-Liste geprüft, zuletzt am 30.09.2026. Keine Einträge betreffen die verwendeten Deflate-Funktionen.Trägt nicht zu einer Gefährdungssituation bei. Die SOUP-Bewertung enthält die Begründung.SBOM des Gateways, pkg:github/madler/zlib@v1.3.2
SOUP-005nlohmann/json 3.12.0github.com/nlohmann/json, MITEinlesen der KonfigurationsdateiWeist fehlerhafte Eingaben durch eine Exception zurück und liefert niemals ein unvollständiges Parse-Ergebnis.Issue-Tracker geprüft, zuletzt am 30.09.2026. Keine relevanten Einträge.Trägt zu HAZ-06 bei (falscher Alarmgrenzwert). Risikobeherrschung durch die Bereichsprüfung RC-11.SBOM des Gateways, pkg:github/nlohmann/json@v3.12.0

Beispiel, fiktive Inhalte zur Veranschaulichung. Fiktives Gerät, reale Open-Source-Komponenten. Ein vollständiges Inventar nennt zusätzlich die Hardware und Software, die jedes Element voraussetzt (IEC 62304 Abschnitt 5.3.4).

Beispiel 02

Auszug aus der Rückverfolgbarkeitsmatrix

Beispiel, fiktive Inhalte zur Veranschaulichung. Von der Anforderung zu Design, Code, Test und Risiko, einschließlich der Rückverfolgbarkeit der Risikobeherrschungsmaßnahmen nach IEC 62304 Abschnitt 7.3.3.

AnforderungTextDesignCode-EinheitTestRisikoStatus
SRS-014Überschreitet der Messwert den eingestellten Grenzwert, muss das Gerät innerhalb von 10 s einen akustischen und optischen Alarm hoher Priorität auslösen. Der Alarm muss bis zur Quittierung selbsthaltend bleiben.SDD-3.2 Alarmmanageralarm/alarm_manager.cSTC-031, STC-033HAZ-04, RC-07Bestanden, Build 2.4.0
SRS-021Die Messdatensätze müssen auch dann erhalten bleiben, wenn während eines Schreibvorgangs der Strom ausfällt.SDD-4.1 Datensatzspeicherstorage/record_store.cppSTC-044HAZ-09, RC-09Bestanden, Build 2.4.0
SRS-030Das Gateway darf Daten nur über TLS 1.2 oder höher und mit einem gepinnten Serverzertifikat hochladen.SDD-5.3 Cloud-Verbindungnet/tls_client.cppSTC-052, PEN-03THR-03, RC-12Bestanden, Build 2.4.0
SRS-037Die Sensoreinheit darf ein Firmware-Image nur annehmen, wenn dessen Signatur gültig ist.SDD-6.2 Image-Verifizierungboot/verify_image.cSTC-060, STC-061THR-05, RC-14Offen, Anomalie PR-118 blockiert das Release
SRS-042Das Gateway-Display muss den zuletzt gemessenen Wert und dessen Alter anzeigen.SDD-2.4 Startbildschirmui/HomeView.qmlSTC-070, UE-05HAZ-11, RC-16Bestanden, Build 2.4.0

Beispiel, fiktive Inhalte zur Veranschaulichung. UE-05 ist eine Bewertung der Gebrauchstauglichkeit nach IEC 62366-1. PEN-03 ist ein Testfall aus dem Penetrationstest. STC-033 verifiziert RC-07 durch Fehlerinjektion. Bei gestoppter Alarm-Task muss der Watchdog die Sensoreinheit innerhalb von 3 s zurücksetzen und den Backup-Summer auslösen. Build 2.4.0 ist der Release Candidate, die offene Anomalie PR-118 blockiert sein Release.

Beispiel 03

Auszug aus der CycloneDX-SBOM

Beispiel, fiktive Inhalte zur Veranschaulichung.

Der Auszug zeigt die SBOM der Gateway-Firmware des fiktiven Geräts im JSON-Format nach CycloneDX 1.6. Er wurde manuell in der Struktur erstellt, die ein Syft-Scan von Build 2.4.0 erzeugt. Ein Scan vergibt eigene bom-ref-Werte. Hier entsprechen diese Werte den SOUP-IDs. Der vulnerabilities-Block stammt nicht aus einem Scan. Ein Entwickler ergänzt ihn nach der Erreichbarkeitsprüfung. Der Auszug enthält vier Komponenten. Die vollständige Datei führt alle Komponenten, das Betriebssystem und die transitiven Abhängigkeiten auf. Jede bom-ref entspricht der SOUP-ID der jeweiligen Komponente. So lassen sich SOUP-Inventar und SBOM miteinander verknüpfen. Die Hashes entsprechen den Werten, welche die Projekte für ihre Quell-Releases veröffentlichen. Für SQLite ist dies der SHA3-256-Hash von sqlite3.c. Die Schwachstellen-ID dient als Platzhalter. In einer echten SBOM stammen die Hashes aus dem Build und beschreiben die ausgelieferten Dateien.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:e23dacfd-0f57-4635-9536-2fda9115f806",
  "version": 7,
  "metadata": {
    "timestamp": "2026-09-30T08:00:00Z",
    "authors": [{ "name": "Softwareteam, fiktiver Hersteller" }],
    "tools": { "components": [{ "type": "application", "name": "syft", "version": "1.52.0" }] },
    "component": { "type": "firmware", "bom-ref": "gateway-fw",
                   "name": "example-gateway-firmware", "version": "2.4.0" }
  },
  "components": [
    { "type": "library", "bom-ref": "SOUP-002",
      "supplier": { "name": "OpenSSL project", "url": ["https://openssl-library.org"] },
      "name": "openssl", "version": "3.5.9",
      "purl": "pkg:github/openssl/openssl@openssl-3.5.9",
      "licenses": [{ "license": { "id": "Apache-2.0" } }],
      "hashes": [{ "alg": "SHA-256", "content": "603f5602e2eef00d77fbd429d34dcd5822bb301757a1bc9cdb24c670f1eb859a" }] },
    { "type": "library", "bom-ref": "SOUP-003",
      "supplier": { "name": "SQLite project", "url": ["https://sqlite.org"] },
      "name": "sqlite", "version": "3.53.4",
      "purl": "pkg:generic/sqlite@3.53.4",
      "licenses": [{ "license": { "id": "blessing" } }],
      "hashes": [{ "alg": "SHA3-256", "content": "67f423e9ebbbdc473cbc4772c872ee6b89f31fde4ed0279a5c25d5f65c043a16" }] },
    { "type": "library", "bom-ref": "SOUP-004",
      "supplier": { "name": "zlib project", "url": ["https://zlib.net"] },
      "name": "zlib", "version": "1.3.2",
      "purl": "pkg:github/madler/zlib@v1.3.2",
      "licenses": [{ "license": { "id": "Zlib" } }],
      "hashes": [{ "alg": "SHA-256", "content": "bb329a0a2cd0274d05519d61c667c062e06990d72e125ee2dfa8de64f0119d16" }] },
    { "type": "library", "bom-ref": "SOUP-005",
      "supplier": { "name": "Niels Lohmann", "url": ["https://github.com/nlohmann/json"] },
      "name": "nlohmann-json", "version": "3.12.0",
      "purl": "pkg:github/nlohmann/json@v3.12.0",
      "licenses": [{ "license": { "id": "MIT" } }],
      "hashes": [{ "alg": "SHA-256", "content": "42f6e95cad6ec532fd372391373363b62a14af6d771056dbfc86160e6dfff7aa" }] }
  ],
  "dependencies": [
    { "ref": "gateway-fw", "dependsOn": [ "SOUP-002", "SOUP-003", "SOUP-004", "SOUP-005" ] }
  ],
  "vulnerabilities": [
    { "id": "CVE-YYYY-NNNNN",
      "affects": [{ "ref": "SOUP-002" }],
      "analysis": { "state": "not_affected", "justification": "code_not_reachable",
                    "detail": "Die betroffene Funktion wird nicht aufgerufen. Erreichbarkeit am Aufrufgraphen von Build 2.4.0 geprüft, Eintrag VA-012, Bedrohung THR-03." } }
  ]
}

Der vulnerabilities-Block dokumentiert die Bewertung jeder bekannten Schwachstelle im Hinblick auf das Gerät. Im gezeigten Fall wird die betroffene Funktion nie aufgerufen. Die Erreichbarkeitsprüfung ist unter VA-012 dokumentiert. Der Eintrag verweist außerdem auf die zugehörige Bedrohung. Diese VEX-Informationen erwartet ein Prüfer zusätzlich zur SBOM.

Die SBOM wird aus dem Build erzeugt und bei jedem Release aktualisiert. Ein Entwickler prüft das SOUP-Inventar, sobald sich eine Komponente, ihre Version oder ihre Funktion ändert. Die Prüfung erfolgt außerdem monatlich im Rahmen der Schwachstellenüberwachung.

Beispiel 04

Auszug aus der STRIDE-Bedrohungstabelle

Beispiel, fiktive Inhalte zur Veranschaulichung. Sieben Bedrohungen des fiktiven Geräts in allen sechs STRIDE-Kategorien. Sie stammen aus dem Bedrohungsmodell, das die Premarket-Guidance der FDA zur Cybersicherheit erwartet, mit dem Management der Sicherheitsrisiken nach IEC 81001-5-1.

IDElementSTRIDEBedrohungAuswirkung auf das GerätKontrollmaßnahmeVerifizierungRestrisiko und Bewertung
THR-01BLE-Verbindung zwischen Sensor und GatewaySpoofingEin Gerät in der Nähe gibt sich als Sensor aus und überträgt Messwerte.Dem Nutzer werden falsche Messwerte angezeigt.LE Secure Connections mit Out-of-Band-Pairing-Daten (MITM-Schutz), da die Sensoreinheit kein Display hat. Nur gebondete Geräte sind zugelassen.PEN-01Niedrig (Wahrscheinlichkeit niedrig, Auswirkung hoch), akzeptiert
THR-02Datenspeicher auf dem GatewayTamperingGespeicherte Datensätze werden im Dateisystem verändert oder erneut eingespielt.Das medizinische Fachpersonal sieht einen verfälschten Messwertverlauf.HMAC für jeden Datensatz mit Sequenznummer, Schlüssel im Secure Element.STC-045Niedrig (Wahrscheinlichkeit niedrig, Auswirkung mittel), akzeptiert
THR-03Cloud-UploadInformation DisclosureDer Datenverkehr zwischen Gateway und Cloud wird abgefangen.Gesundheitsdaten werden offengelegt.TLS 1.2 oder höher, fest hinterlegtes Serverzertifikat mit Backup-Pin für den Zertifikatswechsel.STC-052, PEN-03Niedrig (Wahrscheinlichkeit niedrig, Auswirkung hoch), akzeptiert
THR-04KonfigurationsänderungRepudiationEin Alarmgrenzwert wird geändert, ohne dass sich feststellen lässt, wer die Änderung vorgenommen hat.Bei der Untersuchung einer Beschwerde lässt sich die Änderung nicht nachvollziehen.Signiertes Audit-Log mit Benutzer und Zeitpunkt, das bei jedem Upload in die Cloud kopiert wird.STC-081Niedrig (Wahrscheinlichkeit niedrig, Auswirkung mittel), akzeptiert
THR-05Firmware-UpdateTamperingEin manipuliertes Image wird auf der Sensoreinheit installiert.Verlust der wesentlichen Leistungsmerkmale.Signierte Images, Secure Boot, Rollback-Zähler.STC-060, STC-061Mittel (Wahrscheinlichkeit mittel, Auswirkung hoch), offen, bis PR-118 abgeschlossen ist
THR-06Cloud-APIDenial of ServiceEine Flut von Anfragen blockiert den Upload-Endpunkt.Die Daten erreichen die Klinik verspätet. Der lokale Alarm ist nicht betroffen.Rate Limits, lokaler Puffer für 72 h auf dem Gateway, entsprechend drei Tagen Daten bei höchster Abtastrate.LT-03 (Test der Pufferkapazität)Niedrig (Wahrscheinlichkeit mittel, Auswirkung niedrig), akzeptiert
THR-07USB-ServiceportElevation of PrivilegeAuf einem Seriengerät ist eine Debug-Shell zugänglich.Vollständige Kontrolle über das Gerät.Debug-Schnittstellen in Release-Builds deaktiviert, JTAG gesperrt.STC-090, Release-ChecklisteNiedrig (Wahrscheinlichkeit niedrig, Auswirkung hoch), akzeptiert

Beispiel, fiktive Inhalte zur Veranschaulichung. Wahrscheinlichkeit und Auswirkung sind auf den Skalen des Plans für das Cybersicherheits-Risikomanagement bewertet, und ein benannter Risikoeigner akzeptiert jedes Restrisiko. Jede Kontrollmaßnahme wird in der Rückverfolgbarkeitsmatrix zu einer Sicherheitsanforderung. THR-03 erscheint dort als SRS-030.

Beispiel 05

Ausgefüllte Testfallvorlage

Beispiel, fiktive Inhalte zur Veranschaulichung. Ein Softwaresystemtestfall für SRS-014 mit den Inhalten der Aufzeichnung nach IEC 62304 Abschnitt 5.7.5.

FeldInhalt
Testfall-IDSTC-031
TitelAlarm hoher Priorität bei Überschreitung des Messwertgrenzwerts
RückverfolgbarkeitSRS-014, HAZ-04. STC-033 verifiziert die Risikobeherrschungsmaßnahme RC-07 separat.
Teststufe und SicherheitsklasseSoftwaresystemtest, Software-Sicherheitsklasse B nach IEC 62304 Abschnitt 4.3. RC-07 fängt einen Softwarefehler ab, der den Alarm verzögert. RC-07 ist ein Hardware-Watchdog außerhalb der Software. Er setzt die Sensoreinheit zurück und steuert den Backup-Summer direkt an. Mit RC-07 ist die schwerste mögliche Folge eine nicht schwerwiegende Verletzung. Daraus ergibt sich Klasse B.
VorbedingungenGateway und Sensoreinheit gekoppelt, Alarmgrenzwert auf 120 eingestellt, Messung läuft seit mindestens 60 s.
TestumgebungSensoreinheit mit Hardware-Revision C und Firmware 2.4.0, Gateway-Image 2.4.0, Signalsimulator SIM-2 mit Kalibrierprotokoll CAL-207, Timer-Auflösung 0,1 s.
Testschritte1. Den Wert 110 für 30 s einspeisen. 2. Den Grenzwert 120 für 30 s einspeisen. 3. Auf 121 erhöhen und den Timer starten. 4. Den Wert 20 s halten. 5. Auf 110 senken und 10 s warten. 6. Den Alarm quittieren.
Erwartetes ErgebnisKein Alarm in den Schritten 1 und 2. Innerhalb von 10 s nach Schritt 3 ertönt ein akustischer und erscheint ein optischer Alarm hoher Priorität. In Schritt 5 endet die Alarmbedingung. Das Alarmsignal bleibt bis zur Quittierung in Schritt 6 selbsthaltend.
Bestehens- und NichtbestehenskriterienBestanden, wenn bei allen 10 Wiederholungen am Grenzwert kein Alarm auftritt und der Alarm oberhalb des Grenzwerts innerhalb von 10 s auslöst. Der Alarm muss bis zur Quittierung selbsthaltend bleiben. Jede Abweichung bei einer Wiederholung führt zum Nichtbestehen.
Tatsächliches ErgebnisBei 120 trat in 10 von 10 Fällen kein Alarm auf. Der Alarm löste in 10 von 10 Fällen nach 6,2 s bis 7,9 s aus, im Mittel nach 7,1 s. In 10 von 10 Fällen blieb der Alarm bis zur Quittierung selbsthaltend. Einzelzeiten im Testlog von Build 2.4.0.
ErgebnisBestanden
Ausgeführt von, Datum, Build[Tester], [Datum], Build 2.4.0
Gemeldete AnomalienKeine
Geprüft von[Prüfer], [Datum]

Beispiel, fiktive Inhalte zur Veranschaulichung. Namen und Daten sind als Platzhalter belassen.

Beispiel 06

Aufbau einer FDA Pre-Submission

Beispiel, fiktive Inhalte zur Veranschaulichung. Der Aufbau eines Pre-Submission-Pakets im Q-Submission-Programm der FDA, erstellt von unseren FDA-Beratern, mit den konkreten Fragen, die die Behörde beantworten soll.

AbschnittInhalt
AnschreibenAntrag auf ein Pre-Submission-Meeting für einen vernetzten Monitor für den Heimgebrauch, mit bevorzugtem Meetingformat (Telefonkonferenz) und Kontaktperson.
GerätebeschreibungSensoreinheit mit Firmware, Linux-Gateway mit Touch-Display und Cloud-Upload. Beschreibung des Zusammenspiels der Komponenten, des gemessenen Parameters und der Alarmfunktion mit Systemdiagramm.
Vorgeschlagene Indikationen (Indications for Use)Formulierungsentwurf für die Zweckbestimmung (Intended Use) und die Indikationen (Indications for Use), Patientenpopulation und Anwendungsumgebung (zu Hause).
Bisherige regulatorische VerfahrenBisher keine FDA-Einreichungen für dieses Gerät. CE-Kennzeichnung nach EU MDR in Vorbereitung.
Geplantes Zulassungsverfahren510(k) mit einem vorgeschlagenen Vergleichsprodukt (Predicate Device) und einem kurzen Vergleich der Zweckbestimmung und technologischen Merkmale.
Geplante PrüfungenGrundlegende Sicherheit und wesentliche Leistungsmerkmale nach IEC 60601-1, EMV nach IEC 60601-1-2, Alarme nach IEC 60601-1-8 und Heimgebrauch nach IEC 60601-1-11. Hinzu kommen Softwareverifizierung nach IEC 62304, Gebrauchstauglichkeit nach IEC 62366-1 und die Cybersicherheitsdokumentation nach Section 524B des FD&C Act.
Frage 1Stimmt die Behörde zu, dass sich das vorgeschlagene Vergleichsprodukt für die Zweckbestimmung gemäß den vorgeschlagenen Indications for Use eignet?
Frage 2Stimmt die Behörde zu, dass die geplanten Prüfungen der Alarmleistung ausreichen, um die wesentliche Gleichwertigkeit (Substantial Equivalence) nachzuweisen?
Frage 3Stimmt die Behörde zu, dass die geplanten Penetrationstests des Gateways und der Cloud-Verbindung die Cybersicherheitsdokumentation für diese Einreichung ausreichend stützen?

Beispiel, fiktive Inhalte zur Veranschaulichung. Die Fragen sind für das fiktive Gerät formuliert.

Beispiel 07

Priorisierung klinischer KI-Anwendungsfälle

Beispiel, fiktive Inhalte zur Veranschaulichung. Das erste Ergebnis einer Bestandsaufnahme der KI-Reife für ein Krankenhaus: Anwendungsfälle, gereiht nach Nutzen, Evidenz und den Voraussetzungen, von denen sie abhängen. Einer davon wird vorerst zurückgestellt.

IDAnwendungsfallAbteilungNutzenEvidenzWichtigste VoraussetzungRang
UC-01Frakturerkennung auf Röntgenaufnahmen der NotaufnahmeRadiologie, NotaufnahmeHochStarke Evidenz, Produkte mit CE-KennzeichnungIntegration in das PACS1
UC-04Unterstützung beim Mammographie-ScreeningRadiologie, ScreeningHochStarke Evidenz aus veröffentlichten StudienZunächst vor Ort validieren2
UC-02Entwürfe für EntlassbriefeInnere MedizinHochBegrenzte Evidenz aus PilotdatenPilotprojekt mit Messung vor Ort3
UC-03Terminassistent für das KontaktcenterPatientenanmeldungMittelBegrenztIn die Terminplanung integrieren4
UC-05Sepsisvorhersage anhand der PatientenakteStationenUnsicherSchwache externe EvidenzNoch nicht begonnenVorerst zurückstellen

Beispiel, fiktive Inhalte zur Veranschaulichung. Ein fiktives Krankenhaus. Gereiht zuerst nach Nutzen, dann nach der Stärke der Evidenz, dann nach dem Aufwand für die wichtigste Voraussetzung. Der Nutzen ist aus den eigenen Fallzahlen und Personalzeiten des Krankenhauses geschätzt.

Beispiel 08

Bewertungsmatrix für KI-Anbieter

Beispiel, fiktive Inhalte zur Veranschaulichung. Drei fiktive Produkte, verglichen anhand von Kriterien, die das Krankenhaus vorab festgelegt hat, als Grundlage für die Vergabeentscheidung.

KriteriumGewichtung in %Anbieter AAnbieter BAnbieter C
K.-o.-Kriterium: Zweckbestimmung umfasst die geplante AnwendungBestanden oder nicht bestandenBestandenBestandenBestanden
K.-o.-Kriterium: CE-Kennzeichnung für diese ZweckbestimmungBestanden oder nicht bestandenBestandenBestandenBestanden
Klinische Evidenz für vergleichbare Patientengruppen30342
Anbindung an PACS, RIS und Patientenakte20424
Datenschutz und Hosting in der EU20534
Überwachung und Informationen des Anbieters zu Änderungen15342
Gesamtkosten über drei Jahre15344
Gewichtete Punktzahl1003,603,403,10

Beispiel, fiktive Inhalte zur Veranschaulichung. Ein Produkt, das ein K.-o.-Kriterium nicht erfüllt, wird nicht bewertet. Punkte von 1 bis 5 nach einer schriftlichen Skala je Kriterium, Gewichtungen vor der Bewertung mit dem Krankenhaus vereinbart.

Beispiel 09

Lokaler Validierungsbericht im Überblick

Beispiel, fiktive Inhalte zur Veranschaulichung. Die Zusammenfassung einer lokalen Validierung eines fiktiven KI-Tools mit eigenen Studien eines Krankenhauses, vor dem Go-live nach Untergruppen gemessen.

FeldInhalt
Werkzeug und Version[Produkt], fiktives Werkzeug zur Frakturerkennung mit CE-Kennzeichnung, Version 2.1
Geprüfte ZweckbestimmungErkennung von Frakturen auf Röntgenaufnahmen der Extremitäten bei Erwachsenen als Entscheidungsunterstützung für die Befundung
DatensatzRetrospektiv, 1.200 Untersuchungen aus einem Jahr, davon 380 mit Fraktur. Die Daten stammen aus zwei Abteilungen und von zwei Röntgensystemen. Untergruppen: System A 640, System B 560, Patienten über 75 Jahre 210 (davon 70 mit Fraktur).
ReferenzstandardZwei Radiologen beurteilten die Aufnahmen im Konsens, bei Uneinigkeit ein dritter. Die Radiologen kannten die Ergebnisse des Werkzeugs nicht.
AkzeptanzkriterienVor der Messung im Validierungsplan festgelegt: Sensitivität mindestens 0,90 und Spezifität mindestens 0,85, insgesamt und in jeder Untergruppe
GesamtergebnisSensitivität 0,92 (95-%-KI 0,89 bis 0,94), Spezifität 0,88 (0,86 bis 0,90)
Ergebnisse nach UntergruppenSystem A 0,93 (0,89 bis 0,96) und 0,89 (0,86 bis 0,92). System B 0,91 (0,86 bis 0,94) und 0,87 (0,83 bis 0,90). Über 75 Jahre 0,89 (0,79 bis 0,94) und 0,84 (0,77 bis 0,89)
FazitDie Kriterien wurden insgesamt und für beide Röntgensysteme erfüllt. Für Patienten über 75 Jahre wurden sie nicht erfüllt. Dies wurde als Abweichung DV-03 dokumentiert. Das KI-Aufsichtsgremium des Krankenhauses hat entschieden, das Werkzeug für diese Gruppe erst nach einer erneuten Validierung mit einem größeren Datensatz einzusetzen.
Monitoring-PlanMonatliche Prüfung der Sensitivität anhand einer Stichprobe, Anteil der überstimmten Ergebnisse je Station, vereinbarter Schwellenwert für eine Überprüfung

Beispiel, fiktive Inhalte zur Veranschaulichung. Alle Zahlen sind für dieses Beispiel erfunden.

Kundenprojekte

Dieselben Aufzeichnungen erstellen wir auch für Kunden

Diese Aufzeichnungstypen gehören zu den Produkten, an denen wir arbeiten. In den Fallstudien unten haben wir sie für den Kunden erstellt, im Qualitätsmanagementsystem des Kunden und unter seiner Dokumentenlenkung.

AufzeichnungIn diesen Kundenprojekten erstelltFallstudie
Rückverfolgbarkeitsmatrix wie in Beispiel 02Durchgängig von den Nutzeranforderungen bis zu verifizierten Testergebnissen und je Änderung von der Anforderung bis zur VerifizierungRefactoring eines Laborgeräts, Feature-Entwicklung nach IEC 62304, QA und DevOps für ein reguliertes Portfolio
Testfälle und Testberichte wie in Beispiel 05Verifizierungsplan, Testberichte und Nachweise der Regressionstests für jedes ReleaseRefactoring eines Laborgeräts, QA und DevOps für ein reguliertes Portfolio
Software-AnforderungsspezifikationSchriftlich festgehaltene Anforderungen, die als Grundlage für die Validierung dienenRefactoring eines Laborgeräts
Risikobewertung für jede ÄnderungJede Änderung wird nach ISO 14971 auf Risiken bewertet. Die Bewertung lässt sich bis zur Verifizierung der jeweiligen Änderung zurückverfolgen.Feature-Entwicklung nach IEC 62304
Bericht zur Gap-AnalyseNach Priorität geordnete Abweichungen von den Anforderungen der IEC 62304, der FDA und der MDR, jeweils mit einer Empfehlung zur BehebungGap-Analyse einer Embedded-Firmware

Die Kundendokumente bleiben beim Kunden und werden hier nicht gezeigt.

Umfang

Was die Beispiele zeigen und was nicht

Das zeigen die Beispiele

  • Die Felder und IDs jeder Aufzeichnung
  • Wie die fünf Aufzeichnungen aufeinander verweisen
  • Wie detailliert eine einzelne Zeile ausgearbeitet ist
  • Reale Open-Source-Komponenten mit realen Versionen

Das sind die Beispiele nicht

  • Kopien von Kundendokumenten oder Auszüge daraus
  • Eine Vorlage, die die Formate Ihres QMS ersetzt
  • Ein Nachweis über das Ergebnis einer Einreichung
  • Eine vollständige Aufzeichnung. Jedes Beispiel zeigt nur einen Auszug.
FAQ

Fragen zu den Beispielen

01

Wie unterscheiden sich SOUP-Liste und SBOM?

Die SBOM listet jede Softwarekomponente mit Version, Lieferant, Lizenz und Hash in einem maschinenlesbaren Format wie CycloneDX oder SPDX auf, für die Überwachung von Schwachstellen. Für IEC 62304 ergänzt der SOUP-Eintrag, warum die Komponente eingesetzt wird, welche Anforderungen sie erfüllen muss, die Prüfung ihrer veröffentlichten Anomalien und ihren Beitrag zum Risiko. Ein Gerät braucht beide, und die zwei nutzen dieselben Komponentenkennungen.

02

Welches SBOM-Format liefern Sie?

CycloneDX JSON wie im Beispiel oder SPDX, wenn die Werkzeuge des Kunden dies erfordern. Das Format richtet sich nach dem Scanner und dem Einreichungsweg. Der Inhalt bleibt gleich.

03

Verwenden Sie unsere Vorlagen oder Ihre eigenen?

Wir verwenden Ihre Vorlagen, soweit Ihr QMS diese vorgibt. Die Beispiele zeigen, welche Inhalte eine Aufzeichnung enthalten muss. Wir übernehmen dieselben Inhalte in Ihre Formate und unter Ihre Dokumentenlenkung.

04

Können wir ein vollständiges Dokument aus einem echten Projekt sehen?

Nein. Kundendokumente gehören dem jeweiligen Kunden und bleiben gemäß unseren Vereinbarungen vertraulich. Die Beispiele auf dieser Seite zeigen den Aufbau. In einem Gespräch erläutern wir, wie eine solche Aufzeichnung für Ihr Gerät entsteht.

05

Welche Normen gelten für diese Aufzeichnungen?

IEC 62304 gilt für das SOUP-Inventar, die Rückverfolgbarkeitsmatrix und die Testaufzeichnung. ISO 14971 gilt für die Risikoverweise. IEC 81001-5-1 und die Premarket-Guidance der FDA zur Cybersicherheit gelten für die Bedrohungstabelle und die SBOM. IEC 62366-1 gilt für die Bewertung der Gebrauchstauglichkeit, auf die die Matrix verweist.

Sprechen Sie mit uns

Benötigen Sie diese Aufzeichnungen für Ihr Gerät?

Senden Sie uns Ihre Anforderungen und die aktuelle Dokumentation. Im ersten Gespräch klären wir, welche Aufzeichnungen bereits vorliegen und welche noch fehlen.