-醫療器械軟件申報基本要求_第1頁
-醫療器械軟件申報基本要求_第2頁
-醫療器械軟件申報基本要求_第3頁
-醫療器械軟件申報基本要求_第4頁
-醫療器械軟件申報基本要求_第5頁
已閱讀5頁,還剩123頁未讀, 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、醫療器械軟件申報基本要求審評一處 彭亮2011.8內容摘要失效案例與召回分析軟件與軟件工程概述軟件主要標準介紹軟件監管情況綜述軟件申報資料要求軟件申報注意事項1 失效案例與召回分析軟件失效案例FDA召回分析1.1 軟件失效案例直線加速器19851987年,Therac-25加速器因軟件失效導致6人受到超劑量輻射,其中3人死亡,1人截肢2001年,加速器因軟件和操作錯誤導致巴拿馬5人死亡起搏器和ICD起搏器典型代碼行數為80000行19902000年, 起搏器召回的41%與軟件失效有關19972003年,美國至少有212人因ICD失效而死亡2008年,美國約使用350000個起搏器和140000

2、個ICD1.1 軟件失效案例輸液泵輸液泵典型代碼行數為170000行1997年,Gish公司輸液泵因軟件邏輯錯誤引起嗎啡過量輸入,導致1人死亡2006年,Cardinal公司靜脈輸液泵因軟件設計缺陷引起輸液過量,導致2人死亡,其中1人是出生僅16天的嬰兒,被注入了44.8ml營養液,而處方僅為4.8ml20052009年,FDA收到約56000條輸液泵抱怨記錄,其中710人死亡I級召回2007年,FDA有3例I級召回與軟件失效有關(共23例)2009年,2例手術導航和1例鎮痛泵因軟件失效I級召回1.2 FDA召回分析19831991共召回2792個,軟件失效165個,占總數5.9%199219

3、98共召回3140個,軟件失效242個,占總數7.7%其中軟件變更導致召回192個,占軟件失效79.3%19992005共召回3771個,軟件失效425個,占總數11.3%其中內含軟件器械共召回1261個,占總數33.4%,軟件失效占內含軟件器械召回33.7%1.2 FDA召回分析麻醉類:麻醉機、呼吸機心臟類:起搏器、除顫儀通用類:監護儀、輸液泵診斷類:生化儀、病理儀時期時期麻醉類麻醉類心臟類心臟類通用類通用類診斷類診斷類影像類影像類手術類手術類其他類其他類1983199710%21%10%19%30%3%7%199920051.2%8.1%12.7%34.9%33.2%1.1%8.8%200

4、92.8%5.6%11.3%14.1%60.6% 5.6%影像類:X射線類(診斷、治療)、磁共振、超聲手術類:電刀、激光類其他類:含婦產科和眼科1.2 案例與召回軟件失效足以致命,且所占比例較高軟件失效增速高于醫療器械整體情況內含軟件器械召回1/3與軟件失效有關軟件變更是導致軟件失效的主要原因影像類器械的軟件失效問題最為突出2 軟件與軟件工程概述軟件概述軟件工程概述 軟件質量概述2.1 軟件概述定義軟件是程序、數據和文檔的集合程序 = 算法 + 結構分類(GB/T 13702-1992)系統軟件:操作系統、實用程序、網絡系統支持軟件:開發工具、管理工具、數據庫管理系統應用軟件:數據圖像、控制類

5、、輔助類、安全保密基本特點復雜性:不同輸入不同執行路徑,人為因素無處不在靈活性:同一需求多種實現方式,后續變更容易快速2.1 算法概述定義在有限步驟內解決問題的一系列明確指令特征輸入項:一個算法必須有零個或多個輸入輸出項:一個算法必須有一個或多個輸出明確性:算法每一步驟必須有確切的定義 有限性:算法必須在有限步驟內完成任務有效性:每一步驟可分解為基本運算步驟復雜度時間復雜度、空間復雜度2.1 軟硬件差異硬件是物理實體,軟件是邏輯關系硬件變更周期長,軟件變更容易快速硬件有磨損現象,軟件雖無磨損,但有退化現象硬件質量取決于設計、開發和生產,軟件質量取決于設計和開發,與生產基本無關硬件失效先有征兆再

6、發生,軟件失效沒有征兆突然發生,軟件失效率遠高于硬件(100:1)硬件部件可以標準化,軟件組件標準化較為復雜細微變更對硬件影響有限,對軟件影響可能嚴重2.2 軟件危機對開發進度和成本的估計常常很不準確用戶對交付軟件不滿意的現象常常發生軟件產品質量往往靠不住軟件常常是不可維護的軟件沒有合適的文檔資料軟件成本占計算機總成本的比例逐年上升軟件生產率增速遠遠跟不上硬件性能增速2.2 軟件工程基本原理用分階段的生存周期過程嚴格管理堅持進行階段審評實行嚴格產品控制采用現代程序設計技術結果應能清楚審評開發小組人員應少而精承認不斷改進軟件工程實踐的必要性2.2 軟件生存周期體系結構設計詳細設計系統測試需求分析

