Orvosi eszközök gyártmányfejlesztése Szoftver Kockázatirányítás. Lukács Viktor Budapest,

Átírás

1 Orvosi eszközök gyártmányfejlesztése Szoftver Kockázatirányítás Lukács Viktor Budapest,

2 Tartalom Bevezetés - Szabványok Szoftver Kockázatelemzés Kockázatértékelés Szoftveres Kockázatbefolyásolás SW Életciklus SW Kockázatirányítás Kockázatirányítás az orvostechnikai eszközt is tartalmazó IT hálózatokban 3

3 Bevezetés - Szabványok System Risk Management Rendszer szintű kockázat irányítás, amely az orvosi eszköz egészével foglalkozik. Kockázat befolyásolási intézkedések RCM (SW követelmények) ISO Medical devices- Application of risk management to medical devices IEC Medical device software Software life cycle processes Chapter 7 Software Risk management Process SW Risk Management Az orvosi eszköz szoftverében megvalósított kockázat irányítási folyamatokkal foglalkozik. Minimálisan eltér a rendszer szintű kockázat irányítástól. IEC/ TR Medical device software - Guidance on the application of ISO to medical device software Software RISK MANAGEMENT is a part of overall MEDICAL DEVICE RISK MANAGEMENT and cannot be adequately addressed in isolation annexe B.7 4

4 5

5 Szoftver rendszer fejlesztési életciklus modell - IEC

6 IEC Medical Device Software Software Life-cycle processes Structure: 1. Scope 2. Normative References 3. Terms and Definitions 4. General Requirements 5. SW Development Process 6. SW Maintenance Process 7. SW Risk Management Process 8. SW Configuration Management Process 9. SW Problem Resolution Process 7

7 7. Szoftver kockázat-irányítási folyamat (Software Risk Management Process) A szoftver kockázat-irányítást nem lehet az orvosi eszköz rendszerszintű kockázat-irányításától függetlenül végezni. A szoftver kockázat-irányítást nem lehet hatékonyan végezni csak úgy, hogy az egyes aktivitásokat a fejlesztési és karbantartási folyamatok közben végezzük. Aktivitások 1. A szoftverhibából eredő veszélyes helyzeteket fel kell tárni. 2. A szoftvertől megkövetelt védőintézkedéseket definiálni és implementálni kell. 3. A szoftvertől megkövetelt védőintézkedéseket ellenőrizni kell. 4. A szoftverváltozásokat (beleértve a SOUP-okat is) meg kell vizsgálni a lehetséges szoftverhibákból eredő veszélyes helyzetek és az implementált védőintézkedések hatékonysága tekintetében. 8

8 ISO 14971: A kockázatirányítási folyamat vázlatos bemutatása 9

9 SW Kockázatelemzés (Risk Analysis, RA) RA (Effectiveness Verification) RA RA 10

10 SW Kockázatelemzés - Szoftver követelmények IEC/TR B1 táblázat- Szoftveres funkcionális területek listája, melyek gyakran okoznak veszélyeket 11

11 SW Kockázatelemzés - Szoftver architektúra Az architektúra tervezés végén áll elő a szoftver elemek teljes listája, amely bemenete a kockázatbefolyásolásnak. Nem szükséges minden egységet külön vizsgálni a potenciális hibák analízise céljából, elég a biztonsági szempontból egyenértékű egységek halmazait (elemeket) megkülönböztetni. Egység 1 Egység 2 Egység 3 Egység 4 Szoftver elem X Szoftver elem Y SOUP Szoftver elem Z 4.3 * Software safety classification a) The MANUFACTURER shall assign to each SOFTWARE SYSTEM a software safety class (A, B, or C) according to the possible effects on the patient, operator, or other people resulting from a HAZARD to which the SOFTWARE SYSTEM can contribute. The software safety classes shall initially be assigned based on severity as follows: Class A: No injury or damage to health is possible Class B: Non-SERIOUS INJURY is possible Class C: Death or SERIOUS INJURY is possible IEC Szoftver rendszer 12

12 SW Kockázatelemzés - Szoftver architektúra Az átlátható, egyszerű architektúra megkönnyíti az elemzést. Példa: Az alábbi esetben nem feltétlenül szükséges a Vezérlő szoftver rendszer alkotó elemeit egyesével vizsgálni, amennyiben annak minden hibája ellen hivatott védeni egy tőle független* HW-en futó Ellenőrző szoftver rendszer. Vezérlő szoftver rendszer Vezérlő HW Ellenőrző szoftver rendszer Ellenőrző HW Orvosi eszköz * Ha a logikai függetlenség csak részben garantálható, a Vezérlő szoftver függelmi részeinek további szegregációja és kockázatelemzése szükséges! 13

