Aktív Orvostechnikai Eszközökben használható modern fejlesztési technológiák lehetőségeinek vizsgálata

Átírás

1 Aktív Orvostechnikai Eszközökben használható modern fejlesztési technológiák lehetőségeinek vizsgálata Kutatói beszámoló Kazinczi Ferenc (B. Braun Medical Hungary Ltd.) Dátum:

2 1 Tartalom jegyzék 1 Tartalom jegyzék Bevezetés Dialízis gépek bemutatása Akut és krónikus veseelégtelenség Dialízis terápiák Aktív egészségügyi gépek fejlesztése Szabványok és Guideline-ok ISO Kockázatmenedzsment Usability engineering Egészségügyi gépekben alkalmazott software fejlesztése IEC Medical electrical equipment - Part 1: General requirements for basic safety and essential performance Design History file (DHF) Product Requirement Profile Design and Development Plan Design Input Design Output Design Review Design Verification Design Validation Design Transfer DHF kialakítása Követelmény és Design specifikáció menedzsment Rendszer követelmények specifikációk Software követelmények specifikációk PCB és HW követelmény specifikációk Traceabilty Mátrix Követelmények Menedzselése Fejlesztési folyamat menedzsment Agilis metódusok a SW fejlesztésben A megvalósított SW fejlesztési folyamat

3 2 Bevezetés A kutatást a B. Braun Medical Kft.-nél végeztem, ami több komplex feladat elvégzését foglalt magába egy akut dialízis gép fejlesztésével kapcsolatban. Főbb feladatim közé tartozik az aktív egészségügyi gépek (Active Medical Device) fejlesztési folyamatai során felmerülő nemzetközi minőségügyi, szabályozási, biztonság technikai és a felhasználók által elvárt követelmények meghatározása és a folyamatoknak a javítása. A szabványokban leírt követelmények betartása, pontos dokumentációja nélkülözhetetlen a termék piaci bevezetésekor. A célországok jogrendszerének megfelelően be kell tudni bizonyítani, hogy a gyártó mindent megtett annak érdekében, hogy egy biztonságos és funkcionálisan jól működő gépet kíván forgalmazni, ami nem veszélyezteteti sem a betegeket, sem pedig a felhasználókat. Mindemellett a folyamatok betartása és alkalmazása nem csak csökkenti a fejlesztés költségeit, de növeli a fejlesztés hatékonyságát, minimalizálja az orvostechnikai eszközök által hordozott kockázatot és segíti a mérnököket az egyes életciklus fázisokban helyes döntéseket hozni. Az egészségügyi gépek minőségmenedzsmentjére vonatkozó specifikus követelményeket az ISO 13485:2003 szabványban összegezték. Annak érdekében, hogy akár már kis fejlesztői csapattól egészen a multinacionális cégekig, a szabályozási rendszerek által megkövetelt eredményeket be tudjuk mutatni, nélkülözhetetlen a folyamatok menedzselését és a dokumentációt támogató rendszerek alkalmazása. Ilyen rendszerek irányíthatják a: - Feladatok munkafolyamatát (IBM Lotus Notes alapú életciklus management) - Rendszer és komponens szintu követelmények menedzselését és traceability biztosítását (IBM Rational DOORS) - Konfiguráció és karbantartási menedzsmentet (Reporting rendszerek, Dokumentációs Adatbázis, SVN) - Tesztelési, Verifikációs és Validációs folyamatokat A kutatás fő témakörei: - Az orvostechnikai eszközök élet ciklusát menedzselő rendszerek kialakítása új eszközök, módszerek és technikák alkalmazásával. - Az adott projekttel kapcsolatos ISO által elvárt Design History File (DHF), valamint az amerikai Food and Drug Administration (FDA) CFR 21 Part 820 követelményei alapján agilis folyamatok kialakítása. (TDD, MediSPICE, SCRUM) Szükségszerű a folyamataink optimalizálása és hatékonyságának növelése, így továbbá feladatim közé tartozik még, olyan folyamatok megalkotása, melyek elvégzése nem hátráltatja a fejlesztőket. Ezt olyan, a fejlesztés során bevezetett Agilis módszerek alkalmazásával tesszük, mint például a SCRUM. Ezzel és a hasonló iteratív elveken alapuló módszerekkel időt, pénzt és energiát lehet megtakarítani, valamit növelhető mind az elektronikus, mechanikus és a software fejlesztések hatékonysága. 3

