Szakmai anyagok · Mintadokumentumok

Mintaanyagok az IEC 62304-hez és a kiberbiztonsághoz

A Silurus Software kilenc olyan mintadokumentumot tesz közzé, amelyet egy bejelentett szervezet, az FDA egyik felülvizsgálója vagy a minőségbiztosítási vezetőd is kérhet. Ezek a következők: SOUP-lista, nyomon követhetőségi mátrix, CycloneDX SBOM, STRIDE fenyegetéselemzési táblázat, tesztesetsablon, FDA Pre-Submission vázlat és három kórházi klinikai AI-dokumentum. Mind a kilenc minta egy fiktív eszközhöz készült, szemléltetési céllal.

Mintadokumentumok
9, HTML-ben, letöltési űrlap nélkül
Tartalom
Fiktív, szemléltető célú
Példaeszköz
Fiktív otthoni monitorozó eszköz, B szoftverbiztonsági osztály
Szabványok
IEC 62304:2006+A1:2015 · ISO 14971:2019 · IEC 81001-5-1:2021
Háttér

Konkrét dokumentumokat mutatunk be

Egy szabályozott orvostechnikai eszköz beszállítójának felülvizsgálatakor magukat a dokumentumokat kérik el. A folyamat leírása önmagában nem elegendő.

Az első hat példa az IEC 62304:2006+A1:2015, az ISO 14971:2019, az IEC 81001-5-1:2021 és az FDA orvostechnikai eszközök kiberbiztonságáról szóló útmutatója alapján készült. Orvostechnikai szoftverek dokumentumaiból mutatnak be részleteket. A 07., 08. és 09. példa a kórházak által klinikai AI-eszközök kiválasztásakor és validálásakor használt dokumentumokat szemlélteti. Minden mintában a teljes dokumentumnak csak néhány sorát vagy mezőjét mutatjuk be. A tartalmat kifejezetten ehhez az oldalhoz készítettük. Egyik minta sem ügyfélprojektből származik. Ügyféladatot, terméknevet és ügyfélprojekthez tartozó dokumentumazonosítót sem tartalmaznak.

A példaeszköz egy fiktív, hálózatra kapcsolt otthoni monitorozó rendszer. Részei egy FreeRTOS-t futtató szenzoregység, egy érintőképernyős Linux gateway és a felhőalapú adatfeltöltés. Az IEC 62304 szerint B szoftverbiztonsági osztályba tartozik. A SOUP-listában és az SBOM-ban szereplő nyílt forráskódú komponensek azonban valós projektek, valós verziószámokkal. Így minden bejegyzés ellenőrizhető.

Az első öt dokumentumot közös azonosítók kapcsolják össze. A nyomon követhetőségi mátrixban minden követelményhez hozzárendeljük a megfelelő kockázatcsökkentő intézkedést. A STRIDE-táblázatban a fenyegetéseket követelményekhez és tesztekhez kapcsoljuk. A SOUP-listában az egyes komponensek SBOM-bejegyzésére hivatkozunk.

Felépítés

A mintadokumentumok közös jellemzői

Minden sorhoz egyedi azonosítót rendelünk

Az eszközhöz tartozó dokumentumok minden sorát egyedi azonosítóval látjuk el. A többi dokumentumban ezekre hivatkozunk, így az auditor az adott követelményt a specifikációtól a teszteredményig követheti.

Minden komponens és teszt verzióját azonosítjuk

Minden SOUP-komponensnél rögzítjük a pontos verziót. A teszteredményeknél azt is feltüntetjük, hogy melyik builden futott a teszt.

A dokumentumokat összekapcsoljuk a kockázatkezeléssel

A SOUP-lista, a nyomon követhetőségi mátrix és a fenyegetéselemzési táblázat minden sorában hivatkozunk az ISO 14971 szerinti kockázatkezelési dokumentációra. Megjelöljük a kapcsolódó veszélyt, fenyegetést vagy kockázatcsökkentő intézkedést. Ha nincs ilyen kapcsolat, az indokát is rögzítjük.

Nyomon követhetőség

Így kapcsolódik össze az első öt dokumentum

Az első öt dokumentum között közvetlen kapcsolatot teremtenek a nyomon követhetőségi mátrixban szereplő azonosítók.

A SOUP-lista és az SBOM ugyanazokat a harmadik féltől származó komponenseket írja le, de két eltérő felhasználói körnek szólnak. A SOUP-nyilvántartás az IEC 62304 követelményeit alkalmazó szakembereknek tartalmazza a komponensek rendeltetését, követelményeit, közzétett anomáliáit és kockázatait. Az SBOM géppel feldolgozható formában írja le ugyanezeket a komponenseket. Ezt használják a sérülékenységvizsgáló eszközök, és az FDA-hoz benyújtott dokumentációban is felhasználható.

