點擊這里給我發消息

GB/T 42984.1-2023《健康軟件 第1部分:產品安全的通用要求》

魯械咨詢
2024-05-05

健康軟件 1 部分:產品安全的通用要求

1 范圍

1.1 目的

本文件適用于健康軟件產品的安全和信息安全,旨在在通用計算平臺上運行,并且無需專用硬件即可投放市場,主要關注制造商的要求。

1.2 應用領域

本文件涵蓋整個生命周期,包括健康軟件產品的設計、開發、安裝,確認,維護和處置。

在每個參考標準中,術語“醫療器械”或“醫療器械軟件”在適當時由術語“健康軟件”或“健康軟件產品”代替。

如果使用術語“患者”,無論是在本文件中還是在參考標準中,它指的是使用健康軟件對其健康有益的人。

本文件不適用于預期作為健康用途而設計的特定硬件的一部分的健康軟件。具體而言,本文件不適用于:

a) GB9706系列涵蓋的醫用電氣設備或系統;

b) GB4793(所有部分)涵蓋的體外診斷設備;

c) GB16174(所有部分)涵蓋的植人式設備。

:本文件也適用于旨在與移動計算平臺結合使用的健康軟件產品(例如醫療應用程序,健康應用程序)。

1.3 符合性

通過檢查本文件要求的所有文檔來確定是否符合本文件。

制造商對合規性進行評估并記錄。如果健康軟件產品符合監管要求,則可能會進行外部評估。

如果本文件規范性地引用了以安全或安全為重點的其他標準的部分或條款,制造商可以使用替代方法證明符合本文件的要求。如果這些替代方法的過程結果(包括可追溯性明顯等同并且剩余風險仍然可接受,則可以使用這些替代方法。

2 規范性引用文件

下列文件中的內容通過文中的規范性引用而構成本文件必不可少的條款。其中,注日期的引用文件,僅該日期對應的版本適用于本文件;不注日期的引用文件,其最新版本包括所有的修改單適用于本文件。

YY/T0664-2020醫療器械軟件軟件生存周期過程(IEC62304:2015,MOD)

3 術語和定義

下列術語和定義適用于本文件。


3.1

隨附文件accompanying document

包含健康軟件的文檔,其中包含負責任的組織或用戶的信息,特別是有關安全和信息安全的信息。

[來源:GB 9706.1-2020,3.4,有修改”]

3.2

異常anomaly

任何基于要求規范,設計文件,標準等偏離預期的條件或某人的觀念或經歷。

:異??稍诮】弟浖蜻m用文件的審查,測試,分析,匯編或使用過程中找到,但不限于此。

[來源:基于IEEE 1044:1993,3.1]

3.3

傷害harm

對人體健康的損傷或損害,或對于財產或環境的損害。

[來源:ISO / IEC指南51:2014,3.1]

3.4

危險(源)hazard

可能導致傷害的潛在根源。

:傷害的潛在來源包括違反安全和降低有效性。

[來源:ISO / IEC指南51:2014,3.2,修改 - 增加了注1]

3.5

危險情況hazardous situation

人,財產或環境暴露于一個或多個危害之中的境遇。

[來源:ISO / IEC指南51:2014,3.4]

3.6

*健康軟件 health software

旨在專門用于管理,維持或改善個人健康或提供護理的軟件。注1:健康軟件完全包括被視為醫療器械的軟件(參見A.1中的基本原理)。注2:本標準的范圍是指旨在在通用計算平臺上運行的健康軟件的子集。

3.7

健康軟件產品health software product

健康軟件和隨附文件的組合。

3.8

預期用途intended use

預期目的intended purpose

按照制造商提供的規范、說明書和資料,對產品、過程和服務的預期使用。

[來源:ISO 14971:2007,2.5]

3.9

IT網絡 IT-network

信息技術網information technology network

由通信節點和傳輸鏈路組成的一個或多個系統,在兩個或多個指定的通信節點之間提供物理連接或無線傳輸。

注:本文件中IT網絡的范圍是由負責機構根據IT網絡中的健康軟件的位置和IT網絡的確定用途來確定的。它能包括在設計上不打算用于醫療保健設置的IT基礎設施、家庭健康或普通計算組件或系統。參見7.2.3.2。

[來源:IEC 61907:2009,3.1.1,修改 - 該定義已經改寫,并增加了注。]

3.10

制造商manufacturer

負責設計、開發、包裝、或標記健康軟件產品或在健康軟件產品投入市場之前或使用之前對其進行編譯的自然人或法人,無論這些操作是否該自然人或法人進行還是某第三方代表自然人或法人進行。

1:關于標簽的定義,參見GB/T 42061-2022,3.6,3.8。

2“開發人員”或“開發組織”是健康信息技術背景下常用的術語,而不是制造商。

3.11

剩余風險residual risk

采取風險控制措施后余下的風險。

[來源:ISO 14971:2007,2.15]

3.12

責任方responsible organization

對健康軟件產品的適當運行和使用負有責任的實體。

:舉例來說,負有責任的實體可以是一家醫院、某個醫療服務提供者或者某個遠程醫療機構。

[來源:GB9706.1-2020,3.101,有修改]

3.13

風險risk

傷害發生的概率和該傷害嚴重度的組合。

:發生的概率包括暴露于危害處境以及避免或限制損害的可能性。

[來源:ISO/IEC Guide 63:2019,3.10,有修改]

3.14

風險分析risk analysis

系統地運用現有信息確定危險(源)和估計風險的過程。

[來源:ISO/IEC Guide 63:2019,3.11]

3.15

風險評定risk assessment


包括風險分析和風險評價的全過程。

[來源:ISO/IEC Guide 63:2019,3.11]

3.16

風險控制risk control

做出決策并實施措施,以便降低風險或把風險維持在規定水平的過程。

[來源:ISO/IEC Guide 63:2019,2.12]

3.17

風險評價risk evaluation

將估計的風險和給定的風險準則進行比較,以決定風險可接受性的過程

[來源:ISO/IEC Guide 63:2019,2.14]

3.18

風險管理risk management

用以風險分析、評價、控制和監視工作的管理方針、程序及其實踐的系統運用。

[來源:ISO/IEC Guide 63:2019,2.15]

3.19

安全safety

免除了不可接受的風險的狀態

[來源:ISO/IEC Guide 63:2019,2.16]

3.20

信息安全security

保護信息和數據,讓未經授權的人員或系統無法讀取或修改它們,并且不會拒絕授權人員或系統訪問它們。

[來源:ISO 12207:2017,3.1.49]

3.21

軟件維護software maintenance

出于下列一個或多個原因,對發布后用于預期用途的健康軟件產品進行修改:

a) 糾正,如修復錯誤;