4 3 Dialízis gépek bemutatása 3.1 Akut és krónikus veseelégtelenség A vese funkcionalitásában fellépő különböző rendellenességek alapján megkülönböztethetünk akut és krónikus elégtelenséget. Ezek kezelései: Akut dialízis: a vesét ért hirtelen trauma, általában valamilyen visszafordítható patológia hatás áll a háttérben, ami akár több szervi elégtelenséggel is egyszerre jelentkezhet. Ilyen kiváltó okok lehetnek: o egy baleset, ami során a betegnek a veséje súlyos sérülést szenvedett a becsapódástól. o olyan betegek esetében, akiknek a szervezete túlságosan legyengül műtét közben és a vesét le szeretnék kapcsolni a vérkörről. (Transzplantációs műtétek, szív- és érrendszeri beavatkozások.) o urogenitális daganat következtében elzáródó húgyhólyag és húgyutak. o (Ezeket az okokat megkülönböztethetjük a vesét és környezetét ért hatásoknak megfelelően Prerenális/Renális/Postrenális eredetűeknek. ) Éppen ezért az ilyen jellegű gépek főleg az intenzív osztályokon fordulnak, ahol folyamatos akár több napig tartó kezelésekről lehet szó, amit a vese teljes funkcionalitásának visszanyerése követhet. Ennek érdekében a nővéreknek, orvosoknak egy könnyen kezelhető és kis gépre van szükségük, hogy a többi intenzíves eszközök közötti munka ne legyen még nehezebb. Krónikus dialízis: Krónikus veseelégtelenségről akkor beszélünk, ha fokozatos és visszafordíthatatlan romlás áll fent a betegnél. Ilyenkor a páciensnek rendszeres dialízis kezelésre van szüksége, hogy a vese kiválasztásának feladatit a gép el tudja végezni és ezzel megakadályozzuk a további állapot romlást. Ilyen krónikus gépeket az erre a feladatra kialakított dialízis centrumokban használnak, ahol a betegek állapottól függően hetente 2-3 kezelésen vesznek részt, melyek akár 4 órát is igénybe vehetnek. Ezek a központok saját vízmű - vel vannak ellátva, annak érdekében, hogy növeljék a terápia hatékonyságát. Ennek köszönhetően a krónikus gépeknek, az akut gépekkel szemben, nagyobb a helyigényük és rendszerint bonyolultabb a működésük és a felhasználói felületük is. Krónikus dialízis sajnos nemtől és kortól teljesen függetlenül is kialakulhatnak, de a leg főbb kiváltó okok lehetnek: o egészségtelen életvitel dohányzás, alkoholizmus túlsúlyosság. o a diabetes bármilyen típusú lefolyása o magas vérnyomás, szív- és érrendszeri megbetegedések o genetikailag örökletes és autoimmun betegségek (cystás vese elváltozások, IgA nephropathy (véres vizelet)) 4

5 3.2 Dialízis terápiák Míg a vesében bonyolult kémia folyamatok irányítják a kiválasztást, addig a valóságban egyszerű fizikai modellek helyettesítik a vese főbb funkcióit. Az egyszerűbb kezelések esetében egy féligáteresztő membránra (Haemofilter: Egy szemipermeábilis membrán, amelynek a kapillárisaiban a beteg vére folyik keresztül és a különböző eljárások következtében a hártyán konvekcióval, vagy diffúzióval (ozmósis hatására) molekulák áramlanak a vérből, a membrán egyik oldaláról a másikra.), a beteg vérére, ami egy külső szerelékben pumpák által szabályozottan folyik és dializáló oldatokra van szükség: Hemodialízis (HD): Ennél a terápiánál a beteg vérét egy perisztaltikus pumpa segítségével átvezetjük egy haemofilter kapillárisain, valamint egy dialízis pumpa segítségével a kapillárisokat kívülről dializáló oldatba helyezzük. Ekkor a féligáteresztő hártya két oldala között fellépő koncentráció különbség hatására a vérben oldott toxinok átáramlanak a szűrön keresztül a dialízis folyadékba. A kiválasztott ultrafiltrátum-ot, ezek után elvezetik. Hemofiltráció (HF): Hemofiltráció esetében csak a kapillárisokon belül folyik vér és folyadék. Ilyenkor a haemofilter előtt vagy után közvetlenül a vérhez adják hozzá az úgy nevezett helyettesítő folyadékot. Ennek köszönhetően a beteg vérét először felhígítjuk, majd a rendszerben lévő nyomás következtében a membrán lyukain átpréseljük a különböző molekulákat. Főleg nagyobb méretű molekulák eltávolításban segít. (Akut dialízis esetében, előfordulhat csak tiszta folyadék eltávolítás a betegből, ahol csak a páciens vérét áramoltatják át a filteren és folyadékot vesznek le. Ez főként ödémás betegek esetében alkalmazott.) Hemodiafiltráció (HDF): Ez a terápiás eljárás a hemofiltráció és a hemodialízis kombinációja. Ebben az esetben urémiás toxinok membránon keresztüli kiválasztása a vérből nem csak ozmózissal(koncentráció különbség) történik, hanem konvekcióval (két oldal közti nyomás különbséggel). Plazma terápiák: A plazma terápiák akut dialízis kezelések és egyéb szeptikus esetek kapcsán merülnek fel. Ilyen esetekben először elválasztják a vérplazmát a vér alakos elemeitől, majd vagy lecserélik, vagy egy második filteren vagy adsorberen keresztül a megtisztítják. o Plazma csere : Amikor az elválasztott plazmát eltávolítják és új plazmával helyettesítik. o Plazma adszorpció/perfúzió : Az elválasztott plazma egy szelektív adszorberen keresztül folyik át és az így az adott szelektivitásnak megfelelő molekulától megtisztított plazmát juttatják vissza e beteg váráramlásába. (Léteznek a Hemoperfúziós terápiák is, amikor a vért közvetlenül egy szelektív szűrőn keresztül tisztítják és juttatják vissza a betegbe. ) 5