A STRIDE-táblázat alapján biztonsági követelményeket határozunk meg. Minden védelmi intézkedéshez egyedi azonosítóval ellátott követelményt rendelünk. A nyomon követhetőségi mátrixban ezt a megfelelő kockázatcsökkentő intézkedéssel és az azt verifikáló teszttel kapcsoljuk össze.

A tesztesetsablonban határozzuk meg, milyen formában dokumentáljuk a mátrix tesztoszlopában hivatkozott teszteket. Minden végrehajtott tesztesetnél rögzítjük a buildet, az eredményt és a feltárt rendellenességeket.

01. példa

Részlet a SOUP-listából

Fiktív, szemléltető célú minta. A példaeszköz öt, harmadik féltől származó komponensét az IEC 62304 8.1.2. pontja szerint azonosítjuk. A dokumentáció az 5.3.3. pont szerinti követelményeket és a 7.1.3. pont szerinti anomáliavizsgálatot is tartalmazza.

IDKomponens és verzióForrás és licencA komponens szerepe az eszközbenA komponenssel szembeni követelményekKözzétett ismert hibákKockázat és indoklásSBOM-bejegyzés
SOUP-001FreeRTOS kernel V11.3.1freertos.org, MITA szenzoregység feladatainak ütemezéseA 10 ms-os mérési feladatot határidőcsúszás nélkül futtatja. A stack overflow észlelése engedélyezett.Felülvizsgáltuk a Cortex-M4 port release note-jait és issue trackerét. Az utolsó felülvizsgálat dátuma: 2026. szeptember 30. Nincs olyan nyitott hiba, amely az ütemező használt funkcióit érintené.Hozzájárulhat a HAZ-04 veszélyhez (késedelmes riasztás). A kockázatot az RC-07 hardveres watchdog csökkenti.Szenzoregység SBOM-ja, pkg:github/FreeRTOS/FreeRTOS-Kernel@V11.3.1
SOUP-002OpenSSL 3.5.9 (LTS)openssl.org, Apache 2.0TLS-kapcsolat a gateway és a felhő között az adatok feltöltéséhezCsak TLS 1.2 vagy újabb verzió használható. A szervertanúsítvány rögzített, tartalék tanúsítványlenyomattal. Az újratárgyalás tiltott.A biztonsági közleményeket havonta felülvizsgáljuk. Az utolsó felülvizsgálatot 2026. szeptember 30-án végeztük, a 3.5.8-as verzió frissítése után. Az LTS-ág támogatása 2030. április 8-ig tart.Csökkenti a THR-03 fenyegetés kockázatát. Hiba esetén az adatfeltöltés leáll, az adatok a gatewayen maradnak.Gateway SBOM-ja, pkg:github/openssl/openssl@openssl-3.5.9
SOUP-003SQLite 3.53.4sqlite.org, közkincs (public domain)A mérési adatok helyi tárolása a gatewayenAtomi commit WAL módban, synchronous=FULL beállítással. Minden induláskor integritásellenőrzést futtat.Felülvizsgáltuk a release logot és a CVE-listát. Az utolsó felülvizsgálat dátuma: 2026. szeptember 30. A komponens a 3.53.4-es verzióig megjelent javításokat tartalmazza. A használt funkciókat nem érinti nyitott hiba.Hozzájárulhat a HAZ-09 veszélyhez (mérési adatok elvesztése). A kockázatot az RC-09 intézkedés csökkenti. Ezt az STC-044 áramkimaradási teszttel verifikáljuk.Gateway SBOM-ja, pkg:generic/sqlite@3.53.4
SOUP-004zlib 1.3.2zlib.net, zlib licencA naplóarchívumok tömörítése feltöltés előttAz archívumokat 50 MB-os méretig veszteségmentesen tömöríti és állítja vissza. Az LT-02 terheléses tesztben ekkora volt a legnagyobb napi napló.Felülvizsgáltuk a változásnaplót és a CVE-listát. Az utolsó felülvizsgálat dátuma: 2026. szeptember 30. Egyik ismert hiba sem érinti a használt deflate funkciókat.Nem járul hozzá veszélyes helyzet kialakulásához. Az indoklást a SOUP-értékelés tartalmazza.Gateway SBOM-ja, pkg:github/madler/zlib@v1.3.2
SOUP-005nlohmann/json 3.12.0github.com/nlohmann/json, MITKonfigurációs fájl feldolgozásaA hibás bemenetet kivétel dobásával utasítja el. Részlegesen feldolgozott adatot nem ad vissza.Felülvizsgáltuk az issue trackert. Az utolsó felülvizsgálat dátuma: 2026. szeptember 30. Nincs releváns nyitott hiba.Hozzájárulhat a HAZ-06 veszélyhez (hibás riasztási határérték). A kockázatot az RC-11 tartományellenőrzés csökkenti.Gateway SBOM-ja, pkg:github/nlohmann/json@v3.12.0

