（續前篇）
醫療器材品質管理系統整合、風險治理及全生命週期合規初探
本文以網路搜集來的介紹文件及概要說明為參考基礎，並利用公開法規資料補充及核對，以人工智慧協助進行個人判斷，完成之介紹性文章，僅供一般資訊與個人持續教育用途，不構成法律意見、資訊服務或對任何產品符合特定法律之保證。引用請註明出處。文中如有引用疏漏，歡迎聯繫補正。
CC BY-NC-ND。非供AI模型訓練。
8. Verification, validation and clinical evidence｜查證、確效與臨床證據
8.1 Verification and validation answer different questions｜查證與確效回答不同問題
在工程及品質管理實務中，查證（verification）與確效/確證（validation）有不同目的。
查證通常著重於確認設計輸出是否符合設計輸入及相關規格。
確效則著重於確認產品是否適合預期用途，以及在預期使用情境中能否達到所需結果。
對 AI 醫療器材而言，這兩種活動都不可或缺。
例如：模型程式能夠正確執行、輸出格式符合規格，並不代表其臨床性能已獲充分證明。同樣地，某項臨床研究呈現良好結果，也不能自動證明所有軟體功能、資料處理、資安及組態控制均已通過確證。
企業應根據產品特性建立相互關聯的查證與確效策略。
8.2 A layered evidence strategy｜分層證據策略
可將證據規劃分成四個層次：
- Technical verification｜技術查證
確認程式、資料處理、介面、系統整合及其他設計輸出符合規格。
- AI model evaluation｜AI
模型評估
評估適當的模型性能指標、資料代表性、穩健性、限制及不同情境下的表現。
- Clinical evaluation or performance
validation｜臨床評估或性能確效
根據產品預期用途及適用法規，建立足以支援安全性、性能及臨床適用性的證據。
- System-level validation｜系統層級確效
評估 AI 功能與使用者、工作流程、部署環境及其他系統組件共同運作時的整體表現。
這四層是分析與規劃工具，不是所有產品都必須採用相同的測試架構。實際測試活動應依產品風險、預期用途、適用標準及法規要求制定。
8.3 Test design must be risk-based｜測試設計必須以風險為基礎
測試頻率、樣本量、性能門檻及接受準則，不應僅憑開發團隊的經驗或方便程度決定。
合理的測試策略應說明：
- 為什麼選擇這些性能指標？
- 為什麼選擇這些測試情境？
- 測試資料是否足以支援相關判斷？
- 哪些失效情境需要特別測試？
- 如何處理統計不確定性？
- 哪些結果會導致拒絕放行？
- 哪些變更會觸發回歸測試或重新確效？
測試計畫也應區分開發期間的探索性評估與正式用於符合性判定的測試。若測試資料反覆被用來調整模型，可能降低其作為獨立評估證據的可信度。
對於高風險醫療用途，企業尤其應避免在看到測試結果後才臨時選擇有利的性能指標或門檻。
8.4 Human oversight and usability｜人工監督與可用性
AI Act 對高風險
AI 系統的人工監督及透明度設有相關要求。對醫療器材而言，人工監督不能只靠使用說明書中的一句「最終決策由醫師負責」。
有效的人工監督需要考慮實際工作流程與人因因素。
例如：
- 醫師是否能理解 AI 輸出的意義與限制？
- 系統是否清楚區分高信心與低信心結果？
- 當系統無法可靠判斷時，是否提供適當警告？
- 使用者是否有合理機會覆核結果？
- 使用者能否在必要時忽略或推翻 AI 建議？
- 系統介面是否可能誘發自動化偏差（automation bias）？
- 當工作量大、時間壓力高或警告頻繁時，人工監督是否仍然有效？
這些問題不應只由軟體工程師在技術層面決定。適當的臨床專業人員、使用者代表、品質及法規團隊，應依產品情境共同參與。
真正的人工監督，是讓人員具備理解、判斷及採取適當行動的能力，而不只是把責任留給使用者。
9. Post-market surveillance and serious-incident reporting｜上市後監督與嚴重事件通報
9.1 Compliance continues after market entry｜上市不是合規工作的終點
AI 醫療器材上市後，企業仍需要處理投訴、性能變化、使用者回饋、資安弱點、系統性錯誤及其他可能影響安全與法規符合性的資訊。
對 AI 系統而言，上市後監督還有一個重要任務：確認產品在實際部署環境中的表現，是否仍與上市前的查證及確效證據相符。
例如：AI 影像分析系統可能在開發階段使用特定影像設備及患者族群進行評估，但部署到不同醫療機構後，可能遇到不同的影像品質、工作流程、疾病盛行率或患者特徵。
這些差異不一定代表產品已經不安全，但如果可能影響性能或風險，就需要依預先定義的程序進行評估。
AI Act 第 72 條規定高風險 AI 系統的上市後監督要求；第 73 條則涉及嚴重事件的報告。這些要求應與適用的醫療器材上市後監督、警戒及事件通報程序相互協調。
9.2 A post-market monitoring feedback loop｜上市後監督回饋閉環
|
1. Data collection｜資訊蒐集 投訴、使用者回饋、性能指標、資安弱點、事件及部署資訊 |
|
2. Signal detection｜訊號偵測 趨勢分析、異常門檻、重複事件及潛在新風險 |
|
3. Investigation｜調查與評估 因果關係、產品版本、影響範圍及風險重新評估 |
|
4. Action｜採取行動 矯正措施、風險控制、使用者通知、必要的法規通報及其他適當措施 |
|
5. Effectiveness review｜有效性確認 確認問題是否受控、風險是否降低，以及是否需要更新設計與程序 |
圖示為本文提出的實施模型。各項活動的具體義務及時限，須依適用法規與事件性質判定。
此流程的重點是讓上市後資訊回到設計、風險及品質管理系統，而不是把上市後監督當成一個獨立的客服工作。
9.3 Define meaningful monitoring indicators｜設定具有意義的監督指標
監督指標應能反映產品的預期用途及相關風險。
對 AI 輔助影像分析系統，可能的指標包括：
- 輸入資料品質不符合要求的比例；
- 系統拒絕輸出或要求人工覆核的比例；
- 經確認的錯誤輸出及相關事件；
- 特定適用族群的性能變化；
- 使用者投訴及操作問題的趨勢；
- 資安弱點與修補狀態；
- 模型更新後的性能變化；
- 系統可用性及服務中斷情況。
這些指標並非全部都適用於每個產品，也不是標準要求企業一律採用的固定清單。
每一項指標都應有明確定義、資料來源、監督頻率、分析方法、責任人及異常處置規則。
如果企業只定義指標，卻沒有規定何種結果需要調查、何時必須升級通報，以及誰有權暫停產品使用，監督機制就可能無法發揮實際作用。
此外，模型性能的變化也不應自動被視為唯一的風險訊號。某些低頻但後果嚴重的事件，可能需要個別調查，即使整體性能指標尚未越過預設門檻。
9.4 Serious incidents and reporting timelines｜嚴重事件及通報時限
企業應建立正式的事件識別、調查、升級及通報程序，並明確區分 AI Act 與醫療器材法規下的事件分類及通報要求。
尤其不能將不同法規的定義、起算點及時限混為一談。
AI Act 第 73 條對特定嚴重事件設有通報規則及相應時限。企業在建立程序時，應直接核對適用版本的法規原文，確認事件類型、知悉時間、報告對象及後續報告要求。第 73 條的通報時限具有動態分級：
• 涉及關鍵基礎設施失效：知悉後 2 天內。
• 造成人員死亡或健康嚴重受損：知悉後 10 天內。
• 一般嚴重事件：知悉後 15 天內。
• 時限均自提供者（Manufacturer/Provider）《知悉（Aware）》事件起算，且醫療器材廠商必須同時盤點 MDR/IVDR 與 AI Act 雙重通報機制的起算點差異。
實務上，程序應至少回答：
- 哪些人員可以啟動嚴重事件調查？
- 如何判定事件是否可能與 AI 系統有關？
- 如何記錄企業首次知悉事件的時間？
- 誰負責判定適用的法律通報要求？
- 如何在調查尚未完成時處理可能適用的初步通報？
- 如何保存調查、決策及通報紀錄？
- 如何判定是否需要停止供應、限制使用、更新產品或採取其他矯正措施？
企業不應只在程序中抄錄一組固定天數，而應建立可以依事件性質及適用法律正確判定期限的機制。
10. Documentation and evidence architecture｜文件與證據架構
10.1 Documentation must support decisions｜文件必須支援決策
EN 18286 的管理價值不在於增加文件數量，而在於使法規符合性決策具有一致性、可追溯性及可稽核性。
文件至少應支援三種不同目的：
- 規範工作如何進行：
政策、程序、工作指示、技術規範及接受準則。
- 證明工作實際已執行：
審查紀錄、測試報告、核准紀錄、訓練紀錄及供應商評估。
- 說明為什麼作出某項決策：
適用性判定、風險接受、變更評估及法規解釋紀錄。
只保存第一類文件，卻缺乏後兩類證據，無法充分證明管理系統在實際運作中有效。
為避免
QMS 疊床架屋，廠商應採取「程序共用，但證據欄位擴充」的策略：
|
既有ISO 13485流程 |
⚠️ AI Act / EN 18286 必須補強的盲點 |
📄 應產出的產品層級客觀證據 |
|
7.3 設計開發變更控制 |
不能僅評估程式碼。必須評估模型權重、訓練資料集、外部相依元件變更是否構成「重大修改（Substantial Modification）」。 |
變更影響評估報告（含技術、風險、法規三維度）、可回溯的版本控制紀錄。 |
|
7.1 產品實現與設計輸入 |
傳統軟體未涵蓋端到端資料生命週期。必須補強資料標注者資格控制、偏見（Bias）偵測與資料退役機制。 |
符合AI Act第10條的資料治理程序書、資料集版本與劃分紀錄、訓練/確證/測試（Training/Validation/Test）。 |
|
7.3.7 設計查證與確效 |
統計性能不等於臨床安全。測試集上的高準確率無法替代【人機互動偏差（自動化偏差）】與不同臨床部署環境的泛化能力評估。 |
分層性能測試報告、可用性（人因工程）評估報告、外部確證（External Validation）數據。 |
|
8.2.1 上市後監督 (PMS) |
缺少 AI 特有指標。必須主動監督模型漂移（Drift）、輸入影像品質拒絕率、人工覆核/推翻 AI 建議的比例。 |
主動式 AI 上市後監督計畫書、動態異常觸發與升級處置門檻紀錄。 |
（見續篇）
沒有留言:
張貼留言