6 4 Aktív egészségügyi gépek fejlesztése 4.1 Szabványok és Guideline-ok Az orvostechnikai eszközök fejlesztése egy meglehetősen erősen szabályozott iparág, ahol a versenyben maradás egyik alappillére, hogy ezeknek a nemzetközi szabványoknak, leírásoknak megfeleljen az adott gyártó. Ezek a szabályozások még szigorúbbak, olyan eszközök esteében, ahol az elvárt teljesítményért és a funkcionális biztonságért egy-egy beágyazott rendszer a felelős. A dialízis gépek is ebbe a kategóriába sorolhatóak, ahol a rendszer biztonságos működését egy vagy több software applikáció együttese biztosítja. Ilyenkor az általános minőségmenedzsment szabványok mellet, további folyamat leíró szabványok vagy akár termék specifikus szabványok is megjelenhetnek, mint ez a művese gépek esetében is történt. (IEC th edition - Particular requirements for basic safety and essential performance of haemodialysis, haemodiafiltration and haemofiltration equipment). A lentebbi táblázat egy listát tartalmaz a legfontosabb aktív egészségügyi gépek gyártásával kapcsolatos szabványok és guideline-okról. A gyártók minden évben rendszeresen úgy nevezett auditon vesznek részt, amit egy független minősítő szervezet végez és sikeres megfelelőség esetén a gyártó jogosultságot szerez, hogy forgalmazza a terméket az adott országban vagy. International Standards ISO 9001:2000, Chapter 7.3. Design and development, Chapter 8.3 Control of nonconforming product ISO/IEC 90003:2004 Software engineering Guidelines for application of ISO 9001:2000 to computer software ISO 13485:2003, Chapter 7.3. Design and development, Chapter 8.3 Control of nonconforming product ISO 14971:2007 Application of risk management to medical devices IEC :2005 Medical electrical equipment - Part 1: General requirements for basic safety and essential performance IEC :2006 Medical electrical equipment - Part 1-6: General requirements for basic safety and essential performance Collateral Standard: Usability IEC Medical Device Software Software life cycle processes IEC 62366:2007 Medical Devices Application of usability engineering to medical devices Guidance, national standards EC-Directive 93/42/EEC for Medical Devices and derived National Laws FDA 21 CFR 820 Quality System Regulations FDA Design Control Guidance for Medical Device Manufacturers, March 1997 FDA Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, May 2005 FDA General Principles of Software Validation, Final Guidance for Industry and FDA Staff, 2002 FDA Guidance Do it By Design (An Introduction to Human Factors in Medical Devices) FDA Guidance - Medical Device Use-Safety: Incorporating Human Factors Engineering into Risk Management - 18,July,2000 JUS Canadian Medical Devices Regulations (SOR/DORS) IEEE Std IEEE Standard for Software Reviews ANSI/AAMI HE74:2001 Human factors design process for medical devices IEC/PAS Guidance on human factors ANSI/AAMI HE75:2010 Human factors engineering engineering for system life cycle applications Design of medical devices Table 1. General International and National standards in the Medical device domain 6

7 4.1.1 ISO Ez a szabvány a Nemzetközi Szabványosítási Szervezet (ISO International Organization for Standardization) által elkészített egészségügyi gépekre vonatkozó minőségmenedzsment szabvány (ISO 13485:2003), ami az iparban alkalmazott ISO 9001:2008 minőségmenedzsment szabvány orvostechnikai eszközökre specializálódott módosítása és kiegészítése. A szabvány legfőbb célja, hogy olyan útmutatást biztosítson a gyártóknak, amely harmonizálja és egységesíti ezt az ipari szektort lehetővé téve egy jól kontrollált és felügyelhető termék életciklus megvalósításáti. Nem csak a vevők által felállított követelményeknek és a különböző országok jogszabályainak való megfelelés a cél, de az egészségügyi cégek termelékenységének fokozása és az egyre növekvő termékminőség elérése is meghatározó. Egységes Design History File kialakítása, ami a termék teljes életciklusát bemutató dokumentációs struktúra, egészen a kezdeti tervezési fázistól, a fejlesztésen keresztül, a piacra bocsátáson át a termék visszavonásáig. Ez a fajta egységesítés lehetővé teszi az egyes piacokon képviseltetett versenytársak egyenlő osztályozását és elbírálását. Külön hangsúlyt fektetnek a használhatóságra (Usability Engineering), ez magába foglalja a gép minden élethelyzetben történő felhasználási lehetőségeinek és az egyes felhasználói körök által elvárt követelmények megvizsgálást. Mindezek mellett az egyik legfontosabb szempont a kockázatmenedzsment (Risk Management) harmonizálása, ennek betartása nélkülözhetetlen egy biztonságosan működő termék fejlesztése és gyártása során Kockázatmenedzsment Az elmúlt évtizedek során az egészségügyi gépek fejlesztése során egyre nagyobb teret hódított a kockázatmenedzsment, aminek az iparágban alkalmazott és elvárt folyamatát az ISO 14971:2009 szabvány mutatja be. Természetesen a szabvány lehetőséget biztosít, mindenkinek, hogy a saját folyamataikhoz alakítsák és azok alapján alkalmazzák ezt, de a kimenetet miden esetben szigorú vizsgálatoknak vetik alá, melyeknek lényege a felelősségvállalás. A felhasználó és beteg központú gondolkodás alapja, hogy a rizikó analízis során a fejlesztői csoportok már magas szinten megvizsgálják, hogy a gép, milyen veszélyeket rejthet, attól függően, hogy a hazárdos eset felhasználói hibából, hardware hibából vagy esetleg valamilyen software hibából ered. A fő célja ennek a folyamatnak, olyan védelmek és biztonsági intézkedések kialakítása, melyek képesek az azonosított veszélyes helyzeteket megszűntetni vagy segítenek elkerülni azt. Ilyen megoldások lehetnek: Inherent safety by design: Olyan hardware elemek gyártása, tervezése melyek kizárják egy funkció nem megfelelő alkalmazását. (Mechanikus alkatrészek vagy akár már PCB design szinten bevezetett védelmi áramkörök.) Protective Measures: Főként olyan funkcionális biztonsági intézkedések, ahol valamilyen software által biztosított védelemről van szó. Ilyenkor a rendszer egy veszélyes helyzetben egy előre definiált biztonsági állapotba kerül és ezt figyelmeztető jelekkel jelzi a felhasználónak. (SW alrendszerek, amik bizonyos szenzorok monitorozásával biztosítják a normális működési körülményeket és azok eltérésekor jelzést adnak és beavatkoznak.) Information for safety: Sok esetben fordulhat elő olyan, hogy a veszély megakadályozása nem megvalósítható az előző két eljárás egyikével sem. Ilyenkor a leggyengébb???? védelem, ha megfelelő jelzésekkel, leírásokkal vagy a felhasználók oktatásával próbáljuk meg a rizikót csökkenteni. (Különböző címkék vagy a felhasználó útmutató stb ) 7