Fiktív, szemléltető célú minta. Az eszköz fiktív, a nyílt forráskódú komponensek valósak. A teljes SOUP-listában minden komponens hardver- és szoftverkövetelményei is szerepelnek az IEC 62304 5.3.4. pontja szerint.

02. példa

Részlet a nyomon követhetőségi mátrixból

Fiktív, szemléltető célú minta. A követelményeket összekapcsoljuk a tervekkel, a forráskóddal, a tesztekkel és a kockázatokkal. A nyomon követhetőség az IEC 62304 7.3.3. pontjában előírt kockázatcsökkentő intézkedésekre is kiterjed.

KövetelményLeírásTervezésKódegységTesztKockázatÁllapot
SRS-014Ha a mért érték meghaladja a beállított határértéket, az eszköznek 10 másodpercen belül magas prioritású hang- és fényriasztást kell kiadnia. A riasztásnak a nyugtázásig aktívnak kell maradnia.SDD-3.2 Riasztáskezelőalarm/alarm_manager.cSTC-031, STC-033HAZ-04, RC-07Sikeres, build 2.4.0
SRS-021A mérési adatoknak akkor is meg kell maradniuk, ha írás közben megszakad az áramellátás.SDD-4.1 Adattárolásstorage/record_store.cppSTC-044HAZ-09, RC-09Sikeres, build 2.4.0
SRS-030A gateway kizárólag TLS 1.2 vagy újabb verzióval, rögzített szervertanúsítvány használatával tölthet fel adatokat.SDD-5.3 Felhőkapcsolatnet/tls_client.cppSTC-052, PEN-03THR-03, RC-12Sikeres, build 2.4.0
SRS-037A szenzoregység kizárólag érvényes digitális aláírással rendelkező firmware image-et fogadhat el.SDD-6.2 Firmware image verifikációjaboot/verify_image.cSTC-060, STC-061THR-05, RC-14Nyitott, a PR-118 anomália akadályozza a release-t
SRS-042A gateway kijelzőjén az utolsó mért érték mellett azt is meg kell jeleníteni, hogy mennyi idő telt el a mérés óta.SDD-2.4 Kezdőképernyőui/HomeView.qmlSTC-070, UE-05HAZ-11, RC-16Sikeres, build 2.4.0

Fiktív, szemléltető célú minta. Az UE-05 egy IEC 62366-1 szerinti használhatósági értékelés. A PEN-03 egy penetrációs teszteset. Az STC-033 hibainjektálással verifikálja az RC-07 intézkedést. Ha a riasztási feladat leáll, a watchdog legfeljebb 3 másodpercen belül újraindítja a szenzoregységet és megszólaltatja a tartalék hangjelzőt. A 2.4.0-s build a release-jelölt. A nyitott PR-118 anomália miatt még nem adható ki.

03. példa

Részlet a CycloneDX SBOM-ból

Fiktív, szemléltető célú minta.

A fiktív eszköz gateway firmware-ének SBOM-jából mutatunk be részletet CycloneDX 1.6 JSON-formátumban. A mintát kézzel állítottuk össze, a 2.4.0-s build Syft-vizsgálatának szerkezetét követve. A Syft saját bom-ref értékeket rendel a komponensekhez. Ezek helyett itt a SOUP-azonosítókat használjuk. A sérülékenységeket tartalmazó blokkot nem a vizsgálóeszköz állította elő. Ezt a mérnök egészíti ki, miután ellenőrizte, hogy az érintett kódrészlet elérhető-e. Négy komponenst mutatunk be. A teljes SBOM az operációs rendszert és a közvetett függőségeket is tartalmazza. Minden bom-ref a megfelelő SOUP-azonosítót tartalmazza, így a SOUP-lista és az SBOM egymásra hivatkozik. A hashértékek a projektek által közzétett forráskiadásokhoz tartoznak. Az SQLite esetében az sqlite3.c fájl SHA3-256 hashértékét adjuk meg. A sérülékenység azonosítója helyőrző. Valós SBOM készítésekor a buildből nyerjük ki a hashértékeket. Ezek a ténylegesen kiadott fájlokat azonosítják.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:e23dacfd-0f57-4635-9536-2fda9115f806",
  "version": 7,
  "metadata": {
    "timestamp": "2026-09-30T08:00:00Z",
    "authors": [{ "name": "Software team, fictional manufacturer" }],
    "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": "The affected function is not called. Reachability checked on the call graph of build 2.4.0, record VA-012, threat THR-03." } }
  ]
}

