（內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。）
雖然歐盟指引MDCG 2025-4（另文介紹）未指出風險管理系統的採認標準，若是考慮醫療器材產業界及主管機關熟悉的ISO 14971風險管理過程標準，在對應節點增加考慮網路平台的監管要求與對應措施，顯然可行，且易於獲得主管機關與公告機構的首肯及認可。
此文從利益相關者的角度，把「平台提供者」視為一個受 MDR/IVDR + DSA 約束的經濟營運者，整理出一套可直接運作的風險評鑑與報告模式（含：檢查項目、工具、步驟、接受準則、評估與緩解、剩餘風險與總結報告）。
1. 法規定位與風險評鑑範圍
平台角色區分
- 僅作為數位服務法（DSA）「中介／線上平台」：只連接開發商與使用者，多屬 hosting / marketplace；此時依 DSA 需有「非法內容通報與處置」、「透明度」、「（對 VLOP）年度系統性風險評鑑與緩解」。
- 作為 MDR/IVDR 經銷商或進口商：若平台實際把 MDSW 提供給最終使用者，或 EU 內平台上架的歐盟境外第三國製造商的產品，即須遵循 MDR/IVDR 第 13、14 條義務。
風險評鑑對象至少宜涵蓋事項：
- 不符合法規或違法的 MDSW 遭到上架／留存（如：器材無 CE標示、虛假聲明、未遵循 MDR/IVDR）。
- 關鍵合規資訊缺失或錯誤（如：UDI、IFU、製造商資訊、MD/IVD 的風險等級或分類）。
- 平台介面與排序演算法導致的「醫療 App 被誤認為一般健康／生活類」應用程式，或反之。
- 對主管機關移除命令或使用者通報的產品未及時反應和處理、或處理作業不符合要求。
2. 風險評鑑檢查項目（平台視角 Checklist）
可以把平台風險評鑑做成一張年度「合規＋營運」風險盤點清單，欄位分配如下示（示例欄位名稱）：法規角色與治理
- 是否已正式界定：平台在各種商業模式下是數位服務法（DSA）「中介／線上平台」還是「MDR/IVDR 」的經銷商／進口商？
- 是否指定負責 MDR/IVDR 合規的職責（法規／法務／法規合規長）以及 DSA 責任擔當者？
App 上架前審查（Due Diligence 盡職調查）
- 是否強制收集並查證以下資訊：經濟營運者名稱／地址／聯絡方式、SRN、UDI-DI、MD/IVD 標示、IFU/eIFU 連結、授權代表、公告機構編號與證書號碼（如適用時）？
- 是否要求開發者明確聲明：此應用程式（App）是否為 MDR/IVDR 下「醫療器材軟體 MDSW」？
產品分類與呈現
- 平台是否區分「醫療器材 MDSW」與「一般健康／生活類 App」，並只在完成必要資訊時才允許選擇 MDSW 類別？
- 平台的使用者介面（UI）是否避免以設計誤導使用者（dark patterns暗黑模式），並符合 數位服務法（DSA）下介面透明要求？
非法／不符合內容控管
- 是否建有數位服務法（DSA）所要求的「通報與行動（notice & action）」機制，讓主管機關與使用者能通報疑似違法／不符合的 App？
- 是否有過程處理 MDR/IVDR 主管機關依數位服務法（DSA）第 9、10 條發出的移除命令？
系統性風險
（特別是「大型／特大型平台」 Very Large Online Platforms, VLOP）
步驟
步驟
步驟
典型緩解措施
步驟
步驟
- 對「違法或不合規 MDSW 散布、誤導性資訊、演算法偏差」是否至少每年做一次系統性風險評鑑？
- 是否有文件化的「合理、成比例、有效」緩解措施與成效追蹤？
3. 建議使用的分析工具
利益相關者可以沿用現有醫療器材風險管理邏輯，把平台風險評鑑掛在公司「企業／合規風險架構」下：定性風險矩陣（衝擊Impact × 可能性Likelihood）
- 衝擊：病人安全／資料完整性、法律風險（罰款、禁售）、聲譽與平台存續。
- 可能性：以歷史事件、通報數量、抽查不合格率來估計。
- 此處可直接對應 數位服務法（DSA）要求的「系統性風險識別與分析」。
控制有效性評鑑
- 類似 ISO 27001及 ISO 27701 風險處理：針對每項風險盤點現有控制（契約條款、技術限制、流程），評分或等級化。
- 對 VLOP，可再加上對排序／推薦演算法的「模型風險」檢視（例如是否優先曝光爭議性醫療效果的宣稱內容）。
抽樣與監督工具
- 隨機抽查平台中標記為 MDSW 的 App，核對其 CE 標誌、UDI、SRN、IFU 連結與實際內容。
- 使用關鍵字與規則搜尋（例如：「診斷」「治療」「糖尿病管理」）找出未標為 MDSW 卻疑似具醫療效果的宣稱內容App。
4. 工作步驟與接受準則（平台年度風險評鑑流程）
步驟 1：界定範圍與風險準則步驟
- 確認平台規模（是否可能被歸為「Very Large Online Platform, VLOP」）。
- 列出所有與 MDSW 有關的業務流程：上架、分類、搜尋／推薦、下載、更新、下架。
- 已明確文件化平台在各流程下的 MDR/IVDR/DSA 法規角色。
步驟
- 針對每流程進行腦力激盪/結構化檢討（ brainstorming / structured review）：
- 不合規 App 被上架且未被偵測。
- CE 標示或 IFU 被隱藏或呈現內容不清楚、或易被誤導。
- 使用者通報機制失效或反應過慢。
- 排序演算法讓高風險 App 被過度曝光。
- 每個主要流程至少列出一組「不合規 MDSW 散布」相關的風險情境。
步驟
- 對每個風險情境評估：
- 衝擊等級（例如：以從1到5級，第5級係可能造成嚴重病患危害、死亡或重大法規違例）。
- 發生可能性（製造商預估值、比對歷史資料、抽查結果、監督通報數量）。
- 計算風險等級（如 R = S × P），並設定「不可接受／可接受但需控制／可接受」門檻。
- 最高風險情境有明確記錄，且超過門檻者都被標記為「必須制定緩解措施」。
典型緩解措施
- 強化上架前審查：自動檢查必填欄位是否齊備（SRN、UDI、IFU 連結等），並要求支援文件。
- 建立或優化「通報與行動 notice & action」 流程：通報入口清楚、SLA（處理時限）明確、與主管機關溝通管道的既定方式。
- 分類與 UI 改進：只允許符合條件的 App 使用「Medical Device」標籤，並增加警示文字或連結到 IFU。
- 對 VLOP：引入對演算法排序的治理（人為審查高風險關鍵字、設定「醫療類 App 額外審查」的 flag）。
- 每個「高風險」情境必須至少有一個明確指定的控制措施，且措施可被稽核與查證。
步驟
- 控制措施實施後，再評鑑每個情境的剩餘風險（重新評分）。
- 對仍然高於門檻但暫時無合理控制的部分，需記錄理由與補救計畫（例如技術限制、需配合法規更新等）。
- 剩餘風險須符合公司設定的允收（接受）準則，並符合「合理、成比例且有效」的 DSA 要求。
步驟
- 至少每年（VLOP 為法定最低頻率）重新執行風險評鑑，並在進行重大變更（如：轉換到新排序演算法、改變上架政策）後予以更新之。
- 利用通報記錄、抽查結果、主管機關要求、訴怨與事件資料作為風險指標。
- 提供文件化的年度匯整報告，以及追蹤上一年度 CAPA/改進措施的實施狀態。
5. 評鑑與緩解內容示例（考慮放入風險清單）
以下提供簡化的風險登錄清單的欄位結構（文字版，便於直接轉成 Excel/內部表單），每列一個風險情境：- 風險編碼（ID）。
- 流程／節點（如「上架審查」「搜尋排序」「通報處理」）。
- 風險敘述（例：無 CE 標誌的糖尿病診斷 App 被分類為一般健康 App 並大量下載）。
- 來源／觸發（歷史事件、監管通報、內部稽核發現）。
- 初始嚴重度 S / 發生可能性 P / 初始風險等級 R。
- 相關法規條文：
- 數位服務法（DSA）：Art. 30–31（交易者資訊與介面）、Art. 34–35（VLOP 風險評鑑與緩解）、Art. 9–10（移除命令）。
- MDCG 2025-4：第 3–4 章關於平台責任與資訊義務。
- 現行控制（如：強制性欄位、人工審查、條款禁止、技術檢查）。
- 控制缺口（例如：抽查發現 5% MDSW 資訊不完整）。
- 規劃的緩解措施（含負責人與預定完成日期）。
- 實施後剩餘嚴重度 S / 發生可能性 P / 初始風險等級 R。
- 剩餘風險是否可接受（是／否；如否，附加說明）。
- 監測指標（KPI，如「季度抽查不合格率 < 1%」、「數位服務法（DSA）通報處理時間中位數 < 48 小時」）。
6. 審查重點（內部／外部稽核看什麼）
可以合理預期 MDR/IVDR 主管機關、數位服務法（DSA）的監管機關、公告機構（若平台同時是製造商）將會從以下視角檢查的項目：是否有正式風險評鑑文件：
- 有無年度報告或風險登錄表，明確標示依據法規為「MDCG 2025-4 與 DSA 34–35」。
- 控制措施是否真地反映在上架流程、UI、搜尋排序規則、通報機制和內部 SOP。
- 系統性風險（非法內容、誤導資訊、演算法偏差）是否具備專門章節與治理結構。
- 稽核員經常索取的資料：風險評鑑表 → 改版流程／可用性工程（UI）變更單 → 測試／抽查紀錄 → KPI／指標趨勢。
7. 摘要報告建議結構（提交給管理階層與監管機構時）
最後是「總結報告」的綱要與相關節次，可一年做出一次更新版，須依據數位服務法（DSA）對 VLOP 的「書面風險評鑑」要求，內容可分成如下節次：1. 前言與範圍
說明平台規模、MDSW 應用程式App 規模與類型、適用法規（MDR/IVDR + DSA + MDCG 2025-4）。
2. 方法學與接受準則
簡述採用的風險矩陣、接受準則、資料來源（抽查、事件、通報）。
3. 主要風險與趨勢
概述高風險情境（例如：不合規 MDSW 散布、資訊缺失、可用性工程（UI） 誤導、演算法偏差），以及相對於去年是否改進或惡化。
4. 已實施的緩解措施
對每類風險，說明 1–2 個關鍵控制（例如上架前查證流程、可用性工程（UI）調整、演算法治理、通報與行動notice & action、 改進）。
5. 剩餘風險與改進計畫
列出仍維持在「中高風險」的情境，說明接受理由與後續改進計畫。
6. 結語與管理者簽署
管理階層確認已審查風險評鑑與因應措施，符合「合理、成比例且有效」原則。
（全文竟）
沒有留言:
張貼留言