b) 適應性,如適應新的硬件或軟件平臺;

c) 完善,如執行新要求;

d) 預防,如讓產品易于維護。

參見 ISO/IEC 14764:2006

3.22

用戶user

與健康軟件產品交互的人員。

注:通常情況下,用戶不視為責任方,但消費類的健康軟件產品除外,列如,個人健康應用,或非專業人員使用的產品。


3.23

確認validation

通過提供客觀證據對特定的預期用途或應用要求已得到滿足的認定。

1:確認所需的客觀證據是試驗結果或其他形式的確定結果,如變換方法進行計算或文件評審。2“已確認”一詞用于表明相應的狀態。

3:確認的使用條件可以是真實的,也可以是模擬的。

[來源:ISO 9000:2015,3.8.13]

3.24

驗證verification

通過提供客觀證據對規定要求已得到滿足的認定。

1驗證所需的客觀證據可以是檢驗結果或其他形式的確定結果,如變換方法進行計算或文件評審。

2:為驗證所進行的活動有時被稱為鑒定過程;3“已驗證”一詞用于表明相應的狀態。

[來源:ISO/IEC Guide 63:2019,3.19]

4 *健康軟件產品需求

4.1 通用要求和初始風險評定

制造商應確定并記錄:

a) 健康軟件產品的預期用途,包括預期的用戶概況和預期的操作環境;

b) 健康軟件產品的安全和信息安全相關的特征,危險的識別和相關風險的估計。如適用,包括可以配置和或)支持與其他產品接口的健康軟件產品的情況;

c) 對不可接受的預估風險采取風險控制措施的必要性。

1:根據 ISO 14971,4.1 條不需要正式和完整的風險管理。但,執行該過程的初始步驟卻視為是良好的實踐。

2:風險控制措施可以是硬件、獨立軟件系統,醫療護理程序或其他方式。

3:有關安全漏洞的信息來源包括官方的公開報告,以及供應商的出版物,例如操作系統和第三方軟件。

4.2 健康軟件產品使用要求

制造商應確定并記錄:

a) 針對預期用途的要求;

b) 接口要求,包括適用的用戶接口要求;

1:與作為健康軟件產品系統需求的一部分用戶接口規范相比,用戶接口要求不描述技術(實現)要求,他們描述了技術要求的目的。

示例:在一個緊急裝置中,顯示信息可在 3 米的距離正常讀取。

2:IEC 62366-1:2015 提供了建立用戶接口要求的過程。

c) 對使用相同硬件資源的其他軟件的非預期影響的免疫或易受影響的要求;