7、集成測試編碼運行維護廢棄發行安裝開發策劃配置管理缺陷管理單元測試2.2 生存周期模型瀑布模型增量模型2.2 生存周期模型快速原型模型螺旋模型2.2 生存周期模型V模型W模型2.2 軟件測試分類黑盒測試、白盒測試(靜態測試、動態測試)單元測試、集成測試、系統測試內部測試、用戶測試、第三方測試方法白盒測試:代碼檢查、靜態結構、靜態質量、基本路徑覆蓋、邏輯覆蓋(語句、判定、條件、多條件)黑盒測試:等價類、邊界值、場景法、因果圖、正交試驗、判定表、隨機測試、功能分解、錯誤推測2.2 軟件測試系統測試安裝性測試、兼容性測試功能測試性能測試、負載測試、壓力測試、并發性測試、配置測試、接口測試、可靠性測試、

8、恢復性測試可用性測試、界面測試安全性測試回歸測試用于確定軟件更改沒有產生不良影響或沒有引入新缺陷軟件如有變更均需進行適當且足夠的回歸測試2.2 軟件維護分類完善型:提高軟件功能、性能的變更糾正型:糾正軟件缺陷的變更適應型:改變軟件運行環境的變更統計數據完善型5066%、糾正型1721%、適應型1825%維護費用占軟件生存周期總成本的5080%具體要求軟件維護應進行適當且足夠的回歸測試工作量取決于變更的組件、類型和運行環境工作量也取決于原有開發文檔的詳盡程度2.2 軟件文檔階段相應文檔開發策劃開發計劃、質量管理計劃、風險管理計劃、配置管理計劃、文檔計劃需求分析需求規格、初步測試計劃設計設計規格、

9、各級測試計劃編碼代碼規范、問題解決程序測試各級測試報告、問題解決程序發行安裝說明書運行維護維護計劃、問題解決程序2.2 軟件與軟件工程2.3 軟件質量概述名稱Bug、缺陷、錯誤、故障、失效、異常異常根源軟件若超過169行可執行代碼無法確保完全正確軟件測試由于時間和成本限制不能遍歷所有路徑屬性軟件缺陷與生俱來,不可避免,也無法根除現有已知方法不能保證任何軟件100% 質量原則盡早測試、重點測試、全面測試2.3 復雜度與測試公式軟件復雜度 = NIOPN為軟件類型,I為輸入次數,O為輸出次數,P為指數舉例假設N=1,P=2,輸入2個參數,輸出2個參數,每個參數均為8位數據,執行一次測試耗時1毫秒,

10、則測試所有參數組合耗時為: 282(282)2/(103360024365)8925年假設用戶名為10位數字和字母組合,字母區分大小寫,測試一個用戶名耗時1納秒,則測試所有用戶名耗時為: (10+262)10/(109360024365)26年2.3 缺陷來源2.3 統計數據時間比例需求設計1/3,編碼1/6,測試1/2起源階段需求54%,設計25%,編碼15%,其他6%修正成本設計:編碼:測試:發布=1:6.5:15:60100退化現象每修正25個缺陷就會產生1個新缺陷群集現象“80%”的缺陷集中于“20%”的程序2.3 影響因素計劃和資源語言工具和方法文檔復雜性環境人員培訓組織形式需求轉換

11、和可追溯性測試方法維護現有軟件原型現有類似軟件質量特征設計參數折中2.3 質量度量分類產品度量:用于描述產品特征和質量水平項目度量:用于描述項目特性和執行狀態過程度量:用于開發和維護過程的優化改進過程度量需求分析度量:功能點度量設計度量:形態度量、界面度量源代碼度量:規模度量規模度量、Halstead度量測試度量:DRE度量維護度量:SMI度量2.3 生存周期質量2.3 質量體系與模型質量體系ISO 90003(GB/T 19003)CMM / CMMISPICE(ISO/IEC 15504)質量模型Boehm模型:功能要求、可維護性、可移植性McCall模型:產品運行、產品修改、產品轉移IS

12、O 9126模型:功能性、可靠性、易用性、效率、維護性、可移植性2.3 質量特性與測試3 軟件標準介紹軟件標準概述YY/T 0664介紹YY/T 0708介紹GB/T 25000.51介紹DICOM與HL7簡介3.1 軟件標準概述IEC 62304:2006( YY/T 0664-2008)IEC 60601-1-4:2000(YY/T 0708-2009)IEC 61508系列7標準(GB/T 20438系列)IEC 62274:2005(YY 0721-2009) ISO/IEC 9126系列4標準(GB/T 16260系列)ISO/IEC 14598系列6標準(GB/T 18905系列)

13、ISO/IEC 25051:2006(GB/T 25000.51-2010) ISO/IEC 12119:1994(GB/T 17544-1998)DICOM與HL73.1 軟件標準概述IEC 80001-1:2010Application of risk management for IT-networks incorporating medical devices - part 1: roles, responsibilities and activities IEC/TR 80002-1:2009Medical device software - Part 1: Guidance on