A sérülékenységeket tartalmazó blokkban minden ismert sérülékenységnél értékeljük, hogy érinti-e az eszközt. Ebben a példában a szoftver nem hívja meg az érintett függvényt. Az elérhetőségi vizsgálat eredményét a VA-012 dokumentumban rögzítjük. A bejegyzés a kapcsolódó fenyegetésre is hivatkozik. A felülvizsgáló ezeket a VEX-információkat kéri az SBOM mellé.

Az SBOM-ot a buildből állítjuk elő, így minden release-hez új változat készül. A SOUP-listát mérnök vizsgálja felül, ha valamelyik komponens, annak verziója vagy szerepe megváltozik. A havi sérülékenységvizsgálat során is felülvizsgáljuk.

04. példa

Részlet a STRIDE fenyegetéselemzési táblázatból

Fiktív, szemléltető célú minta. A fiktív eszköznél hét fenyegetést mutatunk be, amelyek lefedik a STRIDE mind a hat kategóriáját. A threat model az FDA forgalomba hozatal előtti kiberbiztonsági útmutatójának elvárásait követi. A biztonsági kockázatkezelést az IEC 81001-5-1 szerint végezzük.

IDRendszerelemSTRIDEFenyegetésHatás az eszközreVédelmi intézkedésVerifikációFennmaradó kockázat és besorolása
THR-01BLE-kapcsolat a szenzor és a gateway közöttIdentitáshamisításEgy közeli eszköz a szenzornak adja ki magát, és mérési adatokat küld.A felhasználó hamis mérési értékeket lát.LE Secure Connections sávon kívüli párosítási adatokkal és MITM-védelemmel, mivel a szenzoregységnek nincs kijelzője. Csak korábban párosított eszközök csatlakozhatnak.PEN-01Alacsony (alacsony valószínűség, súlyos hatás), elfogadva
THR-02Adattárolás a gatewayenAdatmódosításA fájlrendszerben tárolt adatokat módosítják vagy korábbi adatokkal helyettesítik.A kezelőorvos módosított mérési előzményeket lát.Rekordonként HMAC és sorszám, a kulcsot a secure element tároljaSTC-045Alacsony (alacsony valószínűség, közepes hatás), elfogadva
THR-03Adatfeltöltés a felhőbeInformációk illetéktelen megszerzéseLehallgatják a gateway és a felhő közötti adatforgalmat.Illetéktelen személyek férnek hozzá az egészségügyi adatokhoz.TLS 1.2 vagy újabb verzió, rögzített szervertanúsítvánnyal és tartalék tanúsítványlenyomattal a tanúsítványcseréhezSTC-052, PEN-03Alacsony (alacsony valószínűség, súlyos hatás), elfogadva
THR-04Konfiguráció módosításaLetagadhatóságValaki módosítja a riasztási határértéket, de utólag nem állapítható meg, ki tette.A panasz kivizsgálásakor nem lehet visszakövetni, ki végezte a módosítást.Digitálisan aláírt auditnapló a felhasználó azonosítójával és időbélyeggel. Minden adatfeltöltéskor a felhőbe is átmásoljuk.STC-081Alacsony (alacsony valószínűség, közepes hatás), elfogadva
THR-05Firmware-frissítésAdatmódosításMódosított firmware image-et telepítenek a szenzoregységre.Az alapvető működési jellemzők elvesztéseDigitálisan aláírt firmware image-ek, secure boot és rollback counterSTC-060, STC-061Közepes (közepes valószínűség, súlyos hatás), a PR-118 lezárásáig nyitott
THR-06Felhőalapú APISzolgáltatásmegtagadásNagy mennyiségű kérés blokkolja az adatfeltöltési végpontot.A mérési adatok késve érkeznek meg a klinikára. A helyi riasztás működését ez nem érinti.Kérésgyakorisági korlátok és 72 órás helyi adattárolási kapacitás a gatewayen. A rendszer a legnagyobb mintavételi frekvencia mellett is három nap adatait tárolja.LT-03 (tárolókapacitás-teszt)Alacsony (közepes valószínűség, csekély hatás), elfogadva
THR-07USB-szervizportJogosultságszint-emelésEgy éles üzemben használt eszközön elérhető a debug shell.A támadó teljes irányítást szerezhet az eszköz felett.A debug interfészeket a release buildben letiltjuk, a JTAG-hozzáférést zároljuk.STC-090, release-ellenőrzőlistaAlacsony (alacsony valószínűség, súlyos hatás), elfogadva