13 SW Kockázatelemzés - Szoftver részletes terv és megvalósítás IEC/TR B2 táblázat- Szoftveres hibák listája, melyek gyakran okoznak kiszámíthatatlan veszélyeket más szoftver elemekben (is), mint ahol létrejönnek 14

14 SW kockázat becslés A kockázat a valószínűség és a súlyosság kombinációja: (P1 P2 P3 P4) S Példa: Sugárkezeléshez használt berendezés P1: annak a valószínűsége, hogy a SW hibázik = 100% P2: annak a valószínűsége, hogy a SW hiba miatt magas a sugárzás a kimeneten P3: annak a valószínűsége, hogy a magas sugárzás káros P4: annak a valószínűsége, hogy a káros magas sugárzás ellen nincs védő intézkedés és így a páciensnek kárt okozunk 15

15 Szoftveres hibákból eredő ártalmak valószínűsége (példa) Abbreviation Title Criteria Example Fre Frequent > 1 in 100 per patient year Software failure in an undefined safety class Software failure in an Class A software Pro Probable 1 in 100 to 1 in 1,000 per patient year Occ Occasional 1 in 1,000 to 1 in 10,000 per patient year Rem. Remote 1 in 10,000 to 1 in 100,000 per patient year Imp Improbable 1 in 100,000 to 1 in 1,000,000 per patient year Software failure in a Class B software Software failure in a unit developed as a safety class A software, protected by an independent software channel developed as a safety class B software (IEC 62304). Software failure in a Class C software Software failure in a unit developed as a safety class B software, protected by an independent software channel developed as a safety class B software (IEC 62304). Software failure in a unit developed as a safety class A software, protected by an independent software channel developed as a safety class C software (IEC 62304). Software failure protected by an independent hardware channel at least partially tested at least annually and its software (if contained) is developed as a safety class B software (IEC 62304) and its operation is checked by a separate independent channel periodically. Software failure protected by an independent hardware channel not tested and its software (if contained) is developed as a safety class C software (IEC 62304). Software failure in a unit developed as a safety class B software, protected by an independent software channel developed as a safety class C software (IEC 62304). Software failure protected by an independent hardware channel at least partially tested at least daily and its software (if contained) is developed as a safety class B software (IEC 62304) and its operation is checked by a separate independent channel periodically. Software failure protected by an independent hardware channel tested at least annually and its software (if contained) is developed as a safety class C software (IEC 62304) Software failure in a unit developed as a safety class C software, protected by an independent software channel developed as a safety class C software (IEC 62304). Software error in a unit developed as a safety class B software, protected by an independent software channel developed as a safety class C software (IEC 62304) and its working is monitored by an independent hardware channel tested at least daily and its software (if contained) is developed as a safety class C software (IEC 62304). 16

16 Veszélyes helyzetből eredő ártalmak súlyossága (példa) Abbreviation Title Criteria Example Neg Negligible Minor harm to patient or Cut treatable with plaster. staff Stress during treatment. Dialysis was not effective - Uraemia between dialyses. First degree burn. Blood loss of less than 100 ml. Sprain. Mar Marginal Short term harm to patient or staff, medical action is necessary Haematoma. Hypotension (low systolic blood pressure). Hyperpotassemia (damage to the red blood cells results in too much potassium in blood). Fever. Sickness and vomiting Blindness. Sev Severe Long term or permanent harm Long term liver damage. Cri Critical Single death Death. Cat Catastrophic Multiple deaths Machine catching fire as the smoke is poisonous. Back flow of liquid poisons water supply. Design or manufacturing defect with consequence of death. Material (bio incompatibility) releases toxic component into patient s blood. 17

17 SW Kockázatelemzés Szisztematikus módszerek (pl.) Hibafaelemzés (Fault Tree Analysis, FTA): Fentről lefelé építkező technika azaz a lehetséges nem kívánatos következmény alapján vizsgáljuk a lehetséges okokat, hibákat. Hatékonyan végezhető rendszer szinten, pl. előzetes hazárd elemzés eredménye alapján. Hibamód- és hatáselemzés (Failure Modes and Effects Analysis, FMEA): Lentről felfelé építkező technika azaz a lehetséges hibák alapján vizsgáljuk a következményt. Hatékonyan végezhető pl. SW architektúra elemekre nézve. [IEC 60812] 18