8 4.1.3 Usability engineering Egyre szélesebb körben elterjedt módszer, hogy az egészségügyi gépek használatát a lehető legnagyobb mértékben felhasználóbarátra kell tervezni. Ez nem csak a megjelenést rejti magában, ami,mint marketing fogás alkalmazható, hanem segíthet a különböző felhasználói csoportok szokásiból, kultúrából vagy képzettségéből eredő kockázati tényezők csökkentésére, ezáltal növelve a gép biztonságosabb működését. Ezzel az IEC 62366: Medical Device Usability Engineering szabvány foglalkozik, ami szintén egy folyamatot leíró szabvány és az egyes fejlesztési lépések során keletkező kimeneteket definiálja Egészségügyi gépekben alkalmazott software fejlesztése Ahogy már korábban kitértem rá, az orvostechnikai eszközök funkcionalitása és alkalmazhatósága a gép által megvalósított software-től függ a legnagyobb mértékben. Egy SW működésében sohasem lehetünk 100%-osan biztosak, abban hogy minden esetben jól és biztonságosan fog működni. Mégis annak érdekében, hogy egy a SW-t tartalmazó eszközök biztonságos működését elérjük, a Nemzetközi Elektronikai Bizottság hatályba helyezte az IEC 62304: Medical Device Software Software life cycle processes szabványt. Ez a szabvány kiterjeszti a fentebb ismertetett kockázatmenedzsment-et és lemegy egészen a legkisebb SW egységekig, hogy a lehető legalaposabb tervezést, implementálást, tesztelést és verifikációt biztosítsa. Ezáltal garantálja, hogy a gyártó a lehető legjobb tudása szerint járt el és minimalizálta a SW-ből származó hibák valószínűségét. Figure 1. IEC SW fejlesztési folyamat. 8

9 4.1.5 IEC Medical electrical equipment - Part 1: General requirements for basic safety and essential performance Érdemesnek tartom, hogy a legfőbb biztonság technikai szabványt is megemlítsem, ami az orvostechnikai eszközök területén található, ez az alcímben is megnevezett IEC rd edition. Ez a szabvány foglalja magába az összes olyan általános biztonság technikai követelményt és alapvető teljesítmény követelményeket, amik nélkülözhetetlenek az egészségügyi gépek piacán. Ez a szabvány az előzőekben bemutatottakkal szemben nem folyamatokat definiál, hanem konkrét követelményeket fogalmaz meg, amiket minden gyártónak követnie kell és a dokumentáltan bizonyítaniuk kell a követelményekkel szembeni megfelelősséget. Ezek a követelmények direkt hatással vannak a termékek tervezésére és fejlesztésére. További 10 úgy nevezett Colleteral szabványt definiál, amik külön foglalkoznak az Alarm jelzésekkel (IEC ) vagy az Elektromágneses Kompatibilitással (IEC ). Valamint 60 darab termék és piaci szegmens specifikus partikuláris szabványt, mint a bevezetőben említett dialízis gépekkel foglalkozó szabvány, a IEC Ez a szabvány család nélkülözhetetlen követelményeket fogalmaz meg, segítve a biztonságosabb és jobb minőségű gépek fejlesztését egy egységes rendszer keretein belül. 4.2 Design History file (DHF) A minőségmenedzsment legfőbb végterméke a Design History File, aminek egy jelentős részét, az adott termékkel kapcsolatos fejlesztési és egyéb folyamatok végeredményeként keletkező dokumentációk alkotják. A termék fejlesztési életciklusát a gyakorlatban legtöbbször az úgy nevezett V-modellel szokták ábrázolni és megvalósítani, ami egyben megfelelően illeszkedik az ISO által elvárt folyamat orientált megközelítéshez is. Figure 2. V-modell 9