d) 涉及授權使用、個人身份驗證、健康數據完整性和真實性以及防止惡意意圖等領域的隱私和安全要求;

3:有關安全方面的更多信息,參見 7.2.3.1 和IEC TR 80001-2-2(安全功能列表)

e) 附件的要求,如使用說明7.2.2);

f) 支持要求:


1) 對以前版本的更新,包括保持數據完整性和與以前版本的兼容性;

2) 更新后回到以前的版本;

3) 及時安全補丁和更新;

4) 確保安裝完整性的軟件分發機制;

5) 數據的解除、永久刪除、傳輸和/或保留。

g) 來自適用法規的要求,包括受保護信息的規則。

4:在某些情況下,數據保護法規2016 年修訂的歐洲數據保護指令95/46/EC)要求公民保持對個人數據的控制,例如刪除或導出數據。2018 5 25 日的歐洲《一般數據保護條例2016/679)》將取代歐洲數據保護指令95/46/EC。

4.3 健康軟件產品使用要求的驗證

制造商應驗證健康軟件產品的使用要求:

a) 定義并記錄作為輸入的系統要求;

b) 使制造商能滿足規定的使用要求;應記錄驗證的結果。

4.4 更新健康軟產品的使用要求

適當時,制造商應確保健康軟件產品使用需求的更新,例如:作為對健康軟件產品使用需求驗證(見

4.3)或確認的結果。

4.5 系統需求

制造商應制定并記錄健康軟件產品的系統要求。這些要求應包括預期用途的功能,并在適用時包括:

a) 互操作性;

b) 本地化和語言支持;

c) 基于4.1 的初始風險評定,在系統層面,對健康軟件產品實施的風險控制措施;

d) 用戶接口規范;

e) 健康軟件產品的軟件和硬件平臺要求在預期負載下按預期運行,并具有所需的性能水平;

f) 允許在正常使用過程中檢測、識別、記錄、計時和采取行動的信息安全危害的特征;

g) 能夠軟件產品的基本功能,即使軟件安全受到損害;

h) 由經過身份驗證的特權用戶保留和恢復產品配置的方法。   健康軟件產品系統要求應滿足健康軟件產品使用要求4.2)。

1:網址http://www.himss.org/library/interoperability-standards/what-is-interoperability 提供了互操作性的信息來源。

2:用戶接口的技術要求可能包括顯示顏色、字體大小、或者控件的位置。

3:典型的軟件平臺包括但不限于:操作系統、設備驅動程序、軟件庫和其他應用程序。

4:IEC 62304:2006,5.2.1 的軟件系統需求與健康軟件產品系統需求之間不一定存在差異。

4.6 系統需求的驗證

制造商應驗證系統要求:

a) 互不矛盾;

b) 用避免歧義的術語表達;

c) 使用能夠建立試驗標準和執行測試以確定已滿足試驗標準的術語表示;和

d) 能唯一識別。


應記錄驗證結果。

4.7 更新健康軟件產品的系統要求

制造商應確保健康軟件產品的系統需求,在適當的時候更新,如,由于修改了健康軟件產品使用要求,或系統需求驗證的原因,或由于應用IEC 62304:20065.2條和IEC 62304:2006 / AMD1:2015(件要求分析而進行更新。

5 *健康軟件-軟件生命周期過程

4.5中確立的健康軟件產品的系統需求,應作為健康軟件產品生命周期過程的首要設計輸入。

除本文件的其他要求外,IEC 62304:2006的4.2,4.3,第5章,第6章,第7章,第8章和第9章和IEC 62304/AMD1:2015的要求應適用于健康軟件。

IEC 62304:2006和IEC 62304/AMD1:2015規范性地引用了ISO 14971:2007。制造商可能無法遵循ISO 14971:2007中為健康軟件的每個組成部分確定的所有過程步驟這點已得到證實,例如專有組件、非醫療護理的子系統和傳統軟件。在這種情況下,制造商應考慮剩余風險,對不能接受的風險進行風險控制。

6 *健康軟件產品確認

6.1 確認計劃

制造商應制定一份確認計劃,解決4.2中規定的所有健康軟件產品使用要求。在確認計劃里,制造商應:

a) 確定確認范圍和相應的確認活動;

b) 確定可能限制確認活動可行性的約束;

c) 選擇合適的確認方法,輸入信息和相關的驗收標準,以便確認成功;

d) 確定支持確認所需的支持系統或服務,如操作環境,包括硬件和軟件平臺;

e) 指定確認人員所需的資格,如果需要培訓,則應在開始確認之前完成培訓;

f) 應保證確認團隊與設計團隊的適當獨立性。