14、the application of ISO 14971 to medical device softwareIEC 82304-1Healthcare software systems - Part 1: General requirementsIEC 62366:2007Medical devices - Application of usability engineering to medical devices3.2 YY/T 0664介紹背景測試本身不足以確保軟件運行的安全性沒有已知方法可保證任何軟件100%安全性目的規定醫療器械軟件的生存周期要求通過規定過程、活動和任務,為醫療器械

15、軟件生存周期過程建立共同框架作用通過對設計、測試和驗證的詳盡嚴格的要求來增強醫療器械軟件的可靠性增強醫療器械軟件的安全性和有效性3.2 YY/T 0664介紹范圍醫療器械軟件的開發和維護包括未知來源軟件(SOUP)醫療器械軟件在被開發醫療器械內的已開發的軟件系統預期本身用作醫療器械而開發的軟件系統未知來源軟件已經開發且通常可以得到的,并且不是用以包含在醫療器械內而開發的軟件以前開發的、不能得到其開發過程足夠記錄的軟件3.2 YY/T 0664介紹要求質量管理、風險管理和軟件工程相結合實施本標準確定的過程、活動和任務本標準要求生成任務文件本標準要求建立生存周期模型注意事項不為制造商規定組織結構不

16、規定任務文件的特定格式不規定特定的生存周期模型3.2 安全性級別嚴重傷害直接或間接導致下列結果的傷害或疾?。何<吧斐扇梭w功能的永久性損害或者人體結構的永久性損壞需要內科或外科介入以防止人體功能的永久性損害或人體結構的永久性損壞永久性人體功能或結構的不可恢復的損害或損壞,微不足道的損害或損壞除外3.2 安全性級別安全性級別A級:不可能對健康有傷害和損壞B級:可能有不嚴重不嚴重的傷害C級:可能死亡或嚴重傷害嚴重傷害具體要求制造商應賦予每個軟件系統一個安全性級別并形成文檔軟件系統如分解為軟件項,軟件項應繼承原有安全性級別,除非制造商以文件形式給出理由每個軟件系統被賦予安全性級別之前均應按照C級要

17、求安全性分級方案不期望與YY/T 0316的風險分級相一致3.2 安全性級別軟件系統C級軟件項B級軟件項C級軟件項B級軟件項C級軟件項A級軟件單元B級軟件單元A級軟件單元C級軟件單元B級軟件單元A級軟件單元A級軟件單元A級3.2 生存周期過程過程軟件開發過程軟件維護過程軟件風險管理過程軟件配置管理過程軟件問題解決過程過程分類實施于所有醫療器械軟件,標記為A、B、C級實施于選定的軟件項,標記為B、C級或C級3.2 生存周期過程開發策劃需求分析體系結構設計詳細設計單元實現和驗證集成和集成測試系統測試軟件發行制定維護計劃問題和修改分析修改實施軟件危害處境分析風險控制措施軟件更改風險管理風險控制措施驗

18、證配置標識更改控制狀態記錄準備問題報告研究問題通知相關方應用更改程序保持記錄分析問題趨勢驗證問題解決測試文檔內容制定維護計劃問題和修改分析修改實施制定維護計劃問題和修改分析3.2 風險管理概述*軟件本身不是危害,但會引發危害處境軟件表現為隨機失效,但實為系統性失效軟件失效概率難以計算,通?;趽p害嚴重度分析(失效概率假定為100%)要求軟件風險管理是整個醫療器械風險管理的組成部分,孤立分析是不合適的ISO14971沒有特別闡述軟件的風險控制和軟件生存周期過程的風險控制,本標準對軟件的風險控制提供了附加要求3.2 風險管理失效模式與影響分析(FMEA)自下而上的標準的可靠性分析工具用于部件設計、

19、部件制造和用戶使用的失效分析故障樹分析(FTA)自上而下的可靠性與安全性分析工具采用邏輯門符號對頂事件進行圖解分析危害分析與關鍵控制點(HACCP)一種識別、評價和控制危害的系統性方法基于FDA的HACCP應用指南的七個原則3.2 配置管理與問題解決配置管理內容:確定配置項,建立基線,形成文檔作用:標識軟件項,控制變更,提供狀態報告問題解決內容:分析問題,評估影響,提出變更請求作用:解決開發、運行和維護所發現的異常3.3 YY/T 0708介紹背景GB 9706.1通用標準的并列標準基于風險管理和開發生存周期目的規定了可編程醫用電氣系統設計過程的要求作為專用標準要求的基礎,包括作為降低和管理風

20、險的安全要求指南范圍帶有可編程電子子系統的醫用電氣設備或醫用電氣系統3.3 YY/T 0708介紹可編程電子子系統基于一個或多個中央處理單元的系統,包括軟件和接口,簡稱PESS舉例(GB/T 20438.4-2006):微處理器、微控制器、可編程控制器、專用集成電路(ASIC)、可編程邏輯控制器(PLC)、其他以計算機為基礎的裝置(智能傳感器、變送器、執行器)可編程醫用電氣系統包含一個或多個可編程電子子系統的醫用電氣設備或醫用電氣系統,簡稱PEMS3.3 嵌入式系統定義IEEE定義:嵌入式系統是用于控制、監視或者輔助裝備、機器或設備運行的裝置嵌入式系統是以應用為中心,以計算機技術為基礎,軟件與