10 4.2.1 Product Requirement Profile Az elsődleges hivatalos dokumentum egy termékkel kapcsolatban a magas szintű követelmények megfogalmazása, ami nagyobb cégek esetében a különböző divíziók elvárásait, a termékre jellemző felhasználói követelmények és egyéb általános a piac és a versenyképesség által megkövetelt specifikációkat foglalja össze. Ez egységesíti a cégen belül e termékkel kapcsolatos egységes elvárást, ami köré a későbbiekben a marketing, a salse és a fejlesztés is építhet Design and Development Plan Minden fejlesztési projectben nélkülözhetetlen, hogy tervet készítsünk az egyes fázisokhoz. Ennek keretében meg kell tervezni a termékfejlesztés szakaszait, mérföldköveit. Fontos meghatározni az átvizsgálási pontokat, ahol ellenőrizzük az egyes feladatok elkészültségét és a megvalósított design technikai átvizsgálását. Előírjuk, hogy milyen verifikálási tevékenységeket tervezünk és milyen mélységben tervezzük ezeket elvégezni, valamint a validálási és tervezésátadási tevékenységeket. A project elején a project vezetőknek meg kell határozniuk a felelősségi és hatásköröket. Lényeges követelmény, hogy ezt a fejlesztés folyamán karban kell tartani (pl. az átvizsgálások eredményeként szükségessé váló változtatások következményeként vagy a több éves fejlesztési ciklusból adódó erőforrás és technológiai igényeknek megfelelően) Design Input Ez az első lépcsőfok, hogy a termékkel kapcsolatos legfontosabb követelményeket megfogalmazzuk. Kiemelt jelentőségű, hogy a funkcionális és a teljesítmény követelmények mellett, az egyes jogszabályokból adódó elvárásokat is meghatározzuk már ilyen magas szinten és az implementációs eljáráshoz, mint bemenet rendelkezésre bocsássuk. Fontos, hogy az egyéb követelményeken túl kiemelten figyelembe kell venni a biztonsági követelményeket és a kockázatmenedzsment eljárás kimeneti adatait is. Az orvostechnikai eszközök területén az elmúlt években magas súllyal szerepelnek a követelmények között a felhasználói csoportok elvárásai és az esetleges felhasználók által elkövethető hibák elleni védelmek meghatározásai is. Tehát ezek a követelmény specifikációk foglalják össze, hogy MIT várunk el pontosan a végterméktől. A bemenő adatok kielégítő voltát jóvá kell hagyni és a fejlesztés folyamán át kell vizsgálni Design Output Ebben a fázisban születnek meg a magas szintű megvalósításhoz szükséges leírások. Meghatározásra kerülnek, milyen komponenseknek kell alkotniuk egy gépet ezek hogy fognak rendszert alkotni. Milyen SW egységek fogják az egyes funkcionalitásokat biztosítani és azok hogyan kapcsolódnak egymáshoz és a rendszerhez. A kimenő adatoknak ki kell elégíteniük a követelményeket (bemenő adatok) és megfelelő információt kell nyújtaniuk a beszerzéshez, gyártáshoz ill. szolgáltatásnyújtáshoz. Egyszerűen fogalmazva olyan leírások, modellek és egyéb segédeszközök gyűjteményei, amely pontosan megválaszolják, hogy a követelményeket HOGYAN szeretnénk megvalósítani Design Review Egy átlagos egészségügyi gép fejlesztés ciklusa akár 3-5 év is lehet, ami szinte kötelezően magával vonzza, hogy a konzisztencia érdekében a fejlesztési tervben meghatározott pontokon át kell vizsgálni az addigi eredményeket. Megfelelnek-e a követelményeknek, mindent kielégítünk a specifikációs oldalról és nincsenek le nem fedett elvárások. Illetve a feltárt problémák megoldására javaslatokat kell tenni, amelyeket a 10

11 megfelelő folyamatokkal alátámasztva, mint a Change Request Management vagy a Maintenance and Problem Resolution folyamatok Design Verification A verifikálás feladata annak igazolása, hogy a fejlesztés kimenő adatai teljesítik a tervezés és fejlesztés bemenő adatait, azaz a termék követelményeit. A szembe állított verifikációs teszteknek le kell fedniük a követelményeket, ezáltal igazolva, hogy a végtermék a teljesíti a kezdeti követelményeket ezáltal biztosítva az implementáció helyességét Design Validation A validálási tevékenység célja annak igazolása, hogy a termék kielégíti a használati és alkalmazási célokat, azaz megfelel a tényleges felhasználói igényeknek. Ennek részeként klinikai értékelést kell végezni. Fontos kihangsúlyozni, hogy ezt a tevékenységet a végleges körülmények között és valódi felhasználók által a gyártott terméken kell elvégezni a forgalomba helyezés előtt Design Transfer Az utolsó fejlesztési fázis, amikor a termék kész a gyártásra és átadásra kerül, hogy az adott piacra vezessék. A Fejlesztés miden szükséges dokumentációval és folyamattal, ami az egészségügyi gép sorozatgyártásához elvárt befejezésre? kerül DHF kialakítása Az ISO követelményeinek megfelelően az előbbiekben felsorolt fő fejlesztési fázisok kimenetelei fogják alkotni a Design History File -t, ami az Auditokon használt dokumentumok jelentős részét képviselik. Ezeknek a tartalmaknak a megfelelő kialakítása és folyamatos karbantartása nélkülözhetetlen a termék piaci versenyképességéhez. 11

