Szoftverfejlesztő csapat az orvostechnikai eszközödhöz

Összekapcsolt szenzor, betegalkalmazás és orvosi dashboard

Egy digitális egészségügyi vállalat orvostechnikai eszközként fejleszt távmonitorozó rendszert. A rendszer szenzorból, betegeknek szánt mobilalkalmazásból és klinikai szakembereknek készült webes dashboardból áll. A besorolás a rendeltetéstől függ (attól, hogy a gyártó mire szánja a szoftvert). Az EU MDR VIII. mellékletének 10. és 11. szabálya szerint például IIa vagy IIb osztályba tartozhat. Az FDA szerint pedig II. osztályú eszköz lehet.

Közös fejlesztési terv alapján készítjük a firmware-t, az alkalmazást, a felhőalapú backendet és a dashboardot. A szoftverrendszer szoftverbiztonsági osztályát (A, B vagy C, a szoftverhiba okozta lehetséges ártalom alapján) azok a veszélyek határozzák meg, amelyekhez a szoftver hibája hozzájárulhat. Az architektúrában elkülönített szoftverelemek alacsonyabb osztályba tartozhatnak, ha az elkülönítést verifikáltuk, és ennek indokait dokumentáltuk. A Bluetooth-kapcsolatot, az adatáramlást és a felhőszolgáltatás rendszerhatárát egyetlen threat modelben (az eszköz elleni lehetséges támadások módszeres elemzése) vizsgáljuk. A használhatóság vizsgálatakor a betegek és a klinikai szakemberek szempontjait is figyelembe vesszük.

Már az első sprintben megkezdjük a verifikációt. A műszaki dokumentációt és az FDA-beadványt így a fejlesztés során folyamatosan elkészülő dokumentumok alapján állítjuk össze.

Már használt termék dokumentálása és további fejlesztése

Egy alkalmazás, egy felhőalapú backend és egy dashboard már használatban van, de eddig nem tartoztak az MDR hatálya alá. Most orvostechnikai eszközzé kell válniuk. Az MDR szerinti további fejlesztés előtt el kell készíteni a hozzájuk tartozó szoftverdokumentációt.

Először tisztázzuk az eszköz rendeltetését, azt, hogy orvostechnikai eszköznek minősül-e, és megállapítjuk a besorolását. Ezután gap analysis (a szabvány követelményeihez képest fennálló hiányosságok vizsgálata) során dokumentáljuk a termék jelenlegi állapotát. A korábban el nem készített dokumentumokat nem dátumozzuk vissza. A hiányokat új kockázatelemzéssel és verifikációval pótoljuk. Az új fejlesztéseket az életciklus követelményei szerint végezzük, így minden új funkcióhoz követelmények, kockázatértékelés és tesztek tartoznak.

Startup működő prototípussal és lezárt finanszírozási körrel

Egy MedTech startup már működő prototípussal rendelkezik, amelyet külső fejlesztő vagy az egyik alapító készített. Most olyan szoftverre van szüksége, amely megfelel az első EU MDR szerinti eljárás vagy az FDA-beadvány követelményeinek.

A prototípus forráskódján gap analysist végzünk. Minden szoftverelemről eldöntjük, hogy megtartjuk, refaktoráljuk vagy újraírjuk. Elkészítjük a fejlesztési tervet, meghatározzuk a szoftverbiztonsági osztályokat, és elvégezzük a kockázatelemzést. Ezután folytatjuk a fejlesztést, és elkészítjük a beadványhoz szükséges dokumentációt.

Firmware-rel és orvosi alkalmazással működő műszer

Egy IIb osztályú műszer hardverét firmware vezérli, az orvos pedig PC-s alkalmazást használ. Mindkét szoftverkomponenst ugyanazon orvostechnikai eszköz részeként kell fejleszteni és dokumentálni.

A firmware-t és az alkalmazást közös architektúra fogja össze. A rendszer szoftverbiztonsági osztályát a veszélyek határozzák meg. A firmware vagy az alkalmazás csak akkor kaphat alacsonyabb osztályt, ha az elkülönítés ezt indokolja. Meghatározzuk a köztük lévő interfész követelményeit, az interfészt azonosított szoftverelemekben implementáljuk, majd integrációs tesztekkel verifikáljuk. Mindkét rész verifikációját egyetlen nyomon követhetőségi mátrixban (az egyes követelményeket a tervezési elemekhez, tesztekhez és kockázatcsökkentő intézkedésekhez kapcsoló táblázat) dokumentáljuk. A két részt közös release-ben adjuk ki.