Termíny a definice týkající se softwaru pro zdravotnické prostředky – IEC 62304 a FDA (část 2)

Termíny a definice týkající se softwaru pro zdravotnické prostředky – IEC 62304 a FDA (část 2)

Tento článek je součástí naší série věnované normě IEC 62304, která se zaměřuje na pochopení této normy a na to, jak ji správně implementovat při vývoji softwaru pro zdravotnické prostředky.

Předchozí články:

• Jak začít s implementací normy IEC 62304
• Termíny a definice týkající se softwaru pro zdravotnické prostředky – část 1

Toto je druhá část našeho pohledu na termíny definované v normě IEC 62304. V tomto článku se budeme zabývat následujícími pojmy:

• ARCHITEKTURA
• DETAILNÍ NÁVRH SOFTWARU
• SYSTÉM A SOFTWAROVÝ SYSTÉM
• SOUP/OTS
• SLEDOVATELNOST
• ŽIVOTNÍ CYKLUS PRODUKTU

Pokud ještě nemáte vlastní výtisk normy IEC 62304, můžete si jej za velmi rozumnou cenu zakoupit na stránkách www.evs.ee, estonského centra pro normalizaci a akreditaci.

(Doporučujeme zvolit licenci pro více uživatelů ve formátu PDF. Je mnohem snazší k ní přistupovat a číst ji, aniž byste potřebovali jakýkoli další software s pluginy na ochranu autorských práv.)

Oficiální znění většiny termínů a definic najdete také na webových stránkách ISO.

Porozumění termínům vás posune vpřed

Během své konzultační kariéry jsem se často setkával se situacemi, kdy týmy nebyly sjednocené v terminologii používané v normách, kterými se řídí. To obvykle vede k opakujícím se diskusím o tom, zda interní SOP skutečně vyhovují normám, nebo zda termíny používané v interních procesech skutečně odpovídají těm popsaným v normách.

Je důležité si uvědomit, že všechny normy ISO a IEC se v průběhu času vyvíjely; nebyly vytvořeny najednou. Z tohoto důvodu mezi nimi přirozeně najdete určité nesrovnalosti. Důležitější než hledání „dokonalé“ definice pojmu je rozhodnout, jak jej vaše organizace bude interpretovat, tuto interpretaci zdokumentovat a důsledně ji uplatňovat.

Jasně definované pojmy a definice umožňují vaší organizaci používat je konzistentně napříč procesy. Také je mnohem snazší je v případě potřeby přizpůsobit nebo aktualizovat, což zajišťuje, že všichni mluví stejným jazykem, a pomáhá zabránit zmatkům během auditů.

Níže je uveden druhý soubor termínů a definic, které my v QMLogic používáme při pomoci klientům s vývojem jejich interních postupů. Tyto vycházejí nejen z našich zkušeností s návrhem procesů podle IEC 62304, ale také z naší účasti na četných auditech a naší práce na zjištěních zákazníků a projektech nápravných opatření CAPA.

Architektura a architektonický návrh v normě IEC 62304

Termín architektura je pro mnoho vývojářů srozumitelný a ani norma IEC 62304 se o něm v části Termíny a definice příliš nezmiňuje. Popisuje jej pouze jako organizační strukturu systému nebo komponenty.

Navzdory zdánlivé jednoduchosti způsobuje v organizacích mnoho potíží, zejména pokud jde o sledovatelnost nebo souvislosti s různými činnostmi, které s ní souvisejí.

Při dalším čtení normy IEC 62304 se s tímto pojmem setkáte na mnoha místech a definované požadavky na architekturu odhalí její skutečný zamýšlený význam. Dále zjistíte, že norma rozlišuje mezi architekturou a architektonickým návrhem.

A bez správného pochopení tohoto rozdílu můžete mít potíže s dodržením normy.

Architektonický návrh

Architektonický návrh je činnost. Je to to, co softwaroví architekti, nebo obecně vývojáři, pravidelně dělají během konkrétních fází návrhu a vývoje. Naopak výstupem této činnosti je samotná architektura.

V průběhu celého procesu návrhu a vývoje budete promítat softwarové požadavky do architektury, definovat rozhraní mezi softwarovými komponentami a identifikovat komponenty SOUP/OTS (viz následující kapitola), abyste je integrovali do celkového softwarového systému.

Všechny tyto kroky jsou součástí softwarového návrhu — procesu definování struktury, komponent a rozhraní softwaru tak, aby splňovaly specifikované požadavky.

Vše, co z těchto činností vzejde, je poté zdokumentováno jako architektura.