21、硬件可剪裁,以滿足對功能、可靠性、成本、體積和功耗等要求的專用計算機系統 嵌入式軟件是基于嵌入式系統而設計的軟件,同樣分為系統軟件、支持軟件和應用軟件 特征特點:專用性、實時性、可靠性、可剪裁性、可約束性優勢:體積小、功耗低、功能強、性價比高、操作簡便3.3 可編程醫用電氣系統3.3 標準比較相同之處風險管理、生存周期、過程標準差異之處YY/T 0708YY/T 0664對通用標準的補充適用于PEMS開發生存周期包含安全性確認與其他標準共同使用適用于醫療器械軟件開發和維護生存周期不覆蓋醫療器械確認3.3 標準比較YY/T 0708YY/T 066452.201 文件4.1 質量管理體系,4.2

22、 風險管理52.202 風險管理計劃4.1 質量管理體系,4.2 風險管理5.1.7 軟件風險管理策劃52.203 開發生存周期5.1.1 軟件開發計劃9 軟件問題解決過程 52.204 風險管理過程4.2 風險管理,4.3 安全性級別7 軟件風險管理過程52.205 人員資格4.1 質量管理體系52.206 需求規格說明5.2 軟件需求分析,7.2 風險控制措施52.207 體系結構5.3 軟件體系結構設計3.3 標準比較YY/T 0708YY/T 066452.208 設計和實現5.4 軟件詳細設計5.5 軟件單元實現和驗證52.209 驗證5.5 軟件單元實現和驗證5.6 軟件集成和集成

23、測試5.7 軟件系統測試52.210 確認4.1 質量管理體系52.211 修改6 軟件維護過程7.4 軟件更改風險管理8 軟件配置管理過程9 軟件問題解決過程52.212 評定4.1 質量管理體系3.3 獨立軟件與軟件組件內容獨立軟件軟件組件結構組成系統子系統開發策劃軟件系統醫療器械需求分析市場客戶醫療器械設計軟件軟硬件結合編碼軟件軟件單元測試軟件軟件集成測試軟件軟硬件結合系統測試軟件軟硬件結合發行軟件系統醫療器械3.4 GB/T 25000.51介紹范圍適用于商業現貨(COTS)軟件產品僅涉及向用戶提供產品置信度,不涉及生產過程和供方質量體系內容COTS軟件產品的質量用于測試COTS軟件產

24、品的文檔要求COTS軟件產品的符合性評價細則對安全或業務攸關COTS軟件產品的建議3.4 標準比較結構變化GB/T 25000.51:共7章3附錄1參考文獻GB/T 17544:共4章3附錄(含參考文獻)內容變化新版第5章與老版第3章基本一致,不過與GB/T 16260的關系更為緊密新版第6章與老版第4章變化較大,新版刪除了老版測試活動的內容,增加了測試文檔的要求新版增加了第2章“符合性”和第7章“符合性評價細則”3.4 標準比較GB/T 25000.51第5章GB/T 17544第3章差異內容5.1.3.5 法律或行政要求5.1.3.6 最大并發用戶數5.1.3.8 特定軟件和硬件5.1.4

25、.4 軟件組件選項版本5.1.6.6 可訪問性規定標示5.1.10 使用質量陳述5.2.5 易學性5.2.6 可操作性3.1.2 h)要交付項3.1.5 e)使用效率和用戶滿意度3.2.5 可瀏覽性3.3.3 c)可操作性3.4 標準比較GB/T 25000.51第5章GB/T 17544第3章細化內容5.1.7 效率陳述5.1.8 維護性陳述5.1.9 可移植性陳述5.2.1 完備性3.1.6 效率說明3.1.7 可維護性說明3.1.8 可移植性說明3.2.1 完整性調整內容5.1.9.2 配置條件5.1.9.3 安裝規程3.1.2 f)要求的系統3.1.2 i)安裝3.4 標準比較GB/T

26、 25000.51第6章GB/T 17544第4章6.1 一般要求6.2 測試計劃要求(方法、準則、環境、進度)6.3 測試說明要求(測試用例說明、測試規程)6.4 測試結果要求(執行報告、異常情況報告、結果評估)4.1 測試預要求4.2 測試活動4.3 測試記錄4.4 測試報告4.5 跟蹤測試3.4 標準關系框圖軟件組件獨立軟件GB/T 25000.51相應產品標準YY/T 0664YY/T 0708生存周期過程產品確認3.5 DICOM簡介全稱醫學數字成像與通信標準目的醫學圖像的傳輸概況由美國放射學會ACR和美國電子制造商協會NEMA制定1985年1.0版,1988年2.0版,1993年3

27、.0版目前由九部分內容組成,擴展部分正在討論認證通過DICOM符合性聲明自我認證 詳細描述產品滿足的DICOM內容3.5 HL7簡介全稱衛生信息交換標準 目的醫學文本信息的傳輸概況成立于1987年,1994成為美國國家標準局ANSI所授權的標準開發組織1987年1.0版,2000年2.4版,現已開發3.0版由觸發事件、消息、段和字段組成 認證非正式的自我聲明3.5 DICOM與HL74 軟件監管情況綜述FDA軟件監管綜述歐盟軟件監管綜述FDA與歐盟的比較我國軟件監管現狀4.1 FDA軟件監管綜述基本原則基于風險分級管理,不同級別不同要求所有軟件統一要求,不再區分軟件類型過程與結果相結合,質量體