1:約束條件包括:技術可行性,成本,時間,是否存在確認執行者或合格人員,合同約束,任務的關鍵性等。2:確認方法包括:檢驗、分析、類比/類似、論證、模擬、同行評審、試驗或認證。相關信息:參考標準和其他

出版物,如兼容性標準,監管機構指導文件和臨床文獻。

6.2 實施確認

一旦出現以下情況,制造商應確定確認準備就緒:

a) 確認計劃已制定;

b) 確認團隊已經具備了相應的資質人員;

c) 在適當情況下,已完成第5 章所要求的健康軟件產品經確認部分的開發生命周期階段。

確認團隊應根據6.1的確認計劃在預期的運營環境中執行確認活動。 如果認為有必要偏離確認計劃,則應在確認報告中證明其合理性。

當在確認過程中發現健康軟件產品存在異常時,應根據IEC 62304/AMD1:2015第9章通過問題解決流程處理這些問題。如果此問題解決流程導致健康軟件產品的修改,則應根據修改的程度,重復執行確認的相應部分。


6.3 確認報告

確認團隊應根據確認情況制定健康軟件產品的確認報告。確認報告應提供以下證據:

a) 確認結果可追溯至健康軟件使用要求,作為輸入;

b) 健康軟件產品符合4.2 中規定的使用要求;

c) 健康軟件產品的剩余風險仍然可以接受。

確認報告應記錄確認條件和確認活動的結果。如果在確認期間,在健康軟件產品中發現了異常,則這些異常應列在確認報告中。

確認報告應列出確認團隊的成員姓名,所屬機構,職能)。

確認報告應包括確認結果的摘要,以及根據使用需求確認健康軟件產品是否適用于預期用途的結論。

7 健康軟件產品標識和隨附文件

7.1 *標識

健康軟件產品應標識制造商的名稱或商標,產品名稱或型號參考,以及唯一的版本標識符,例如修訂的級別,發布日期。

1:在一些監管地區,器械唯一標識(UDI)是強制性的。

用戶在使用健康軟件時,應能夠識別健康軟件產品。

2:在開始頁面或登錄屏幕中包含標識被認為是一種良好做法。

7.2 隨附文件

7.2.1 概述

制造商應為健康軟件提供隨附文檔,以允許用戶和責任方組織按預期實施和使用健康軟件產品。

隨附文件應包括:

a) 制造商的名稱和聯系信息,包括網站;

b) 健康軟件產品標識7.1);

c) 健康軟件產品的版本標識符,例如修訂版本或發布日期,用于識別其適用的健康軟件產品;

d) 隨附文件的版本標識符,如修訂級別或發布/發布日期;

e)使用說明7.2.2);

f)技術說明7.2.3)。

隨附文件可包括軟件發布說明和典型安裝環境的說明。

隨附文件應規定預期用戶或責任單位所需的任何特殊技能、培訓和知識,對可使用健康軟件產品的地點或環境的任何限制,以及(如適用)任何系統接口、軟件平臺和工具以及硬件要求或限制。

隨附文件的提供應符合擬提供文件的人的教育、培訓和任何特殊需要的水平。

注:以電子形式提供隨附文件可以提高可用性。當以電子方式提供時,監管機構可以指定隨附文件或或其部分的特定格式。

7.2.2 使用說明

7.2.2.1 概述


使用說明應記錄正確操作健康軟件產品所需的所有內容,包括適當的安裝說明。如適用,使用說明應規定對使用健康軟件產品的IT網絡的限制(7.2.3.2)。

注:使用說明適用于用戶和責任組織,僅包含對用戶或責任方有用的信息。其他細節可包含在技術說明中。見7.2.3。

7.2.2.2 健康軟件描述

使用說明應包括:

a) 制造商規定的健康軟件產品的預期用途;

b) 健康軟件產品的簡介,包括健康軟件產品的基本功能;

c) 使用健康軟件的任何操作安全性選項;

d) 使用健康軟件產品的任何已知的技術問題、限制、免責聲明或禁忌癥。

7.2.2.3 安全和/或信息安全的警告和注意事項

使用說明書應列出與使用健康軟件產品有關的安全和(或信息安全的所有警告和注意事項,并在不能自我解釋時對其進行說明或擴充。

安全和(或信息安全的一般警告和注意事項宜放在使用說明書的特定標識部分。對特定的指令或行動使用安全或信息安全的警告或通知時,應在它適用的指令之前進行。

7.2.2.4 安裝

使用說明書應包含:

a) 聲明是由用戶按照,還是應由制造商完成或在制造商協助下安裝,或由授權人員完成;

b) 預期執行健康軟件的軟件平臺和硬件平臺的系統需求;

c) 在安裝時設置健康軟件的操作安全選項;

d) 對其他應用程序的任何關鍵依賴性;

e) 配置要求;