Softwarová architektura

Častou chybou — a častým zdrojem potíží pro vývojové týmy — je považovat softwarovou architekturu pouze za grafický diagram. Samotný obrázek však nemůže zachytit všechny činnosti a výsledky architektonického návrhu, jak byly definovány výše.

Norma IEC 62304, oddíl 5.3.6, stanoví, že by mělo být provedeno a zdokumentováno ověření softwarové architektury, aby se zajistilo, že všechny softwarové požadavky jsou správně zohledněny v celkové architektuře a že celková architektura podporuje rozhraní mezi komponentami. Tato úroveň ověření prostě není možná pouze na základě obrázku a vyžadovala by detailní obrázek.

Proto je nejlepší vnímat softwarovou architekturu jako živý dokument, se kterým vývojáři aktivně pracují a který pravidelně aktualizují.

Tento dokument by měl obvykle obsahovat:

• grafický diagram znázorňující vztahy mezi komponentami
• popis vysvětlující, co diagram představuje
• seznam softwarových položek
• seznam externích softwarových komponent, známý také jako SOUP/OTS
• Definované architektonické pohledy a úrovně detailu

Co mám na mysli pod pojmem architektonický pohled nebo úroveň detailu?

Je důležité chápat softwarovou architekturu jako soubor diagramů a popisů, nikoli pouze jako jedinou vizualizaci. Každý diagram může zobrazovat jinou úroveň detailu v závislosti na tom, co znázorňuje.

Například jeden diagram může ilustrovat rozhraní k hardwarové komponentě, jiný může ukázat, jak jsou citlivá data oddělena v databázi, a další může popisovat, jak je komunikace šifrována. Každý z těchto diagramů řeší různé požadavky na nezbytné úrovni detailu.

Ve společnosti QMLogic jsme velkými fanoušky pokynů FDA, protože často poskytují jasnější vhled do regulačních očekávání. Doporučujeme prostudovat pokyny FDA „Obsah předložených materiálů před uvedením na trh pro softwarové funkce zařízení“ (14. června 2023), konkrétně sekci E: Diagram architektury systému a softwaru.

Detailní návrh softwaru v normě IEC 62304

Jakmile pochopíme, že softwarová architektura může existovat na různých úrovních detailu, snáze pochopíme i další pojem z normy — detailní návrh softwaru.

Ačkoli norma IEC 62304 návrh softwaru jasně nedefinuje, kapitola 5.4, která se na toto téma zaměřuje, ukazuje, že lze uplatnit stejné principy jako u softwarové architektury, jen s větší hloubkou a přesností. Jinými slovy, podrobný návrh softwaru lze vnímat jako podrobnější pohled na architekturu konkrétní softwarové komponenty.

Nenechte se tedy příliš svázat snahou striktně oddělit softwarovou architekturu od podrobného návrhu softwaru. Představují různé úrovně detailu v rámci stejného konceptu a je zcela přijatelné popsat je oba v jediném dokumentu.

Další pokyny lze opět najít v dokumentu „Obsah předložených materiálů před uvedením na trh pro softwarové funkce zařízení“ (14. června 2023), kde FDA odkazuje na tento dokument jako na SDS (specifikace návrhu softwaru).

Obrázek 1: Specifikace návrhu softwaru podle definice FDA

Vedení podrobného návrhu softwaru – důsledky pro FDA a kyberbezpečnost

Podle normy IEC 62304 je dokument podrobného návrhu softwaru formálně vyžadován pouze pro systémy softwarové bezpečnostní třídy C (toto téma dále rozebíráme v našem článku „Jak začít s implementací normy IEC 62304“). Důrazně však doporučujeme vést takový dokument z několika dalších důležitých důvodů.

Za prvé, FDA může tento dokument požadovat během předložení žádosti o uvedení na trh nebo při inspekci FDA.

Za druhé, norma IEC 62304 definuje požadovanou úroveň technické dokumentace především z hlediska bezpečnosti produktu. V dnešním světě propojených zařízení a cloudových řešení se však kyberbezpečnost stala stejně důležitou a návrh softwaru nyní hraje v kyberbezpečnosti významnější roli než dříve.

Normy kybernetické bezpečnosti, jako je IEC 81001-5-1, výslovně vyžadují činnosti v oblasti návrhu softwaru, jako jsou ty popsané níže v úryvcích z normy.

Obrázek 2: IEC 81001-5-1: Návrh softwarové architektury

Obrázek 3: IEC 81001-5-1: Návrh softwaru

Softwarový systém, systém a řešení