28、系與確認并重關注重點質量體系軟件確認現成軟件網絡安全4.1 FDA指南與要求質量體系設計控制(820.30:1997)、人因工程(1996)采購控制(820.50)、糾正與預防措施(820.100)AAMI SW68:2001 = IEC 62304:2006通用指南醫療器械軟件通用指南(1998 & 1997 = 2005)醫療軟件確認基本原則(1997 = 2002)醫療器械使用現成軟件指南(1997 = 1999)內含現成軟件醫療器械網絡安全指南(2005)產品指南醫療影像管理器械指南(1983 = 2000)4.1 設計控制指南820.30(a)所有III類和II類醫療器械均應進行設計

29、控制部分I類醫療器械應進行設計控制 (i)軟件操控的醫療器械;(ii)820.30(g)設計確認應包含軟件確認和風險分析820.30(j)每個制造商應對每類產品建立和維護DHFDHF應包含或引用開發符合計劃和需求的必要記錄4.1 設計控制指南評審通過文檔化、全面的、系統的檢查來評估需求的適當性和設計符合需求的能力 ,并識別問題驗證通過檢查和提供客觀證據來認定規定需求已得到滿足確認通過檢查和提供客觀證據來認定特定預期用途的需求已得到滿足 過程確認:通過客觀證據確立一個過程能始終產出符合預期規格的結果或產品設計確認:通過客觀證據確立器械規格符合用戶需求和預期用途4.1 設計控制指南4.1 軟件確認

30、指南背景由于復雜性,軟件開發過程比硬件更應嚴格控制軟件工程比硬件工程需要更高級別的監管和控制適用范圍作為醫療器械組件、部件或附件的軟件本身是醫療器械的軟件用于醫療器械生產的軟件用于質量體系管理的軟件典型活動質量策劃、需求、設計、編碼、內部測試內部測試、用戶測試用戶測試、維護變更4.1 軟件確認指南文檔化的軟件需求規格是軟件確認的基線軟件測試的能力是有限的,卻是必須的軟件確認需要時間和精力,應當盡早準備軟件確認應在軟件生存周期過程中進行軟件確認需要通過計劃來定義和控制軟件確認是通過一系列工作程序來實現的軟件變更均應進行確認分析,并需回歸測試確認范圍取決于軟件的復雜度和風險水平確認應堅持“評審獨立

31、性”的原則制造商可以選擇確認活動,但應付最終責任4.1 軟件通用指南適用范圍固件或其他基于軟件控制的醫療器械獨立的應用軟件安裝在通用計算機的軟件專用的硬件/軟件醫療器械包含軟件或為獨立軟件的醫療器械附件適用類型預上市通告(510K),包括傳統、專用和簡易方式 預上市批準申請(PMA)研究器械豁免(IDE)人道主義器械豁免(HDE),包括修訂和補充4.1 軟件通用指南驗證通過提供客觀證據來認定某開發階段的輸出符合該階段所有輸入需求包括走查、靜態分析、動態分析、代碼檢查、文檔檢查、單元測試、集成測試確認通過提供客觀證據來認定軟件符合用戶需求和預期用途 僅限于設計確認,不包括過程確認軟件在真實或模擬

32、使用環境中正確運行的檢查,也包括質量策劃、驗證、可追溯性分析、配置管理等活動4.1 軟件通用指南可追溯性名稱:可追蹤性、可跟蹤性定義:在開發過程中兩個或多個產品之間能建立關聯的程度,特別是存在前后和主次關系的產品之間可追溯性分析追蹤(1)軟件需求規格與系統需求規格、(2)軟件設計規格與軟件需求規格、(3)源代碼與軟件設計規格之間的關系,分析已識別關系的正確性、一致性、完整性和準確性軟件確認指南要求進行系統需求、軟件需求、軟件設計、源代碼、軟件測試和風險分析之間的可追溯性分析可追溯性矩陣記錄兩個或多個產品之間關系的矩陣 4.1 軟件通用指南傷害嚴重傷害:定義與IEC 62304基本相同輕微傷害:

33、不是嚴重傷害嚴重傷害的任何傷害關注水平嚴重關注:失效或潛在設計缺陷可能直接或者通過錯誤或延遲信息間接造成患者或操作者死亡或嚴重傷害中等關注:失效或潛在設計缺陷可能直接或者通過錯誤或延遲的信息間接造成患者或操作者輕微傷害輕微關注:失效或潛在設計缺陷不太可能對患者或操作者造成任何傷害4.1 軟件通用指南內容要求內容要求輕微關注輕微關注中等關注中等關注嚴重關注嚴重關注關注水平關注水平陳述關注水平并描述確定理由軟件描述軟件描述概述軟件特征和軟件運行環境設備危害分析設備危害分析 列明已識別的硬件和軟件危害,包括嚴重度評估和減緩措施軟件需求規格軟件需求規格SRS功能需求概要完整的SRS文件體系結構圖體系結