Fiktív, szemléltető célú minta. A valószínűséget és a hatást a kiberbiztonsági kockázatkezelési terv skálái szerint értékeljük. Minden fennmaradó kockázatot egy név szerint kijelölt kockázatfelelős fogad el. A nyomon követhetőségi mátrixban minden védelmi intézkedéshez biztonsági követelményt rendelünk. A THR-03 fenyegetéshez ott az SRS-030 követelmény tartozik.

05. példa

Kitöltött tesztesetsablon

Fiktív, szemléltető célú minta. Az SRS-014 követelményhez tartozó szoftverrendszer-tesztesetet mutatjuk be. A dokumentum az IEC 62304 5.7.5. pontjában előírt adatokat tartalmazza.

MezőTartalom
Teszteset-azonosítóSTC-031
MegnevezésMagas prioritású riasztás a mérési határérték túllépésekor
Kapcsolódó azonosítókSRS-014, HAZ-04. Az RC-07 kockázatcsökkentő intézkedést külön, az STC-033 teszttel verifikáljuk.
Tesztszint és szoftverbiztonsági osztálySzoftverrendszer-teszt, B szoftverbiztonsági osztály az IEC 62304 4.3. pontja szerint. Ha egy szoftverhiba késlelteti a riasztást, az RC-07 intézkedés lép működésbe. Ez egy szoftvertől független hardveres watchdog, amely újraindítja a szenzoregységet és közvetlenül működteti a tartalék hangjelzőt. Az RC-07 alkalmazásával a legsúlyosabb lehetséges következmény nem súlyos sérülés. Ez indokolja a B szoftverbiztonsági osztályt.
ElőfeltételekA gateway és a szenzoregység párosítva van. A riasztási határértéket 120-ra állítottuk, és a mérés legalább 60 másodperce fut.
TesztkörnyezetC hardverrevíziójú szenzoregység 2.4.0-s firmware-rel, 2.4.0-s gateway image, SIM-2 jelszimulátor CAL-207 kalibrálási jegyzőkönyvvel, 0,1 s-os időzítőfelbontás
Tesztlépések1. Adjunk 110-es értéket 30 másodpercig. 2. Adjunk pontosan 120-as értéket, vagyis a határértéket, 30 másodpercig. 3. Emeljük az értéket 121-re, és indítsuk el az időmérést. 4. Tartsuk az értéket 20 másodpercig. 5. Csökkentsük 110-re, és várjunk 10 másodpercet. 6. Nyugtázzuk a riasztást.
Elvárt eredményAz 1. és 2. lépésben nem indul riasztás. A 3. lépés után 10 másodpercen belül magas prioritású hang- és fényriasztás indul. Az 5. lépésben megszűnik a riasztást kiváltó állapot, de a riasztás a 6. lépésben történő nyugtázásig aktív marad.
A sikeres és sikertelen tesztek kritériumaiA teszt akkor sikeres, ha mind a 10 ismétlésben teljesülnek a feltételek. A határérték elérésekor nem indul riasztás. A határérték túllépése után 10 másodpercen belül elindul, és a nyugtázásig aktív marad. Ha bármelyik ismétlésben eltérést tapasztalunk, a teszt sikertelen.
Tényleges eredmény120-as értéknél mind a 10 ismétlésben elmaradt a riasztás. A határérték túllépésekor a riasztás mind a 10 esetben 6,2 és 7,9 másodperc között indult el, átlagosan 7,1 másodperc után. Mind a 10 ismétlésben aktív maradt a nyugtázásig. Az egyes mérések időeredményeit a 2.4.0-s build futtatási naplója tartalmazza.
TeszteredménySikeres
Tesztelő, dátum, build[tesztelő], [dátum], build 2.4.0
Feltárt rendellenességekNincs
Felülvizsgálta[felülvizsgáló], [dátum]

Fiktív, szemléltető célú minta. A neveket és a dátumokat helyőrzők jelölik.

06. példa

Az FDA Pre-Submission dokumentációjának vázlata

Fiktív, szemléltető célú minta. Bemutatjuk az FDA Q-Submission programjához tartozó Pre-Submission dokumentáció felépítését. A vázlatot FDA-tanácsadóink készítették, és az FDA-nak szánt konkrét kérdéseket is tartalmazza.