f) 系統接口要求(必需和可選);

g) 支持的軟件平臺的細節;和

h) 安裝說明或參考安裝說明的位置。

7.2.2.5 啟動程序

使用說明書應包含用戶使用健康軟件的必要信息。

7.2.2.6 關閉程序

使用說明書應包含用戶關閉健康軟件的操作的必要信息。

7.2.2.7 操作說明

使用說明書應包含操作健康軟件所需的所有信息。這應包括對控制,顯示和信號功能以及操作順序的說明。

使用說明書應說明數字,符號,警告聲明和縮寫的含義。

7.2.2.8 消息

使用說明應列出生成的所有系統消息,錯誤消息和故障消息,除非這些消息是不言自明的。

注:可以分組識別這些消息。


該列表應包括對消息的解釋,包括重要原因,以及用戶可能采取的行動如果有的話,以解決消息所指示的情況。

7.2.2.9 健康軟件停止使用和處置

使用說明應包含用戶或責任方安全停止使用和處置健康軟件所需的所有信息。這應酌情包括保護與安全性和隱私有關的個人和健康數據。

注:監管機構可以在處理個人和健康相關數據時指定要求。

7.2.2.10 技術說明參考

使用說明書應包含技術說明(7.2.3)或可以找到技術說明的參考。

7.2.3 技術說明

7.2.3.1 概述

技術說明書應提供安全可靠的操作、運輸和存儲所必需的所有數據,以及安裝和準備使用健康軟件所需的措施或條件。應包括:

a) 用于執行健康軟件的軟件和硬件平臺的系統需求;

b) 支持的軟件平臺的細節;

c) 運輸和儲存含有健康軟件的媒體的允許環境條件;

d) 健康軟件的所有特征,包括顯示值的范圍,準確度和精確度,或者可以找到它們的指示;

e) 任何特殊安裝要求或限制;

f) 任何維護要求,例如要檢查和可能清除的日志文件,數據庫維護和存儲介質的更改;

g) 可以在健康軟件產品中配置的任何技術安全選項,以及可負責組織可用的選項。此類安全可能包括:

1) 配置選項,例如最少的網絡端口列表和所需的計算機服務;

2) 軟件選項,例如打開加密設置,更改默認登錄憑據;

3) 操作選項,例如審計和日志記錄管理設置。

h) 當檢測到未能保持信息安全時,應對軟件所做的操作進行描述。描述應包括對患者護理,數據或臨床工作流程的任何影響。

注:由于健康軟件通常運行在多個硬件和軟件平臺,在某些情況下,對典型特征和約束實施的成功描述或記錄,可以提供有效的幫助。

制造商應在用戶和(或)負責組織的技術說明中提供有關如何處理硬件和軟件平臺變更的說明(例

如,使用防病毒/防火墻軟件,系統庫,固件和其他軟件的補丁/更新,以及如何選擇適當的平臺設置來支持安全目標和安全功能。

7.2.3.2 *旨在用于IT 網絡的健康軟件

IT網絡的范圍可能包括未明確打算用于醫療保健環境的支持性IT基礎架構或系統。見3.9。

如果健康軟件旨在用于不受健康軟件制造商控制的IT網絡,則制造商應作為技術說明的一部分提供此用途所需的說明,包括但不限于以下:

a) 健康軟件實現其目的所需的IT 網絡的特征和配置;

b) 健康軟件實現其目的所需的IT 網絡技術規范,包括安全規范和防惡意軟件或類似軟件;

c) 使用IT 網絡在健康軟件與其他軟件或系統之間的預期信息流。

制造商應在技術說明中包括由于IT網絡未能在使用該IT網絡時提供健康軟件所需的特性和服務而導致的危害處境列表。


在技術說明中,制造商應通知責任方:

a) IT 網絡上執行健康軟件可能會導致以前身份不明的患者,用戶或第三方的風險;

b) 建議負責任的組織識別,分析,評估和控制這些風險;

c) IT 網絡的變更可能會引入新的風險并需要額外的分析;并且

d) IT 網絡的變更包括:

1) IT 網絡配置的變化;

2) IT 網絡添加項目硬件和軟件平臺或軟件應用程序);

3) IIT 網絡中刪除項目;

4) 更新IT 網絡上的硬件和或)軟件平臺或軟件應用程序;和

5) 升級IT 網絡上的硬件和或)軟件平臺或軟件應用程序。

注:IEC 80001-1:2010提供了健康軟件制造商,其他信息技術提供商和負責組織的要求,以解決IT網絡修改的風險。

8 健康軟件產品的上市后活動

8.1 概述