18 SW Kockázatelemzés Szisztematikus módszerek FMEA példa No. Form Software Component Reference Software Item Failure Mode No. FRC Failure Root Cause (FRC) Failure Consequence Control Measure Component Traceability Matrix Reference Probability Severity Detectability REN (Risk Evaluation Number) P*S*D Additional measures necessary? 1 diagnosztizáló SW egység2 hibás kalkuláció 34 memória hibás korrupció diagnózis, félrekezelés MMU MMU ellenőrzési riport no Risk Acceptance Probability of Occurrence : P Severity : S Detectability : D results in the Risk Evaluation Number REN = P x S x D. 19

19 Likelihood Kockázatértékelés Frequent Greater than 1 in 100 per patient year for a patient using the device or product Probable Between 1 in 100 and 1 in 1,000 per patient year for a patient using the device or product Occasional Between 1 in 1,000 and 1 in 10,000 per patient year for a patient using the device or product Remote Between 1 in 10,000 and 1 in 100,000 per patient year for a patient using the device or product Fre Pro Occ Rem Not Acceptable Region Broadly Acceptable Region with Exteded Inspection This International Standard does not specify acceptable risk. That decision is left to the manufacturer. IEC Improbable Between 1 in 100,000 and 1 in 1,000,000 per patient year for a patient using the device or product Incredible Less than 1 in 1,000,000 per patient year for a patient using the device or product Imp Inc Broadly Acceptable Region Risk Matrix for Device and Product Risk Assessments Neg Mar Sev Cri Cat Negligible Minor harm Marginal Short term harm, medical action necessary Severe Long term or permanent harm Severity Critical Single death Catastrophic Multiple deaths 20

20 Szoftveres Kockázatbefolyásolás Védőintézkedés (Risk Control Measure, RCM) 21

21 Szoftveres Kockázatbefolyásolás - Biztonsági osztályozás (1) A biztonsági osztályozás súlyosság (Severity) alapú: Negligible Software class A Marginal Software class B Severe Software class C Critical Software class C Catastrophic Software class C A biztonsági osztály csökkenthető, amennyiben a kockázatbefolyásoló - súlyosságot vagy valószínűséget csökkentő - hardveres védőintézkedésekkel a maradék kockázat elfogadható mértékűvé vált. A biztonsági osztálynak megfelelő aktivitások/feladatok vonatkoznak az adott szoftver elemre. 22

22 Szoftveres Kockázatbefolyásolás - Biztonsági osztályozás (2) A biztonsági osztályozás öröklődő szoftver elemek között, de elkülönítéssel csökkenthető egyes alsóbb szintű elemek biztonsági osztályozása. 23

23 Szoftveres Kockázatbefolyásolás - Biztonsági osztályozás (3) A biztonsági osztályba sorolásnál figyelembe kell venni az adott szoftver egység által potenciálisan okozott ártalom súlyosságát, illetve az adott szoftver egység által esetlegesen implementált védőintézkedést szükségessé tevő ártalom súlyosságát! A megfelelő biztonsági szoftver architektúra gondos kozkázatmegállapítás (risk assessment) eredménye kell, hogy legyen. A szoftver rendszert úgy kell megtervezni, hogy egy SOUP/OTS meghibásodása esetén is megfelelő védelmet biztosítson. d) When a SOFTWARE SYSTEM is decomposed into SOFTWARE ITEMS, and when a SOFTWARE ITEM is decomposed into further SOFTWARE ITEMS, such SOFTWARE ITEMS shall inherit the software safety classification of the original SOFTWARE ITEM (or SOFTWARE SYSTEM) unless the MANUFACTURER documents a rationale for classification into a different software safety class. Such a rationale shall explain how the new SOFTWARE ITEMS are segregated so that they may be classified separately. IEC

24 Example of risk based Item/Unit test strategy Verification Unit In Item A In Item B In Item C Review O M M Independent review O O M Rule check M M M Basic Unit test O M M 100% Code coverage O O M Integration level test O O M M=Mandatory O=Optional Class A: No injury or damage to health is possible Class B: Non-SERIOUS INJURY is possible Class C: Death or SERIOUS INJURY is possible 25

25 26