SzakaszTartalom
KísérőlevélPre-Submission egyeztetést kérünk egy hálózatra kapcsolt otthoni monitorozó eszközhöz. Megadjuk az egyeztetés kért formáját (telekonferencia) és a kapcsolattartó személyt.
Az eszköz leírásaBemutatjuk a firmware-t futtató szenzoregységet, az érintőképernyős Linux gatewayt és a felhőalapú adatfeltöltést. Ismertetjük a részegységek együttműködését, a mért paramétert és a riasztási funkciót. A leíráshoz rendszerábrát is mellékelünk.
Javasolt alkalmazási javallatokMegfogalmazzuk a tervezett rendeltetést és az alkalmazási javallatokat. Meghatározzuk a betegpopulációt és a használati környezetet (otthon).
Korábbi szabályozási eljárásokAz eszközhöz nem kapcsolódik korábbi FDA-benyújtás. Az EU MDR szerinti CE-jelölés előkészítése folyamatban van.
Tervezett szabályozási eljárás510(k) eljárást tervezünk, és referenciaeszközt javasolunk. Röviden összehasonlítjuk a két eszköz rendeltetését és technológiai jellemzőit.
Tervezett vizsgálatokAz alapvető biztonságot és az alapvető működési jellemzőket az IEC 60601-1 szerint vizsgáljuk. Az elektromágneses összeférhetőséget az IEC 60601-1-2, a riasztásokat az IEC 60601-1-8, az otthoni használatot az IEC 60601-1-11 szerint teszteljük. A szoftververifikációt az IEC 62304, a használhatóságot az IEC 62366-1 szerint vizsgáljuk. Elkészítjük az FD&C Act 524B. szakasza szerinti kiberbiztonsági dokumentációt.
1. kérdésEgyetért-e az FDA azzal, hogy a javasolt referenciaeszköz megfelelő a tervezett alkalmazási javallatokban meghatározott rendeltetéshez?
2. kérdésEgyetért-e az FDA azzal, hogy a tervezett riasztásteljesítmény-vizsgálatok elegendők a lényegi egyenértékűség alátámasztásához?
3. kérdésEgyetért-e az FDA azzal, hogy a gateway és a felhőkapcsolat tervezett penetrációs tesztjei elegendők a benyújtott kiberbiztonsági dokumentáció alátámasztásához?

Fiktív, szemléltető célú minta. A kérdéseket a fiktív eszközhöz állítottuk össze.

07. példa

A klinikai AI-alkalmazások rangsorolása

Fiktív, szemléltető célú minta. Egy kórházi felkészültségi felmérés első eredményeit mutatjuk be. Az alkalmazásokat a várható előnyök, a rendelkezésre álló bizonyítékok és a bevezetés feltételei alapján rangsoroljuk. Az egyik alkalmazás bevezetését egyelőre nem javasoljuk.

IDAlkalmazási területOsztályVárható előnyA megfelelőséget alátámasztó dokumentációFő feltételRangsor
UC-01Csonttörések felismerése sürgősségi röntgenfelvételekenRadiológia, sürgősségi osztályMagasErős, CE-jelöléssel rendelkező termékekPACS-integráció1
UC-04Mammográfiás szűrés támogatásaRadiológia, szűrővizsgálatokMagasErős, publikált tanulmányokElőször helyi validáció szükséges2
UC-02Zárójelentés-tervezetek készítéseBelgyógyászatMagasKorlátozott, pilotvizsgálatból származó adatokPilotprojekt helyi eredményméréssel3
UC-03Időpontfoglalási asszisztens az ügyfélszolgálati központbanBetegfogadásKözepesKorlátozottIntegráció az időpontfoglalási rendszerrel4
UC-05Szepszis előrejelzése a betegdokumentáció alapjánFekvőbetegosztályokBizonytalanGyenge külső bizonyítékokNem indult elEgyelőre nem javasolt

Fiktív, szemléltető célú minta egy fiktív kórházhoz. A rangsort először a várható előnyök, majd a bizonyítékok erőssége alapján állítjuk fel. Ezután azt is mérlegeljük, mennyi munkát igényel a legfontosabb feltétel teljesítése. A várható előnyöket a kórház saját esetszámai és a munkatársak időráfordítása alapján becsüljük meg.

08. példa

AI-szállítók pontozási mátrixa

Fiktív, szemléltető célú minta. Három fiktív terméket hasonlítunk össze a kórházzal előzetesen egyeztetett szempontok szerint. Az értékeléssel a beszerzési döntést készítjük elő.