Význam pojmu softwarový systém je poměrně jasný; odkazuje na soubor softwarových položek (definici pojmu „položka“ najdete v 1. části této série).

Je však důležité si uvědomit, že norma IEC 62304 definuje také pojem systém. Norma jej popisuje jako kombinaci vzájemně interagujících prvků, jako jsou procesy, hardware, software a lidé.

Zatímco procesy a lidi můžeme prozatím ponechat stranou, neměli byste přehlížet hardware, úložiště dat, cloudové prostředí nebo komunikační infrastrukturu spojené s vašimi softwarovými produkty.

Z mé zkušenosti jsou tato rozhraní obvykle zřetelnější pro vývojáře pracující na vestavěném softwaru, ale při vývoji na vyšší úrovni samostatného softwaru pro zdravotnická zařízení jsou často přehlížena.

Proč na tom záleží? Protože výkon, dostupnost a bezpečnost vašeho softwarového produktu mohou být ovlivněny systémem, v němž funguje. Proto je důležité při provádění testování, řízení rizik nebo činností v oblasti kyberbezpečnosti zohlednit celý systém, nejen softwarový systém.

Můžete se také setkat s pojmem řešení. Tento pojem není v normě formálně definován a lze jej používat různými způsoby. Může odkazovat na stejný koncept jako systém, na soubor interně definovaných systémů nebo dokonce na skupinu různých zdravotnických prostředků.

Ušetříte si spoustu zmatků a přepracovávání, pokud si interně definujete, co vaše organizace rozumí pod pojmem „řešení“.

SOUP/OTS v životním cyklu softwaru

• SOUP je zkratka pro Software of Unknown Provenance (software neznámého původu)
• OTS je zkratka pro Off-the-Shelf Software (hotový software)

Na internetu se vedou četné diskuse o tom, zda jsou SOUP a OTS stejné nebo odlišné. Zjednodušeně řečeno, ne, v praxi pro vás prakticky není žádný rozdíl.

Oba pojmy se vztahují na softwarové komponenty, které:

1. nebyly původně vyvinuty jako součást zdravotnického prostředku a
2. nemají kompletní technickou dokumentaci

Jediný nepatrný rozdíl spočívá v tom, že SOUP by teoreticky mohl být software, který byl dříve vyvinut vaší vlastní organizací, zatímco OTS obvykle pochází z externího zdroje.

Ve skutečnosti však v 99,9 % případů SOUP nebo OTS odkazují na externí software integrovaný do vašeho produktu, nikoli na něco, co váš tým vyvinul dříve. Tento rozdíl má velmi malý praktický dopad na to, jak SOUP/OTS spravujete, snad s výjimkou kyberbezpečnosti, kde může být interně vyvinutý (i nedokumentovaný) software považován za bezpečnější než náhodná knihovna stažená z internetu.

Příklady SOUP/OTS zahrnují:

• Externí knihovny používané ve vašem softwaru

• Operační systémy

• Databázové systémy

• Cloudová řešení

• Frameworky pro vývoj backendu nebo frontendu

Stručně řečeno, SOUP a OTS jsou softwarové komponenty, nazývané v normě IEC 62304 „softwarové položky“, které pocházejí z vnějšku vaší organizace.

Proč je důležité identifikovat SOUP/OTS?

SOUP/OTS představuje externí software, na kterém závisí bezpečnost, účinnost a zabezpečení vašeho produktu. Proto je nezbytné tyto komponenty identifikovat a vyhodnotit s nimi spojená rizika.

Měli byste si položit otázky jako:

• Mohu tomuto softwaru důvěřovat?

• Jak mohu minimalizovat potenciální rizika s ním spojená?

• Co by se stalo, kdyby SOUP/OTS přestal fungovat?

• Je plně kompatibilní s naším softwarovým systémem?

• Mohl by obsahovat bezpečnostní zranitelnosti nebo dokonce úmyslné zadní vrátka?

Sledovatelnost a norma IEC 62304

Termín sledovatelnost je v normě definován poněkud krypticky a jeho interpretace a praktické použití nejsou vždy jasné. Norma IEC 62304 jej definuje jako „míru, do jaké lze mezi dvěma nebo více produkty vývojového procesu navázat vztah.“

Zde se „výrobky“ nevztahují na samotné zdravotnické zařízení, ale spíše na jakýkoli výstup, jakýkoli výsledek vytvořený během vašich vývojových činností. To zahrnuje Design Controls, jako jsou požadavky, architektura, opatření pro řízení rizik a další související dokumenty.