12 5 Követelmény és Design specifikáció menedzsment 5.1 Rendszer követelmények specifikációk A projekt indulását követően a megismert folyamat alapján először szükséges, hogy a magas szintű marketingtől, piackutatásból származó adatokat egy jól strukturált, már technikai és biztonsági adatokkal kiegészített rendszer szintű követelmény halmazba rendezzük. Ezeket Rendszer Követelményeknek nevezik, ez a specifikáció adja az első igazi bemenetet a fejlesztőknek, akik ezek alapján meg tudják határozni, milyen komponensek alkossák a gépet, hogyan nézzen ki, az egyes elemek hogyan kapcsolódjanak egymáshoz. 5.2 Software követelmények specifikációk A SW követelmények már a fejlesztés egy későbbi fázisában válnak fontossá, ahol a SW mérnököknek egy, a Rendszer szintű követelmények alapján készített specifikáció fogja képezni az implementáláshoz szükséges inputot. Fontos, hogy a követelmények egyértelműek, jól érthetőek legyenek. Pontosan megfogalmazzák a funkciókkal szembeni elvárásokat, beállítható tartományokat, default értékeket, alarm limiteket. Definiálják a hardware-software interfészeket, bizonyos vezérlések esetében a kommunikáció paramétereit (RS232, RS422 ) vagy esetleg analóg jeleknél az egyes logikai szinteket. Ezek a követelmények egy fajta cheklist-et alkotnak az implementációs folyamat végén, melyek a verifikációs eljárás során, a teljesség és helyesség bizonyításához használhatók. Fontos megjegyezni, hogy a SW követelmények változnak a leggyakrabban egy fejlesztés során, mivel ez a legkiszámíthatatlanabb komponens és szinte 100%-osan biztos, hogy mindig javítani, módosítani kell és állandó support-ot kell biztosítani a termék életciklusának végéig. 5.3 PCB és HW követelmény specifikációk Mivel egy orvostechnikai eszköznek csak egy részét képezi a SW követelmények előállítása, külön folyamatok és eljárások léteznek, a mechanikus és elektronikus alkatrészek specifikálásához. A funkcionális követelmények mellett, fontos a teljesítmény kritikus követelmények meghatározása, melyek később a rendszer integrálás során tesztelésre kerülnek és biztosítják az egész gép egységes teljesítményét az előírt használati körülményeknek megfelelően. 5.4 Traceabilty Mátrix Project menedzsment szempontból fontos, hogy a változásokat minden szinten gyorsan és egyszerűen követni tudjuk. Ezért fontos, hogy az egyes dokumentációs szintek között egyértelmű hozzárendelések biztosítsák a teljes lefedést. Tehát fontos, hogy a követelményeket rendszer szintről egészen a komponens szintig követhessük és a teszteken keresztül a verifikációig is eljussunk. Ez az összeköttetés struktúra vagy gráf ábrázolható egy traceability mátrixszal (nyomon követhetőségi mátrix), ami biztosítja, hogy minden rendszer szintű követelmény ki lett elégítve és nincsenek felesleges vagy nem használt elemek a struktúrában. Ezt szemlélteti a lentebbi ábra, ahol a zöld nyom egy helyes lebontást reprezentál a struktúrában. Ezzel szemben a piros dobozok jelölik azokat az elemeket, amiket nem fedtünk le vagy kihagytunk az implementáció során. Ennek a segítségével a project végén, biztosíthatjuk, hogy ha traceability teljes, akkor nincs olyan követelmény, amivel a fejlesztés nem foglalkozott, nem lett implementálva vagy nem lett letesztelve. 12

13 Figure 3. Traceabilty 5.5 Követelmények Menedzselése Annak érdekében, hogy ezeket a különböző szintű és a szintenként eltérő mennyiségű követelményeket egyszerűen és átláthatóan tudjuk kezelni fontos, hogy olyan eszközöket alkalmaznunk, amelyek a következő tulajdonságokkal rendelkeznek: Robosztus és nagy mennyiségű szöveges tartalom kezelésére alkalmas Több felhasználó olvashat és szerkeszthet egy időben A tartalom több nézetben is megfigyelhető legyen Az egyes dokumentumok külön, jól definiált modulokba rendezhetőek Az egyes dokumentumok verzió kezelhetőek A dokumentum belül, az egyes követelmények és bejegyzések külön-külön verzió kezelhetőek Az egyes fejlesztési fázisokban baseline-ok húzhatóak (Verzió vagy verziók csoportja, amik ha tovább változnak külön tártolódnak és bármikor visszaállíthatóak.) Legalább Szerver- Kliens struktúra a biztonságos adattároláshoz Traceability (Nyomon követhetőség) biztosítása, ami segít egy magasabb szintű követelmény lebontásának a nyomon követésében, egészen az alacsonyabb szintű követelményeken keresztül a verifikációig. Tartalom exportálása pdf, word vagy egyéb szerkeszthető szöveges formátumba Helyesírás ellenőrzés Esetleges Script nyelvek támogatása, amik egyszerű funkciók megvalósítására alkalmas Ha belső fejlesztésű, akkor legyen validálva, hogy a gyártó garantálni tudja a helyes működést és ezáltal a helyes kimeneti dokumentumokat és eredményeket is. Ezeket a szempontokat figyelembe véve és azt, hogy a piacon mit ajánlanak, mint követelmény menedzsment rendszer, az IBM Rational DOORS program került bevezetésre. A Project keretin belül az eddig bemutatott folyamatoknak és a DHF-nek megfelelően felállítottam a DOORS-ban a dokumentációs struktúrát és az egyes szinteknek megfelelően a követelmény specifikációkat is implementáltam. 13