Értékelési szempontSúly (%)A szállítóB szállítóC szállító
Kizáró feltétel: a rendeltetés kiterjed a tervezett alkalmazásraMegfelel vagy nem felel megMegfelelMegfelelMegfelel
Kizáró feltétel: az eszköz rendelkezik CE-jelöléssel a tervezett rendeltetésreMegfelel vagy nem felel megMegfelelMegfelelMegfelel
Klinikai bizonyítékok összehasonlítható betegpopulációkból30342
Integráció a PACS-, RIS- és betegdokumentációs rendszerekkel20424
Adatvédelem és EU-n belüli tárhelyszolgáltatás20534
A szállító tájékoztatása a monitorozásról és a változásokról15342
Hároméves teljes költség15344
Súlyozott pontszám1003.603.403.10

Fiktív, szemléltető célú minta. Ha egy termék nem teljesíti valamelyik kizáró feltételt, nem pontozzuk. A többi terméket szempontonként 1-től 5-ig értékeljük, előre meghatározott skála alapján. A súlyokat az értékelés előtt egyeztetjük a kórházzal.

09. példa

A helyi validáció eredményeinek összefoglalója

Fiktív, szemléltető célú minta. Egy fiktív AI-eszköz helyi validációjának eredményeit mutatjuk be. A kórház saját vizsgálati anyagait használjuk, és az éles bevezetés előtt alcsoportonként is értékeljük az eszköz teljesítményét.

MezőTartalom
Eszköz és verzió[termék], fiktív, CE-jelöléssel rendelkező törésfelismerő eszköz, 2.1-es verzió
Ellenőrzött rendeltetésCsonttörések felismerése felnőttek végtagjairól készült röntgenfelvételeken, a leletező orvos döntésének támogatására
AdathalmazRetrospektív vizsgálat 1 200 felvételsorozattal, amelyek közül 380 tartalmazott törést. Az adatokat egy év alatt gyűjtöttük két osztályon, két röntgenberendezéssel. Alcsoportok: A rendszer 640, B rendszer 560, 75 év feletti betegek 210 vizsgálata (ebből 70 töréssel).
Referencia-standardKét radiológus konszenzusos értékelése, véleménykülönbség esetén harmadik radiológus bevonásával. Az értékelők nem ismerik az eszköz eredményét.
Elfogadási kritériumokAz elfogadási kritériumokat a mérés előtt rögzítettük a validációs tervben. A szenzitivitásnak legalább 0,90-et, a specificitásnak legalább 0,85-öt kell elérnie a teljes adathalmazon és minden alcsoportban.
Eredmény a teljes adathalmazonSzenzitivitás: 0,92 (95%-os konfidenciaintervallum: 0,89 és 0,94 között). Specificitás: 0,88 (0,86 és 0,90 között).
Eredmények alcsoportonkéntA rendszer: szenzitivitás 0,93 (0,89 és 0,96 között), specificitás 0,89 (0,86 és 0,92 között). B rendszer: szenzitivitás 0,91 (0,86 és 0,94 között), specificitás 0,87 (0,83 és 0,90 között). 75 év felett: szenzitivitás 0,89 (0,79 és 0,94 között), specificitás 0,84 (0,77 és 0,89 között).
KövetkeztetésA teljes adathalmazon és mindkét röntgenberendezés esetében teljesültek az elfogadási kritériumok. A 75 év feletti betegeknél azonban nem teljesültek. Ezt DV-03 eltérésként rögzítettük. A kórház AI-felügyeleti bizottsága úgy döntött, hogy ebben a betegcsoportban egyelőre nem használják az eszközt. Előbb nagyobb adathalmazon kell megismételni a validációt.
Monitorozási tervHavonta mintavételes szenzitivitásmérés, az AI-javaslatok felülbírálási arányának követése osztályonként, egyeztetett felülvizsgálati küszöbérték

Fiktív, szemléltető célú minta. Minden számadatot ehhez a példához alkottunk meg.

Ügyfélprojektek

Ügyfeleinknek is készítünk ilyen dokumentumokat

Ezek a dokumentumtípusok az általunk fejlesztett termékek dokumentációjában is szerepelnek. Az alábbi esettanulmányokban bemutatott projektekben mi készítettük el őket, az ügyfél minőségirányítási rendszerében és dokumentumkezelési előírásai szerint.