34、構圖無需提交*詳述功能單元和軟件模塊,可以包含狀態圖和流程圖軟件設計規格軟件設計規格無需提交軟件設計規格文件可追溯性分析可追溯性分析 需求、規格、已識別危害及減緩、驗證與確認的可追溯性*4.1 軟件通用指南內容要求內容要求輕微關注輕微關注中等關注中等關注嚴重關注嚴重關注開發環境開發環境無需提交概述軟件生存周期開發計劃,包括配置管理和維護活動的概述概述軟件生存周期開發計劃,開發過程生成的控制文件列表,包括配置管理和維護計劃文件驗證與確認驗證與確認軟件功能測試計劃、通過準則和結果單元、集成和系統級VV活動描述。系統測試協議,包括通過準則和結果單元、集成和系統級VV活動描述。單元、集成和系統測試協議

35、,通過準則、測試報告、摘要和結果修訂歷史修訂歷史修訂歷史日志,包括發布的版本號和日期*未解決異常未解決異常無需提交剩余軟件異常列表,附注對安全性或有效性的影響說明,包括操作者使用和人為因素4.1 現成軟件指南定義通常可得到的且制造商未進行完整生存周期控制的軟件包含系統軟件、支持軟件、應用軟件要求輕微關注輕微關注中等關注中等關注嚴重關注嚴重關注危害分析基礎文檔危害消減危害分析基礎文檔危害消減剩余風險描述危害分析基礎文檔危害消減剩余風險描述專用文檔4.1 現成軟件指南基礎文檔現成軟件描述現成軟件計算機規格要求終端用戶正確使用保證措施現成軟件功能和用途現成軟件正常工作確認現成軟件可追溯性分析專用文檔

36、開發者所用的開發方法是適當且充分的驗證與確認的程序和結果是適當且充分的已建立后續維護與支持活動的保障機制4.2 歐盟軟件監管綜述指令93/42/EEC(醫療器械):操控醫療器械的軟件自動與醫療器械歸為一類90/385/EEC(有源植入):設計和制造必須特別注意程序和控制系統,包括軟件的正常運行98/79/EEC(體外診斷):含有軟件的醫療器械必須在設計上確保有效性、可靠性和可重復性07/47/EEC(修訂):軟件被明確定義為有源醫療器械,無論是獨立軟件還是軟件組件,軟件確認都是基本要求質量體系全面質量體系:ISO9001:94/ISO13485:96/EN46001:96生產質量體系:ISO9

37、002:94/ISO13488:96/EN46002:96產品質量體系:ISO9003:94/EN46003:964.2 歐盟軟件監管概述標準IEC 62304:2006IEC 60601-1-4:2000IEC 80001-1:2010IEC/TR 80002-1:2009IEC 62366:2007建議書(NB-MED/2.2/Rec4)本身是醫療器械或是醫療器械附件的軟件應標記“CE”,軟件組件無需標記“CE”推薦ISO/IEC 12119:1994(GB/T 17544-1998)4.3 FDA與歐盟比較 FDA軟件關注水平IEC 62304安全性級別輕微關注:失效或潛在設計缺陷不太可

38、能造成任何傷害A級:不可能對健康有傷害和損壞中等關注:失效或潛在設計缺陷可能直接或間接造成輕微傷害B級:可能有不嚴重的傷害嚴重關注:失效或潛在設計缺陷可能直接或間接造成死亡或嚴重傷害C級:可能死亡或嚴重傷害4.3 FDA與歐盟比較 FDA軟件通用指南 IEC 62304 關注水平4.3 軟件安全性級別 軟件描述5.2 軟件需求分析 設備危害分析7.1 促成危害處境的軟件分析軟件需求規格5.2 軟件需求分析 體系結構圖5.3 軟件體系結構設計4.3 FDA與歐盟比較 FDA軟件通用指南 IEC 62304 軟件設計規格5.4 軟件詳細設計可追溯性分析貫穿全程,包括5.1.1,5.2.6,5.7.

39、4,7.3.3,8.2.4開發環境5.1 軟件開發策劃 驗證與確認貫穿全程,包括5.2.6,5.3.6,5.4.4,5.5.5,5.6.3,5.6.7,5.7.5,7.3.1,9.7,9.8 修訂歷史8.3 配置狀態記錄未解決異常9.5 保持記錄4.3 FDA與歐盟比較 FDA軟件確認指南IEC 62304 5.2.1 質量策劃5.1 軟件開發策劃 5.2.2 需求5.2 軟件需求分析 5.2.3 設計 5.3 軟件體系結構設計5.4 軟件詳細設計 5.2.4 編碼 5.5 軟件單元實現和驗證5.2.5 內部測試5.5 軟件單元實現和驗證5.6 軟件集成和集成測試5.7 軟件系統測試5.2.6