根據第1條,本標準涵蓋了健康軟件的整個生命周期。在其生命周期內,健康軟件可能會進行軟件維護,最終會退役和處置。第4.2條規定了在使產品可供使用之前實施和確認的使用需求;這些要求包括退役和處置健康軟件產品。當本標準用于合規目的時,僅適用與產品設計和開發相關的上市后方面。

8.2 軟件維護

如果制造商確定軟件維護是相關或必要的,例如,由于檢測到的錯誤可能會對安全和信息安全產生影響,制造商應根據本文件制定健康軟件產品的修改(見條款5)

1:維護還可以包括隨機文件的變更,例如:關于健康軟件的運行平臺。

2:由于檢測到的錯誤會影響安全和(或)信息安全,因此在軟件維護的情況下可以制定法規要求。

8.3 重新確認

制造商應確??紤]到修改的程度,重新確認受軟件維護影響的健康軟件產品部分的有效性。制造商應相應更新確認計劃。

制造商應確保修改后的健康軟件版本適用于聲稱支持的任何硬件和軟件平臺。

8.4 健康軟件產品的上市后溝通

制造商應向用戶和負責任組織通知制造商已經了解的健康軟件產品的安全漏洞以及影響健康軟件產品使用的法規要求變更。

對于軟件維護,制造商應向用戶和負責組織提供有關健康軟件產品更新版本的信息,并在適當情況下提供以下信息:

a) 新功能;

b) 糾正的錯誤;

c) 對修改后的軟件的安全和(或)信息安全的任何影響;

d) 更新健康標識7.1);

e) 隨附文件的更新7.2).