DokumentumÜgyfélprojektben végzett munkaEsettanulmány
Nyomonkövethetőségi mátrix, mint a 02. példábanA felhasználói igényektől a verifikált teszteredményekig nyomon követhető kapcsolatokat alakítottunk ki. Minden változtatásnál összekapcsoltuk az érintett követelményt a verifikációval.Laboratóriumi eszköz refaktorálása, funkciófejlesztés az IEC 62304 szerint, QA és DevOps szabályozott szoftverportfólióhoz
Tesztesetek és tesztjelentések, mint a 05. példábanVerifikációs tervet és tesztjelentéseket készítettünk. Minden release-hez regressziós teszteredményeket is dokumentáltunk.Laboratóriumi eszköz refaktorálása, QA és DevOps szabályozott szoftverportfólióhoz
Szoftverkövetelmény-specifikációA követelményeket úgy dokumentáltuk, hogy azok alapján validációt lehessen végezni.Laboratóriumi eszköz refaktorálása és IEC 62304 szerinti dokumentációja
Kockázatértékelés minden változtatáshozMinden változtatásnál értékeltük a kockázatokat az ISO 14971 szerint. Az eredményeket összekapcsoltuk a megfelelő verifikációval.Funkciófejlesztés az IEC 62304 szerint egy nagy .NET-kódbázisban
Gap analysis jelentésAz IEC 62304, az FDA és az MDR követelményei alapján rangsoroltuk a feltárt eltéréseket. Mindegyikhez javító intézkedést javasoltunk.Beágyazott firmware gap analysise

Az ügyféldokumentumok az ügyfeleknél maradnak, ezért itt nem mutatjuk be őket.

A feladatok köre

Mit mutatnak be a példák, és mire nem szolgálnak

Amit bemutatunk

  • Az egyes dokumentumok mezői és azonosítói
  • Az öt dokumentum közötti hivatkozások
  • Egy-egy sor részletessége
  • Valós nyílt forráskódú komponensek valós verziószámokkal

Amire a példák nem szolgálnak

  • Nem ügyféldokumentumok másolatai vagy részletei
  • Nem helyettesítik a minőségirányítási rendszerben előírt sablonokat
  • Nem igazolják egy hatósági benyújtás eredményét
  • Nem teljes dokumentumok, mindegyik csak részletet mutat be
FAQ

Kérdések a mintákról

01

Miben különbözik a SOUP-lista az SBOM-tól?

Az SBOM géppel feldolgozható formátumban, például CycloneDX vagy SPDX szerint sorolja fel a szoftverkomponenseket. Tartalmazza a verziót, a szállítót, a licencet és a hashértéket, így a sérülékenységek követésére használható. Az IEC 62304 szerinti SOUP-listában ezen felül rögzítjük a komponens szerepét és követelményeit. Dokumentáljuk a közzétett ismert hibák felülvizsgálatát és a komponens kockázatokban betöltött szerepét is. Egy orvostechnikai eszközhöz mindkét dokumentum szükséges, közös komponensazonosítókkal.

02

Milyen SBOM-formátumot adtok át?

A példában bemutatott CycloneDX JSON-formátumot használjuk, vagy SPDX-et, ha az ügyfél eszközei ezt igénylik. A formátumot a vizsgálóeszköz és a tervezett hatósági benyújtási eljárás alapján választjuk ki. A tartalom mindkét esetben ugyanaz.

03

A saját sablonjainkban vagy a tieitekben dolgoztok?

A minőségirányítási rendszeredben előírt sablonokat használjuk. A példák azt mutatják be, milyen adatokat kell tartalmazniuk a dokumentumoknak. Ezeket a saját formátumaidban, a dokumentumkezelési szabályaid szerint rögzítjük.

04

Megnézhetünk egy teljes dokumentumot egy valós projektből?

Nem. Az ügyféldokumentumok az ügyfelek tulajdonában vannak, és szerződéseink alapján bizalmasan kezeljük őket. Az oldalon szereplő példák a dokumentumok felépítését mutatják be. Egy szakmai egyeztetésen átbeszélhetjük, hogyan készítjük el ugyanezeket a dokumentumokat egy konkrét eszközhöz.

05

Mely szabványok követelményeihez kapcsolódnak ezek a dokumentumok?

A SOUP-lista, a nyomon követhetőségi mátrix és a tesztdokumentáció az IEC 62304 követelményeihez kapcsolódik. A kockázatkezelési hivatkozásokat az ISO 14971 szerint készítjük. A fenyegetéselemzési táblázat és az SBOM az IEC 81001-5-1, valamint az FDA forgalomba hozatal előtti kiberbiztonsági útmutatójának követelményeihez igazodik. A mátrixban hivatkozott használhatósági értékelést az IEC 62366-1 szerint végezzük.

Kapcsolódó tartalmak

Kapcsolódó projektek és oldalak

Az ügyfelek nevét csak a hozzájárulásukkal tesszük közzé.

Vedd fel velünk a kapcsolatot

Ilyen dokumentumokra van szükséged az eszközödhöz?

Küldd el a követelményeket és a meglévő dokumentációt. Az első egyeztetésen áttekintjük, mely dokumentumok készültek már el, és melyek hiányoznak.