26 Example of risk based requirement test strategy Req.Class A B C Verification Exploratory O O M Scripted(Req. Based) M M M Independent Review O M M M=Mandatory O=Optional Risk control measures included in reqs Class A: No injury or damage to health is possible Class B: Non-SERIOUS INJURY is possible Class C: Death or SERIOUS INJURY is possible 27

27 Szoftveres Kockázatbefolyásolás - Nyomonkövethetőség Biztosítani kell a nyomonkövethetőséget: Veszélyes helyzet Kiváltó szoftver egység az architektúrában Szoftveres ok Védőintézkedés (HW, SW) Védőintézkedés (SW) Szoftver követelmény Implementáló szoftver egység az architektúrában Részletes terv Szoftver egység implementáció Szoftver egység ellenőrzés Szoftver integrációs teszt Szoftver rendszer teszt Védőintézkedés hatékonyságát igazoló ellenőrzés 28

28 SW Életciklus SW Kockázatirányítás 5. Szoftver fejlesztési folyamat (Software Development Process) 5.1 SW development planning 5.2 SW requirements analysis 5.3 SW architectural design 5.4 SW detailed design 5.5 SW UNIT implementation & verification 5.6 SW integration and integration testing 5.7 SW system testing 5.8 SW release 29

29 5.1 Szoftver fejlesztés tervezés (Software development planning) [ ] Kockázat-irányítási terv a szoftver kockázat-irányítási folyamatára - (tartalma megegyezik a 3.4 /ISO 14971) A terv tartalma: A terv alkalmazási területe, az orvostechnikai eszköz és az életciklus szakaszai, amelyre a terv alkalmazható Felelősségek és hatáskörök kijelölése (kockázatirányítási csapat) Kockázatirányítási folyamat átvizsgálási követelményei A kockázat elfogadhatósági kritériumok (kockázat mátrix) a gyártó kockázat politikájával összhangban Az igazolási (verifikálási) terv Gyártási és gyártás utáni információk gyűjtésének és átvizsgálásának módja 30

30 5.2 Szoftver követelmény analízis (Software requirements analysis) *IEC Table D1. Life-cycle/ risk management (fordítás a teljesség igénye nélkül) kockázatelemzés Analizálni az eszköz alkalmazási célját (intended use) Azonosítani az ismert és előrelátható kapcsolódó veszélyeket Figyelembe venni a termék fázisait, pl. installáció,oktatás, használat, frissítés, karbantartás SW biztonsági osztályozás kockázatértékelés Dönteni, vajon szükséges-e kockázatcsökkentés? Meghatározni, hogy szoftveres védőintézkedés elegendő, megfelelőe, vagy hardveres védőintézkedés szükséges és megvalósítható-e? kockázatbefolyásolás Azonosítani a szoftveres védőintézkedéseket az azonosított kockázatokra ( pl. hardver hibák vagy felhasználói hibák által) Azonosítani a szoftvert amely növeli a detektálhatóságot, csökkenti a súlyosságát és/vagy valószínűségét egy veszélyes helyzetnek 31

31 5.3 Szoftver architektúra tervezés (Software architectural design) kockázatelemzés Azonosítani a kritikus adatokat és komponenseket Azonosítani a kapcsolódó veszélyeket Azonosítani az interfészeket, mit kommunikálnak és mikor SW biztonsági osztályozás kockázatértékelés Újraértékelni a szoftvernek szánt szerepet kockázati szempontból Kiértékelni a nem biztonságkritikus funkciók védőintézkedésekre gyakorolt hatását kockázatbefolyásolás Izolálni a kritikus komponenseket Különösen figyelni a helyesen megválasztott redundanciára Azonosítani a redundanciával kapcsolatos veszélyeket Azonosítani a globális módszereket a detektálásra 32

32 5.4 Szoftver részletes tervezés (Software detailed design) kockázatelemzés Azonosítani a további potenciális okokat a veszélyekre Feltételezni az adat, kódolási, átviteli hibákat Feltételezni a hardver hibákat kockázatértékelés Újraértékelni a védőintézkedések megfelelőségét, alkalmasságát Meghatározni a nem biztonságkritikus és biztonságkritikus kódokat kockázatbefolyásolás Speciális védőintézkedéseket bevezetni a programozási gyakorlatra Komplett nyomon követés és lefedettség analízis, annak ellenőrzésére, hogy a védőintézkedések megvalósultak Felderíteni, ha nem specifikált funkció lett megvalósítva 33