14 6 Fejlesztési folyamat menedzsment Az információs társadalom egyre gyorsabb és nagyobb léptékű változásait, a piacon való versenyt jelentősen befolyásolja, hogy milyen minőségügyi, fejlesztési folyamatokat követünk. Az ipart még mindig nagy mértékben az úgy nevezett vízesés modellen alapuló fejlesztések uralják. A módszer lényege, hogy az egyes lépéseket egymás után, szekvenciális sorrendben hajtjuk végre, ahol minden egyes újabb fázis bementét az előző állapotok kimenetei határoznak meg és nincs visszacsatolás a megelőző állapotokhoz. Figure 4. Vízesés modell Ennek a modellnek a hátránya, hogy lassan reagál a környezet változásaira, az újabb állapotba lépés előfeltétele az előző lépés 100%-os befejezése. Későn történnek tesztelési és átvizsgálási folyamatok, amik jelentősen befolyásolják egy termék végső minőségét, valamint sok esetben a fejlesztési munkák befejezésének a csúszását eredményezheti. Ez jelentős pénz, idő és pozíció vesztéssel járhat. A dinamikus és rugalmasabb változás követés igényei új koncepciók megjelenését hozták magukkal, ilyenek többek közt az úgy nevezett Agilis eszközök, életciklus modellek, amik innovatív folyamat menedzselési eljárásokat fognak össze egy hatékony módszer keretin belül. 6.1 Agilis metódusok a SW fejlesztésben Az agilis módszerek alapja a gyors visszacsatolási pontok meghatározása a kritikus fejlesztési szakaszokban. Ezek az iterációs lépések, olyan tanulási folyamatot biztosítanak, amik segítenek észrevenni az implementációs hibákat, nem megfelelő vagy hiányos implementálásokat, még az életciklus korai szakaszaiban. Lehetővé teszik a fejlesztés skálázhatóságát, könnyebb átlátását, valamint biztosítják a végtermék jó dokumentáltságát, helyesen implementálását, tesztelését és verifikálását. A folyamatos tesztek nem csak a hibák feltárását eredményezik, de a minőség folyamatos növekedését is magukkal hozzák. Az egyik ilyen agilis módszertan a SCRUM, ami a teljes termék egészre vonatkozó jól bevált gyakorlatok, eszközök, konw-how-k gyűjteménye. A SCRUM-ot, olyan SW fejlesztéssel foglalkozó cégek is alkalmazzák, mint az Erricsson, a Noki-Siemens-Networks. Az orvostechnikai eszközök területén, még mindig nem teljesen elfogadott módszer agilis eszközök és fejlesztések alkalmazása, főként a SW fejlesztések területén. A legfőbb problémát az egészségügyi gépekre vonatkozó túlzottan szigorú és erősen szabályozott szabvány rendszer okozza. A szabványok által előírt folyamatok, feladatok, biztonsági és 14

15 dokumentációs elvárások sok esetben nehezen bonthatóak kisebb egységekre és a tesztelési, verifikációs eljárások kivitelezése nehézkes. Ezeket figyelembe véve főbb feladatom volt, hogy a meglévő folyamatokat egy agilis fejlesztési folyamattá szervezzem és ezt egy munkafolyamat menedzselő rendszerrel megvalósítsam. A folyamat, amit meg kellett valósítani az IEC 62304: Medical Device Software Software life cycle processes szabvány definiálja pontosan. A kutatásaim továbbá kiterjedtek egy olyan folyamatmodell megismerésére és kezdeti alkalmazására, ami a szabvány következő verziójába fog bekerülni. Ez az úgy nevezett MediSPICE, ami az autóiparban alkalmazott SPICE modellre épít, de az egészségügyi gépekre specifikus kiterjesztéseket és szigorításokat is egzaktul magába foglalja. Így a jövőben nagyobb hangsúlyt fogunk fordítani ennek a módszernek az elsajátítására és a folyamatink ilyen irányú fejlesztésére. 6.2 A megvalósított SW fejlesztési folyamat A következő ábra vizuálisan illusztrálja az egyes fejlesztési fázisokat, az ott történő aktivitásokat. Egy másik jól bevált eszköz, hogy az egyes állapotokat egy ikonnal párosítjuk, így a vizuális tanulást és felismerést gyorsítjuk. Az ábrán előre mutató nyilak a munkafolyamat folyását ábrázolja, míg a visszamutató nyilak a visszacsatolást az egyes állapot között. Az alap gondolat, hogy bármelyik állapotból vissza tudunk lépni egy előző állapotba és minden állapotnak saját felelőse van, aki az adott lépésnek megfelelően dönthet, hogy tovább engedi az állapot vagy visszaküldi azt egy előzőbe, hogy kijavítsák a talált hibákat. 15