40、 用戶測試5.7 軟件系統測試5.2.7 維護變更6 軟件維護過程4.3 FDA與歐盟比較相同之處質量管理、風險管理和軟件工程相結合測試不足以確保安全性,必須進行過程控制基于風險水平分級管理,不同級別不同要求軟件風險分級和內容要求相互對應基本一致差異之處體制差異:FDA上市申報,歐盟協調標準類型差異:FDA統一要求,歐盟區分要求4.4 我國軟件監管現狀業內認識不足,對軟件問題不重視法規相對滯后,與軟件發展不匹配質量體系缺失,相關標準難以落實檢測實力欠缺,對軟件評價不到位審評范圍有限,對軟件要求不全面處于起步階段,缺乏經驗需要摸索4.4 軟件審評工作思路國外經驗與我國國情相結合專家研討和企業調研

41、相結合逐步完善軟件申報資料要求制定軟件技術審評指導原則5 軟件申報資料要求原則范圍申報要求現成軟件FDA比較5.1 基本原則擴大軟件審評范圍,所有軟件均統一要求申報詳盡程度取決于安全性級別與復雜度申報內容均源自開發過程生成的軟件文檔通用要求,其他指導原則如未規定均適用5.1 適用范圍基本類型安裝形式醫療器械硬件關系核心功能獨立軟件處理型通用計算機處理數據型通用計算機通信處理軟件組件嵌入式醫療器械硬件操控操控(處理)控制型通用計算機操控操控(處理)適用范圍獨立軟件:本身是醫療器械或附件的軟件軟件組件:作為醫療器械、部件或附件組成部分的軟件專用軟件:其他有特定用途的軟件5.2 文檔內容基本信息產品

42、標識、安全性級別、結構功能、硬件關系、運行環境、適用范圍、禁忌癥、上市歷史實現過程開發綜述、風險管理、需求規格、生存周期、驗證與確認、缺陷管理、修訂歷史、臨床評價核心算法列明核心算法的名稱、原理、用途和類型5.2 申報要求內容內容A級(輕微)級(輕微)B級(中等)級(中等)C級(嚴重)級(嚴重)產品標識產品標識描述軟件名稱、型號、版本號、制造商和生產地址安全性級別安全性級別描述軟件安全性級別,并詳述安全性級別確定理由結構功能結構功能依據體系結構圖,描述軟件的組成模塊、模塊功能、模塊關系、外部接口和用戶界面硬件關系硬件關系依據物理拓撲圖,描述軟件、通用計算機和醫療器械硬件的連接關系運行環境運行環

43、境描述軟件運行所需的硬件配置、軟件環境和網絡條件適應范圍適應范圍描述軟件的適用范圍和適用人群禁忌癥禁忌癥描述軟件的禁忌癥和不適用人群上市歷史上市歷史描述軟件在中國、原產國等主要國家地區的上市時間、版本號和管理類別5.2 申報要求內容內容A級(輕微)級(輕微)B級(中等)級(中等)C級(嚴重)級(嚴重)開發綜述開發綜述描述開發語言、工具、方法、模型、人員、時間、工作量、代碼行數和控制文檔數風險管理風險管理提供風險管理資料需求規格需求規格需求規格的功能、性能要求需求規格全文,包含硬件、功能、性能、輸入輸出、接口界面、警示信息、保密安全、數據與數據庫、文檔和法規的要求生存周期生存周期開發生存周期計劃

44、摘要開發生存周期計劃、配置管理計劃和維護計劃的摘要開發生存周期計劃、配置管理計劃和維護計劃的摘要,列明各階段輸入輸出文檔驗證與驗證與確認確認系統測試和用戶測試的計劃與報告摘要概述開發各階段的驗證活動,系統測試和用戶測試的計劃與報告摘要概述開發各階段的驗證活動,系統測試和用戶測試的計劃與報告5.2 申報要求內容內容A級(輕微)級(輕微)B級(中等)級(中等)C級(嚴重)級(嚴重)缺陷管理缺陷管理描述缺陷總數和剩余缺陷數描述缺陷總數和剩余缺陷數,列明剩余缺陷的嚴重度、處理措施和處理時間修訂歷史修訂歷史描述版本號命名規則,列明本次修訂的版本號、類型和日期描述版本號命名規則,列明本次修訂的版本號、類型

45、和日期,詳述本版與前版的變更內容描述版本號命名規則,列明本次和以往修訂的版本號、類型和日期,詳述本版與前版的變更內容臨床評價臨床評價提供臨床評價資料核心算法核心算法公認成熟算法列明名稱,全新算法列明名稱、原理和用途公認成熟算法列明名稱、原理和用途,全新算法除列明名稱、原理和用途外,還應提供安全性與有效性的驗證資料5.2.1 產品標識與安全性級別產品標識軟件的名稱、型號、版本號制造商的名稱、生產地址安全性級別說明軟件安全性級別(A、B、C)詳述安全性級別確定理由包括直接影響和間接影響與管理類別沒有對應關系5.2.1 結構功能體系結構圖圖示軟件組成模塊之間、組成模塊與外部接口的關系,應包含足夠且必

