Technická dokumentace pro SaMD: co soubor skutečně potřebuje

Technický soubor pro software není to samé jako pro hardware

Pokud přicházíte z hardwarového prostředí a pokusíte se adaptovat šablonu hardwarového technického souboru na software, vytvoříte něco, co vypadá kompletně, ale postrádá to, co Notifikované osoby skutečně potřebují vidět. Technická dokumentace softwaru má jiný tvar: je silně zaměřena na procesní důkazy — dokumentaci toho, jak byl software vyvíjen, testován a udržován — spíše než na fyzické specifikace.

Rámec stanovuje MDR Příloha II a Příloha III. Pro software ale obsah několika sekcí Přílohy II dále upřesňuje IEC 62304, harmonizovaná norma pro životní cyklus vývoje softwaru zdravotnických prostředků. Tyto dva zdroje musí v souboru spolupracovat. Pochopit, jak se na sebe mapují, je správné místo, kde začít.

Co vyžaduje IEC 62304 a proč na tom záleží

IEC 62304 definuje model životního cyklu pro software zdravotnických prostředků. Norma přiřazuje každému softwarovému systému bezpečnostní klasifikaci (třída A, B nebo C) podle potenciální závažnosti újmy způsobené selháním softwaru. Tato klasifikace souvisí s třídou prostředku podle MDR, ale není s ní totožná — klasifikace IEC 62304 určuje hloubku dokumentace a testování požadovanou normou.

V praxi to pro technický soubor znamená:

• Plán vývoje softwaru — váš zdokumentovaný přístup k vývoji: metodologie, nástroje, role v týmu, praktiky správy verzí, procesy řízení změn. Notifikované osoby sem hledí, aby pochopily, zda máte řízené vývojové prostředí.
• Specifikace požadavků na software — všechny funkční a bezpečnostní požadavky, včetně těch odvozených z analýzy rizik. Častá mezera: požadavky na software, které nelze zpětně dohledat k zamýšlenému účelu a GSPR.
• Dokument softwarové architektury — strukturální rozklad systému na softwarové položky. Pro třídy B a C musí ukazovat, jak jsou identifikovány bezpečnostně kritické komponenty.
• Detailní projektové dokumenty — pro třídu C až na úroveň jednotek.
• Záznamy ověření a validace — plány testů, testovací případy, výsledky testů. Záznamy musí prokázat, že jste testovali vůči specifikovaným požadavkům — ne jen to, že software „funguje".
• Záznamy řešení problémů — jak řešíte chyby, anomálie a defekty nalezené během vývoje a po uvedení na trh.

Pro software třídy A (selhání nemůže přispět k újmě) jsou požadavky lehčí. Pro třídu C (selhání může způsobit smrt nebo vážnou újmu) je dokumentační zátěž výrazně větší.

Struktura Přílohy II pro technický soubor softwaru

Takhle se technický soubor softwaru typicky mapuje na Přílohu II:

Oddíl 1 — Popis a specifikace prostředku: popis softwaru včetně zamýšleného účelu, přehledu uživatelského rozhraní, shrnutí systémové architektury, specifikací hardwarového/softwarového prostředí (operační systém, verze prohlížeče, závislosti) a popisu všech softwarových komponent.

Oddíl 2 — Informace dodávané s prostředkem: návod k použití, označení, školicí materiály. Pro software návod k použití často pokrývá omezení specifická pro danou verzi, minimální hardwarové specifikace a pokyny pro uživatele v oblasti kybernetické bezpečnosti.

Oddíl 3 — Informace o návrhu a výrobě: pro software se stává dokumentací SDLC — artefakty IEC 62304. Pro většinu SaMD souborů je toto největší sekce.

Oddíl 4 — GSPR: vaše matice sledovatelnosti ukazující, jak je každý příslušný Obecný požadavek na bezpečnost a výkon řešen. Pro software GSPR 14–17 vyžadují největší úsilí: IT bezpečnost (17.2), interoperabilita a elektronická data.

Oddíl 5 — Analýza rizika/přínosu: váš soubor řízení rizik podle ISO 14971. Pro software zahrnuje rizika specifická pro software: selhání algoritmů, nesprávné výstupy, rizika konektivity, hrozby kybernetické bezpečnosti jako nebezpečné situace.

Oddíl 6 — Ověření a validace produktu: shrnutí V&V odkazující na podrobné záznamy v Oddílu 3.

Oddíl 7 — Data po uvedení na trh: váš plán sledování po uvedení na trh, plán PMCF a veškerá data shromážděná po spuštění.

Oddíl 8 — Klinické hodnocení: váš CER nebo ekvivalent. Pro software je tato sekce tou, kterou většina týmů podceňuje nejvíce. Podrobnosti najdete v zdroji o klinickém hodnocení v této kategorii.

Správa verzí — místo, kde to většinu týmů dostihne

Každá vydaná verze softwaru musí být v technickém souboru identifikovatelná. To neznamená samostatný technický soubor pro každou verzi — znamená to, že soubor musí jasně uvádět, pro kterou verzi platí, a váš proces řízení změn musí dokumentovat, jak bylo každé vydání posouzeno vůči původním požadavkům a souboru rizik.

Praktické pravidlo: změna, která přináší nové funkce, mění zamýšlený účel nebo ovlivňuje bezpečnostně kritické komponenty, vyžaduje zdokumentované posouzení změny a potenciálně re-kvalifikaci nebo nové posuzování shody. I „drobná" aktualizace, která opravuje chybu v bezpečnostně kritické komponentě, musí projít procesem řízení změn a být zdokumentována.

Do tohoto vstupuje i UDI — verze softwaru nad určitými prahovými hodnotami spouštějí aktualizace UDI. To je pokryto ve zdroji o registraci v EUDAMED v této kategorii.

Co Notifikovaná osoba skutečně hledá

Týmy jsou často překvapeny, čemu Notifikované osoby v souboru SaMD věnují nejvíc času. Obvykle to nejsou diagramy architektury. Je to sledovatelnost — dokážete ukázat nit od zamýšleného účelu, přes požadavky, přes návrh, přes testování, přes kontroly rizik až ke shodě s GSPR? Mezery v této niti jsou místem, kde se hromadí otázky NB.

Budujte soubor se sledovatelností v mysli od prvního dne. Nástroj pro správu požadavků, který propojuje požadavky s testovacími případy a zmírněními rizik, se vrátí v ušetřeném čase při přezkumu.