16 Figure 5. Software fejlesztési folyamat START: Egy új funkció, egy Bug vagy hiba implementálása előtt, minden esetben fontos, hogy a feladat jóváhagyásra kerüljön. A fejlesztés vezetőknek, a marketingnek és a további magasabb szerveknek a cégen belül, mérlegelniük kell, hogy milyen fontos az adott feladat megoldása, mekkora a prioritása a legközelebbi határidőhöz képest, mennyi időt és erőforrást igényel a fejlesztés. Ha faladat kiosztásra kerül, akkor elindul fejlesztési folyamat is. 16

17 Requirement Analysis és Review: Minden esetben az egyik legfontosabb bemenetet az adott feladathoz köthető technikai és egyéb követelmények megfogalmazása jelenti. Az agilis fejlesztés feltétele, hogy az első követelmény halmaz, ha nem is teljes, de elégséges a munka elkezdéséhez és a fejlesztők elkezdhetnek dolgozni, mialatt a tanulási fázisokon átesve a követelmények is teljesek lesznek. A bemeneti követelmények meghatározása általában a rendszermérnökök feladata, akik egyértelmű és jól megfogalmazott check-list jellegű követelményeket fogalmaznak meg. Az implementáció során folyamatos követelmények karbantartása a visszajelzések alapján és azok helyességének ellenőrzése. Implementation Phase: o Implementation: Ha az első követelmény halmazt tovább adták implementálásra a mérnökök elkezdenek dolgozni. Meghatározzák milyen architektúrális változásokra van szükség, az esetleges változások milyen kockázattal járhat és hogyan befolyásolja a már létező és implementálják a kódot. Ha a fejlesztés alatt újabb követelmények fogalmazódnak meg azok gyors visszakapcsolásokon keresztül bekerülnek a követelmény specifikációba, így biztosítva a verifikációs eljárás teljességét. A SW komplexszitásától függően akár már implementáció közben el lehet kezdeni a tesztelést. Ilyen lehet a kód szakértők jelenlétében történő átnézése az egyes kódolási szabványoknak megfelelően vagy statikus kód analizátorok alkalmazása, amik előre meghatározott szabályok és metrikák figyelésével elemzik a megvalósított forráskód halmazt. Ez biztosíthat egy állandó naprakész forráskód halmazt, ami lefordítható és szükségszerűen futtatható állapotba helyezhető. o Test Specification:. Tesztelés több fázisban is történhet attól függően milyen mélységben akarunk tesz eseteket megfogalmazni és milyen forráskód vagy rendszer ismereteket igényel teszt. (White-box, Grey-box és Black-box testing.) Mélyebb ismeret igénylő tesztek esetében a fejlesztő előkészítheti az egyes teszt eseteket, amiket a teszt mérnökök fognak futtatni, alkalmazni. Magasabb szinten a SW rendszer architektúráját jól ismerő teszt mérnökök készíthetik elő a teszt eseteket, specifikációkat. Tesztelhetünk pontosan definiált funkcionális SW egységeket, amik lehetnek akár függvények egy meghatározott funkcióval vagy objektum orientál környezetben az egyes objektumok tesztelése is idesorolható. Ezek után integrációs teszt szinten megvizsgálhatjuk, hogy egy adott SW rendszert alkotó egységek és objektumok összessége, hogyan kapcsolódnak egymáshoz, megfelelően elvégzik az alrendszer által meghatározott funkciókat, illeszkedik a tervezett modellhez és képes-e az interfészein keresztül más SW alrendszerekkel és HW egységekkel együttműködni. Esetleg több SW rendszert igénylő orvostechnikai gépek esetében is ajánlott lehet szimulált HW környezetben történő tesztelés, ahol az egyes SW rendszerek együtt működve tesztelhetőek, úgy mintha a valós rendszerben futnának. 17

18 o Testing: Tesztelés során az előre meghatározott teszteseteket hajtják végre. Az iparban sok olyan eszközök található, amik az egyes tesztelési szinteken meghatározott teszteseteket automatikusan lefuttatják és kiértékelik. A másik eshetőség kisebb fejlesztői csapatok esetében, hogy ezt is manuálisan végzik a tesztmérnökök. Ha a teszt megbukik valahol, akkor meg kell vizsgálni, hogy az implementáció a sikertelenség forrása vagy esetleg a teszt kritérium nem megfelelő. Általánosságban ha minden teszt eset eredményesen fut le és nem buknak meg a teszt kritériumokon, akkor az implementáció sikeresnek nevezhető és befejeződhet az implementációs fázis. Verification: A verifikációs állapotban, a verifikálónak a felelőssége, hogy leellenőrizze, hogy minden követelmény implementálva és tesztelve lett. Biztosítja, hogy a traceability létezik-e egészen a követelményektől eredően a tesztekig és megvizsgálja, hogy a folyamat által megkövetelt lépéseket pontosan végrehajtották-e a fejlesztési résztvevők. Ha ezeknek az elvárásoknak megfelel az implementálás, a verifikáció biztosítja hogy az új funkció, hibajavítás illeszkedik a IEC szabvány által elvárt folyamatnak és integrálható a következő SW verzióba. Validation: Az utolsó lépésben a SW fejlesztést vezető főmérnök, rendszermérnök jóváhagyja és aláírásával biztosítja, hogy az új funkció, módosítás bekerülhet a következő kiadott SW verzióba. 18