46、要的注釋功能描述依據體系結構圖描述軟件的組成模塊、模塊功能、模塊關系、模塊與外部接口關系、用戶界面內容與相互關系組成模塊如為選裝應注明,如有版本號也應注明外部接口必備軟件:軟件運行所必需的應用軟件選配軟件:與軟件配套使用的應用軟件硬件:通用計算機或醫療器械硬件現成軟件如有,列明名稱、版本號、制造商和類型5.2.1 結構功能5.2.1 硬件關系物理拓撲圖圖示軟件、通用計算機、醫療器械硬件之間的物理連接關系,應包含足夠且必要的注釋關系描述獨立軟件:說明通用計算機的類型和功能,如需與醫療器械硬件聯合使用應說明名稱、型號、規格和制造商軟件組件:說明醫療器械硬件的名稱、型號和規格,如需與通用計算機聯合使

47、用應說明類型和功能5.2.1 硬件關系5.2.1 運行環境安裝于通用計算機的軟件硬件配置CPU、內存、硬盤、顯示器、顯卡和IO設備軟件環境系統軟件、支持軟件、必備軟件、選配軟件和殺毒軟件名稱、版本號和補丁號(如有)網絡條件網卡、類型(局域網、廣域網)和架構(CS、BS)CS架構:服務器端、客戶端BS架構:服務器端、客戶端、瀏覽器5.2.1 運行環境安裝于醫療器械硬件的軟件硬件配置處理器、存儲器、外設器件、IO設備軟件環境系統軟件、支持軟件、必備軟件、 選配軟件和殺毒軟件名稱、版本號和補丁號(如有)網絡條件網絡接口(如有)5.2.1 適用范圍與禁忌癥適用范圍獨立軟件:軟件的適用范圍和適用人群軟件

48、組件:醫療器械產品的適用范圍和適用人群禁忌癥獨立軟件:軟件的禁忌癥和不適用人群軟件組件:醫療器械產品的禁忌癥和不適用人群5.2.1 上市歷史中國情況實質首次注冊:依據醫療器械分類目錄及后續分類界定通知說明管理類別實質重新注冊:列明在中國所有上市產品的版本號和產品注冊證號國外情況列明軟件在原產國、美國、日本和歐盟首次上市的時間、版本號和管理類別,無需提供各國上市批書 軟件組件描述醫療器械產品的上市歷史5.2.2 開發綜述開發技術語言:C、C+、C#、Java、XML工具:支持軟件(含開源軟件)和應用軟件,描述開發工具、管理工具、產品工具的名稱、版本號和制造商,其中產品工具還應簡述功能和用途方法:

49、面向對象、基于構件、虛擬機、CS架構生存周期模型:瀑布、增量、漸進、V模型度量數據開發人員數量、開發時間、工作量(人月數)代碼行總數、控制文檔總數5.2.2 風險管理風險管理報告名稱、嚴重度、原因、減緩措施和結果現成軟件如有,所有級別軟件均應進行風險管理實施情況可另附說明文檔5.2.2 需求規格A級軟件需求規格功能和性能的要求B級和C級軟件需求規格全文包含硬件、功能、性能、輸入輸出、接口界面、警示信息、保密安全、數據與數據庫、文檔和法規的要求現成軟件如有,B級和C級軟件應要求需求規格可另附說明文檔5.2.2 生存周期A級軟件開發生存周期計劃摘要描述開發策劃、需求分析、設計(體系結構設計、詳細設

50、計)、編碼和測試(單元、集成、系統、用戶)各階段的任務、內容和結果B級在A級基礎上提供配置管理計劃和維護計劃摘要,描述相應過程的工具、流程和要求5.2.2 生存周期C級在B級基礎上列明各階段輸入輸出控制文檔現成軟件如有,B級和C級的軟件應在開發生存周期計劃、配置管理計劃和維護計劃中說明相應要求實施情況可另附說明文檔YY/T 0664-2008或YY/T 0708-2009核查表5.2.2 驗證與確認驗證通過提供客觀證據來認定某開發階段的輸出符合該階段所有輸入需求包括質量管理計劃、正式技術評審、可追溯性分析、白盒測試(靜態和動態)、黑盒測試、回歸測試確認通過提供客觀證據來認定軟件符合用戶需求和預

51、期用途 用戶測試(真實或模擬使用環境測試),也包括質量管理、風險管理和軟件工程等活動5.2.2 驗證與確認A級系統測試、用戶測試的測試計劃和報告摘要(條件、工具、方法、通過準則和結果)B級系統測試、用戶測試的測試計劃和報告摘要概要介紹開發各階段的驗證與確認活動(工具、方法、內容和結果),其中單元測試應描述覆蓋率要求,集成測試應描述集成策略5.2.2 驗證與確認C級系統測試、用戶測試的測試計劃和報告全文概要介紹開發各階段的驗證與確認活動(工具、方法、內容和結果),其中單元測試應描述覆蓋率要求,集成測試應描述集成策略現成軟件如有,所有級別軟件均應進行驗證與確認系統測試和用戶測試可另附說明文檔5.2.2 缺陷管理A級描述缺陷管理的工具、流程和要求,列明測試階段發現的缺陷總數和剩余缺陷數B級和C級在A級基礎上列明剩余缺陷

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論