V praxi to znamená, že byste měli mít logický systém, který propojuje vaše dokumenty a informace v nich obsažené a zajišťuje, že vše zůstává konzistentní a bez rozporů.

Jednou z běžných forem sledovatelnosti používaných ve většině organizací je propojení mezi požadavky, opatřeními pro řízení rizik, návrhem a ověřením. Zjednodušeně to může vypadat asi takto:

Obrázek 4: Design Controls Traceability

Definice sledovatelnosti však také zmiňuje, že zahrnuje architekturu. To nás vrací k předchozím kapitolám, kde jsme diskutovali o tom, co architektura vlastně znamená, a toto pochopení pomáhá objasnit, jak se sledovatelnost uplatňuje v rámci samotné architektury.

Jak jsme již řekli, architektura je více než jen grafický diagram; je to komplexní dokument, který obsahuje popisy a může také obsahovat odkazy (sledovatelnost) na konkrétní požadavky.

Proč je sledovatelnost užitečná?

Jasné propojení mezi požadavky a architekturou pomáhá zajistit, že všechny konkrétní potřeby, jako jsou ty související s interoperabilitou nebo bezpečností, jsou v architektonickém návrhu správně zohledněny.

Podívejme se na příklad. Předpokládejme, že existuje požadavek na šifrovanou výměnu dat přes Bluetooth mezi periferním zařízením IoT a mobilní aplikací.

Tento požadavek by měl být viditelný v rámci softwarové architektury:

• Architektura by měla odrážet periferní zařízení IoT.

• Měla by být znázorněna výměna dat mezi periferním zařízením IoT a mobilní aplikací.

• Požadavek na šifrování by měl být v architektuře zmíněn.

• Mělo by být popsáno implementované řešení, včetně podrobností o párování a chování šifrování.

Díky tomuto druhu sledovatelného uspořádání budete schopni předložit úplný, transparentní a sledovatelný obraz, pokud se váš manažer, externí auditor nebo vyšetřovatel FDA zeptá, jakým způsobem dochází k výměně dat mezi periferním zařízením a mobilním zařízením.

Životní cyklus produktu

Ačkoli samotná norma obsahuje v názvu životní cyklus, k tomuto pojmu se dostáváme až nyní.

Zatímco norma IEC 62304 poskytuje jasnou definici modelu životního cyklu vývoje softwaru, je stejně důležité pochopit širší pojem životního cyklu produktu.

Mnoho společností má tendenci spojovat životní cyklus produktu hlavně s činnostmi v oblasti návrhu a vývoje.

Ve skutečnosti však životní cyklus produktu zahrnuje celou dobu životnosti zdravotnického produktu, od jeho počátečního konceptu až po konec jeho životnosti. Tato širší perspektiva je obzvláště důležitá pro software, kde udržovatelnost hraje ústřední a trvalou roli.

Proč je životní cyklus produktu důležitý?

Prostředí kolem softwaru pro zdravotnické prostředky se neustále mění. Operační systémy se vyvíjejí, cloudová infrastruktura se aktualizuje, v knihovnách se objevují nové bezpečnostní chyby a softwarové komponenty, na kterých váš produkt závisí, se mohou časem

stát nekompatibilními. Všechny tyto faktory je třeba sledovat a řídit i po uvedení vašeho produktu na trh.

Kromě toho data, se kterými váš software pracuje, podléhají po celou dobu používání regulačním požadavkům a požadavkům na ochranu soukromí. Během fáze vyřazování nebo konce životnosti je nezbytné mít definované procesy, které zajistí, že po ukončení výroby produktu nezůstanou žádné citlivé lékařské údaje přístupné nebo nesprávně uložené.

Zeptejte se sami sebe:

• Co se stane, když uživatel přestane používat vaši aplikaci?

• Zaznamenáte tuto událost a máte postupy pro identifikaci a smazání dat tohoto uživatele?

• Můžete potvrdit, že všechna zákaznická data, která se již nepoužívají, byla bezpečně odstraněna?

• Existují nějaké známé nové bezpečnostní chyby v softwarových komponentách, které používám?

• Je můj produkt kompatibilní se všemi aktuálními verzemi operačních systémů?

• Existují v aplikaci nebo produktu nějaké problémy, které nebyly odhaleny během testování, ale objevují se v produkčním prostředí?

Tyto otázky zdůrazňují, proč životní cyklus produktu přesahuje rámec návrhu a vývoje.

V dnešní digitální éře jsou takové aspekty životního cyklu stále častěji prověřovány auditory a regulačními orgány, včetně FDA.