33 5.5 Szoftver egység megvalósítás és ellenőrzés (Software unit implementation and verification) kockázatelemzés Azonosítani a további potenciális okokat a veszélyekre Kiértékelni a teszt hibákat a hasonló kód implementációra kockázatértékelés Újraértékelni a védőintézkedések megfelelőségét, különböző feltételek melletti vizsgálat, teszt segítségével, valamint reprezentatív felhasználóval és környezetben való teszteléssel kockázatbefolyásolás Regressziós tesztek a védőintézkedésekre a végső release előtt Kiegészíteni a nyomon követés és lefedettség analízist, annak ellenőrzésére, hogy a védőintézkedések megvalósultak és tesztelve voltak Statisztikák szerint a SW hibák 70%-áért az első kiadott verzió utáni módosítások a felelősek! 34

34 5.6 Szoftver integráció és integrációs teszt (Software integration and integr. testing) 5.7 Szoftver rendszer tesztelés (Software system testing) kockázatelemzés kockázatértékelés kockázatbefolyásolás - - Regressziós tesztek a védőintézkedésekre a végső release előtt Kiegészíteni a nyomon követés és lefedettség analízist, annak ellenőrzésére, hogy a védőintézkedések megvalósultak és tesztelve voltak 35

35 5.8 Szoftver kiadás (Software release) kockázatelemzés Azonosítani a konfigurációirányítási tervet, benne a konfigurációs egységekkel kockázatértékelés Értékelni kell a fennmaradó rendellenességeket kockázatbefolyásolás Igazolni, hogy a felhasznált szoftver elemek és SOUPok megfelelő verziói kiadott állapotban vannak Igazolni, hogy a build környezet konfiguráció ellenőrzés alatt van 36

36 6. Szoftver karbantartási folyamat (Software Maintenance Process) Szoftver karbantartási tervet kell készíteni, melynek: [ ] elő kell írnia a kockázat-irányítási, konfiguráció irányítási és probléma megoldási folyamatok használatát, Probléma és módosítás analízis aktivitás kiadott szoftver termékre nézve: A visszajelzéseket monitorozni és értékelni kell. A probléma jelentések hatásait meg kell vizsgálni a biztonságra való tekintettel, és szükség esetén módosítási kérelmet kell indítani. [ ] A végrehajtott szoftverváltozásokat (beleértve a SOUP-okat is) meg kell vizsgálni a lehetséges szoftverhibákból eredő veszélyes helyzetek és az implementált védőintézkedések hatékonysága tekintetében. 37

37 Orvostechnikai eszközök IT hálózatban IEC /TR Application of risk management for IT networks incorporating medical devices, Part 1: roles, responsibilities and activities IEC /TR Application of Risk management for IT networks incorporating medical devices, Part 2-1 Step by step risk management of medical IT networks- Practical applications and examples ( A hálózati környezetben működő számítógép vezérelt orvosi eszközök növekvő elérhetősége veszély forrást jelent. Ilyen orvosi rendszerek pl. a betegmonitorok és központi állomások, okos infúziós pumpa rendszerek és információs rendszerekhez kapcsolódó eszközök, melyek felügyeletet és riasztást látnak el. Veszélyt jelent, amikor az orvosi eszközrendszert megváltozott környezetben használják, amelyet egyáltalán nem vagy csak részben vett figyelembe az orvosi eszköz gyártó. Miután a szabályozott orvosi eszköz rendszer a felhasználási helyén telepítve lett, a hálózati környezet kiépítése, üzemeltetése és időbeli változtatása (pl. kábel WiFi), illetve új rendszerek hálózatba kapcsolása mind hatással lehetnek az orvosi eszköz biztonságosságára és hatékonyságára. 38

38 Orvostechnikai eszközök IT hálózatban (folyt.) A gyártó felelősége: A hálózati csatlakozás lehetőségét figyelembe véve tervezze meg az eszközt! Közölje az üzemeltetővel a hálózati csatlakoztatás szándékolt használatát! Szűkítse a szükséges minimumra a lehetőségeket! Informálja az üzemeltetőt a kockázatokról! Az üzemeltető felelősége: Új szerepkör definiálása: Orvosi IT-hálózati kockázatirányító. Kockázatirányítás a hálózat teljes életciklusa alatt. 39

39 Köszönöm a figyelmet! Kérdések? 40