用戶或負責任的組織是否安裝修改版的健康軟件的決定應基于修改的安全和(或信息安全影響。如果修改后的健康軟件產品對健康軟件的安全和信息安全產生積極影響,制造商可以建議用戶和負責組織在短期內更換其版本。

8.5 健康軟件產品的停止使用和處置

用戶或責任組織應能夠在其使用壽命結束時安全地停用和處置健康軟件產品,包括在適當情況下保護與安全和隱私相關的個人和健康相關數據。健康軟件應提供符合4.2中規定的適用使用需求的此功能。


A

(資料性附錄)   本文件要求的理由說明


A.1 概述

健康軟件由其制造商專門用于健康目的。這包括旨在幫助診斷,治療或監測患者,或幫助補償或減輕疾病,傷害或殘疾的應用。

在本文件的開發的早期階段,使用以下術語來指示軟件作為硬件醫療器械“醫療器械軟件”和作為醫療器械本身的軟件軟件醫療器械的一部分。各自的定義是;醫療器械軟件:專門用于嵌入到物理醫療器械中的軟件,以及軟件醫療器械:本身就是醫療器械的軟件。這兩個子類別的組合被定義為:醫療器械軟件:旨在專門用于嵌入到物理醫療器械或旨在作為軟件醫療器械的軟件。

健康軟件,如3.6中所定義:“旨在專門用于管理,維持或改善個人健康,或提供護理”,完全包“醫療軟件”,但更廣泛。醫療軟件與術語醫療器械密切相關,醫療器械是一個不同管轄區域的監管定義。就本文件而言,健康軟件一詞被認為更合適。在更廣泛的范圍內,本標準允許對所有與健康相關的軟件產品的安全、信息安全和性能采取共同的方法,無論它們是否作為醫療器械進行管理。

國際醫療器械監管機構論壇IMDRF已發布文件SaMD WG / N10FINAL“作為醫療器械的軟件SaMD關鍵定義”。如果健康軟件具有醫療用途且不打算運行專用硬件,則它與作為醫療器械的軟件相同。

請注意,本文件僅針對健康軟件產品提供要求,即作為獨立產品提供的健康軟件。旨在在專用硬件上運行的健康軟件有時也稱為“嵌入式”軟件被認為是物理設備的一部分,而不是產品本身。另見A.2。

健康軟件包括處理健康,健康管理和醫療保健資源管理的應用程序。表A.1給出了本標準涉及的軟件產品示例。 ISO/TR 17791介紹了健康軟件標準的概況,識別出按現有標準覆蓋健康軟件的存在的差距。對于獨立的健康應用程序,引用安全,信息安全的標準似乎不存在。本標準旨在填補這一空白。

每個司法管轄區都必須自行決定哪些健康軟件產品被認為受其醫療器械法規的約束,或者當不作為醫療器械管理時,是否適用其他法規。鼓勵有意在已采納本標準的管轄區內投放健康軟件領域內的軟件產品的制造商,調查哪些監管制度適用(如果有的話)。

A.1本文準范示例

在適用范圍

不在適用范圍

- 健康試用的純軟件產品

- 在不使用特定傳感器或探測器的設備上運行的移動應用

- 實驗室信息軟件

- 放射學信息軟件

- 健身中心的個人軟件

- 計算機輔助診斷軟件

- 分析醫學圖像的軟件

- 臨床決策支持軟件,用于輔助個人的診斷,治療和健康管理

- 具有反饋的個人減壓軟件

- 用于重新確認目的的培訓計劃軟件

- 用于刺激阿爾茨海默病患者活動的軟件

- 電子健康記錄系統,電子病歷系統

- 醫院信息系統

- 不具備可執行性的軟件,例如參考值集,。

- 不解決個人健康問題的軟件

- 醫院賬單軟件

- 醫院設備維護調度軟件

- 流行病學研究軟件

- 護士訓練軟件

- 醫學專業人員的自學軟件

- 療養院的電子日志

在范圍之外也還是軟件,或是其更新,旨在驅動(部分

- IEC 60601 / IEC 80601 涵蓋的醫療電氣設備或系統(所有部件)

- IEC 61010 涵蓋的體外診斷設備(所有部件)

- ISO 14708 涵蓋的可植入設備(所有部件)


- 由外部組織托管的提供服務的健康軟件


a 智能手機或平板電腦上常見的相機或麥克風或其他功能不被視為特定的傳感器或檢測器。

A.2 健康軟件產品的要求

請注意,本文件僅提供作為獨立產品提供的健康軟件的要求。A.1顯示了健康軟件的應用領域及其相關標準的相應覆蓋范圍,即本文件和IEC 62304:2006以及IEC 62304:2006 / AMD1:2015。

A.1健康標準范圍

健康軟件通常在非常不同的平臺上運行,包括硬件和軟件。例如:固定或移動物理設備,或虛擬機,本地或網絡或作為“云” - 通過互聯網托管的服務。這些平臺往往超出制造商的影響和控制。因此, 本文件還打算領導制造商和負責任的組織注意必要的考慮因素,任務和文件,以充分解決可能由于使用的多樣性和頻繁變化的平臺而導致的危害。

旨在在專用硬件上運行的健康軟件應被視為物理設備的一部分,有時也稱為“嵌入式”軟件。這種軟件本身并不是一種產品。這對于作為醫療設備被監管的產品中的軟件和作為醫療設備不受監管的特定物理設備的一部分的軟件也是如此。

A.3 特定條款和子條款的基本原理

3.6-健康軟件的定義

根據ISO 17791:2013,健康軟件還包括 - 在其基本形式 - 系統、軟件項和軟件單元(參見IEC 62304:2006和IEC 62304:2006 / AMD1:2015的定義3.30,3.25和3.28),以及相關的編碼系統,推理引擎,原型和本體。此外,它包括使用,受益或適用于衛生部門任何部分的軟件,包括所有公共和私營組織或企業以及消費者,

3.6中的健康軟件定義與ISO 17791:2013,2.6中相同術語的定義不相沖突。


4章-健康軟件產品需求

通常的做法是根據預期用途建立產品的使用需求,并且確認最終產品的標準是基于這些客戶或使用需求。定義系統需求和最終產品的確認之間的階段是產品開發過程。這種開發過程如圖A.2所示。實際過程可以遵循各種方案,例如瀑布模型或更多迭代或增量開發方案。本標準不要求或優先考慮特定的過程方案。

A.2IEC82304-1 產品流程

用戶需求是開發過程的輸入,并通過一系列解釋這些用戶需求的過程。一旦建立了系統需求,就可以啟動IEC 62304:2006IEC 62304:2006 / AMD1:2015中描述的過程。這些過程導致經過確認的健康軟件與文檔一起發布。根據此文檔,隨后最終確定了隨附文檔,使健康軟件成為真正的健康軟件產品,可以接受有效保護。

對于健康軟件產品的確認,本標準要求基于使用需求的確認計劃;見4.2和4.3。成功確認VAL后,可以認為健康軟件產品可滿足用戶需求。由制造商決定是否將健康軟件產品投放市場;除了成功的確認之外的其他考慮可以影響該決定。

在上市后階段,制造商可能會收到 - 或積極收集有關健康軟件產品的反饋。根據這些信息或其他考慮因素,可以對上市后活動做出決定。這些活動可能包括軟件維護,必須遵循與初始開發相同的過程

(如果適用)。其他上市后活動可以是與用戶或當局的溝通,例如與安全漏洞的溝通。

與健康軟件相關的危害可能源于可用性問題。在確定使用需求時,建議參考IEC 62366-1:2015了解可用性工程流程。

IEC 62304:2006和IEC 62304:2006 / AMD1:2015,處理醫療器械軟件的生命周期過程,涵蓋整個軟件開發方案。IEC 62304旨在參考其他系統安全標準。IEC 82304-1涵蓋整個產品生命周期,并在適用的情況下標準化地參考IEC 62304:2006和IEC 62304:2006 / AMD1:2015。

5章 健康軟件-軟件生命周期過程


本文件包含基于風險/收益的方法。本標準的用戶需要建立,維護和應用風險管理流程,作為合規性的一部分。IEC 62304:2006和IEC 62304:2006 / AMD1:2015中記錄了該要求以及軟件生存周期過程的其他要求。這些要求同樣適用于所有健康軟件,并通過引用規范性地包含在本文件中。

6章 健康軟件產品確認

任何健康軟件開發生命周期模型的最后階段是健康軟件產品確認。確認過程的目的是提供客觀證據,證明健康軟件產品在其預期的操作環境中符合健康軟件產品使用需求(4.2)。健康軟件產品確認旨在確保構建正確的產品。確認對于健康軟件產品很重要,因為可能會發生只能通過確認發現的功能之間的意外交互。

健康軟件產品有效性可包括大量數據,高負載或壓力,人為因素,性能,配置兼容性,數據,環境和系統完整性,故障測試,文檔,安全和安全性的測試。

需要獨立性,至少強烈建議,以避免利益沖突,并且因為設計者的假設不應影響或限制健康軟件產品確認的范圍。獨立程度的例子包括:

a) 獨立的人;

b) 獨立管理;

c) 獨立組織;

7.1-標識

軟件可以輕松更新或升級,有時無需用戶參與。重要的是,可以識別所使用的健康軟件的特定版本。術語版本標識符“適用于此特定健康軟件版本,而不適用于健康軟件的單個副本。用于每個版本的標識符應足夠獨特,以區分使用中的健康軟件版本與之前版本的健康軟件。

7.2.3.2 旨在用于IT網絡的健康軟件

本文件建議使用IEC 80001-1:2010IEC 80001-2-2:2012,以獲取更多信息和有用的指導,盡管當前版本的范圍僅限于醫療器械和()醫療器械軟件。

當閱讀IEC 80001-1:2010IEC 80001-2-2:2012用于本文件時,術語“醫療器械”可以理解為“健康軟件產品”;“醫療器械制造商”稱為“健康軟件產品”制造商”。


[1] IEC 60601(all parts),Medical electrical equipment

[2] IEC 60601-1:2005,Medical electrical equipment part1: General requirements for basic safety and essential performance

[3] IEC 61907:2009 Communication network dependability engineering

[4] IEC 62366-1:2015 Medical devices - Part 1: Application of usability engineering to medical devices

[5] IEC 80001-1:2000 Application of risk management for IT-networks incorporating medical devices - Part 1: Roles, responsibilities and activities

[6] IEC/TR 80001-2-2:2012 Application of risk management for IT-networks incorporating medical devices - Part 2-2: Guidance for the disclosure and communication of medical device security needs, risks and controls

[7] IEC 80601(all parts) Medical electrical equipment

[8] ISO/IEC 12207:2008 Systems and software engineering -- Software life cycle processes

[9] ISO/IEC 14764:2006 Software Engineering -- Software Life Cycle Processes --

Maintenance

[10] ISO/IEC Guide51:2014 Safety aspects Guidelines for their inclusion in standards

[11] ISO/IEC Guide63:2012 Guide to the development and inclusion of safety aspects in international standards for medical devices

[12] ISO 9000:2015 Quality management systems - Fundamentals and vocabulary

[13] ISO 13485:2016 Medical devices - Quality management systems - Requirements for regulatory purposes

[14] ISO 14708(all parts)Implants for surgery-Active implantable medical devices

[15] ISO 14971:2007 Medical devices Application of risk management to medical devices

[16] ISO/TR 17791:2013 Health informatics Guidance on standards for enabling safety in health software

[17] IEEE 1044:1993 Classification for software anomalies

[18] WHO:1946 Preamble to the Constitution of the World Health Organization as adopted by the international Heath Conference,New York,19-22 June,1946;Signed on 22 July 1946 by the representatives of 61 States (Official Records of the World Health Organization,no.2,p.100)and entered into force on 7 April 1948

[19] IMDRF/SaMD WG/N10FINAL:2013 Software as a Medical Device (SaMD):Key Definitions (http://www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-131209-smad-key-definitions-1 40901.pdf)

[20] HIMSS/NEMA HN 1-2013 Manufacturer Disclosure Statement for Medical Device Security(https://www.nema.org/standsrds/Pages/Manufacturer-Disclosure-statement-for-Medic al-Device-Security.aspx).

http://www.sdmdcw.com魯械咨詢代辦醫療器械注冊證


閱讀42
分享
寫評論...