終於來到了最後一天，在最後一天的文章當中，我將來回顧這 30 天的文章。在這 30 篇文章當中，我們將醫療軟體的概況全貌說明了一遍。
首先是「屬性」：我們先區分一般健康／醫療相關軟體與醫療器材軟體。本系列主要討論 SaMD，也就是軟體本身執行醫療目的，且不是硬體醫療器材一部分的情況；醫療器材內部的軟體，不一定屬於 SaMD。實際定位仍要依用途、功能及適用市場判斷。FDA 的 SaMD 說明
「利害關係人」：在利害關係人當中，使用醫療軟體的人可能會是受測者、照護者、醫護人員，還有管理者。需要考慮如何設計不同角色使用的權限以及操作的流程... 等等。
「預期用途」：在開發醫療軟體時，我們需要將預期用途定義清楚。除了定義預期用途之外，還要定義非目標、使用族群...，在之後的需求以及風險管制上，以此預期用途為基礎來發展出去。
在第二階段當中，我們聊到了如何控管品質以及管理需求的風險。我們說明了：
這些標準分別從品質管理、風險、軟體生命週期與安全使用的角度，幫助我們規劃開發工作。實際適用哪些要求，仍要依產品與市場確認，不能只因文章介紹了標準，就認為產品已經符合規範。
除了妥善打造以外，管理也十分重要，其中包含風險管理與 bug 管理，需要識別一些危害的情境，在新版本推出之後，我們也需要持續驗證上市後的維運情況。
如果在上市之後遇到了問題或情況需要立即修正，也需要妥善評估風險、走完該走的流程，才不會因為匆忙上線，反而引來更多的風險。
介面的可用性也要一起考慮。除了正常操作，還要將使用錯誤以及例外情況補進需求，例如選錯家人、缺少單位、斷網與重複送出。畫面上的對象、時間與保存狀態，需要和實際寫入結果一致；控制措施是否有效，還要透過查證與使用評量確認。
另外，IEC 62304 的 A／B／C 軟體安全分類，和各市場的醫療器材法規分級不同。分類要回到產品情境、可能傷害與相關控制判斷，不能只因功能用了 AI，或顯示某種生命徵象，就直接指定等級。
在醫療軟體當中，我們先要把資料本身的意思記清楚，再透過資訊交換標準，讓不同系統有共同依據理解資料。
以家庭生命徵象紀錄 App 為例，量測對象與登錄者可能是不同的人；量測、登錄與同步，也可能發生在不同時間。資料模型需要分開保存這些意思，並留下項目、數值、單位、來源、狀態與修訂版本。更正輸錯的值，是同一次量測的新版本，不能在趨勢圖裡當成另一筆量測。缺值也不能直接補成 0。
那麼，符合規格的資訊交換標準需要注意哪些事項呢？
我們談到 HL7 制定的 FHIR 標準。它約定資料的結構與意義，例如用 Patient 表示量測對象、Observation 表示量測結果、Device 表示已知裝置，再透過 Reference 連接資源。
不過，這不代表每次傳送都會把全部資訊放進同一個封包，或自動具備足夠的上下文。被參照的資源可能需要另外取得，雙方也要確認 FHIR 版本、Profile、實作指引、代碼、單位及病人識別規則。JSON 可以解析，還不等於已完成資料驗證與系統串接。FHIR 交換方式
除了 FHIR，在處理醫療影像時，我們也介紹了 DICOM。它涵蓋醫療影像及相關資料的模型、格式與通訊，保留像素之外的病人、檢查、裝置與影像位置等脈絡。
DICOM 常透過 Patient、Study、Series、Instance 的階層，以及 Study、Series 與 SOP Instance UID 等識別資訊，維持資料之間的關聯。DICOMweb 是透過 Web 存取 DICOM 資料的一組服務；雖然儲存請求可以包含多個物件，但這不是把所有影像放進單一網路封包的意思。DICOMweb 儲存交易
以電腦斷層為例，一次檢查可能產生多張切片或多影格影像。系統需要透過識別碼、位置與方向等資訊，知道哪些影像屬於同一組、應如何排列。單獨匯出 JPEG 或 PNG，可能失去部分脈絡；維持關聯不能只靠把檔案一起傳送，也不能因此保證沒有遺失。
資料保存正確之後，還要確認它能支持什麼結論。例如一週只有兩筆血壓紀錄，可以比較那兩次讀值，卻不能直接說整週持續上升。我們需要交代缺少的日期、尚未同步的資料，以及量測條件是否可比。若要用來訓練模型，也要檢查資料代表性、標籤來源與訓練／測試資料的獨立性，避免資料洩漏讓結果過度樂觀。
在軟體架構當中，我們需要劃分信任邊界。
所謂的信任邊界，是資料跨越不同信任程度或控制範圍的位置，例如量測裝置、App 與外部服務之間。跨過邊界時，我們不能直接相信傳入的資料或權限，需要重新檢查格式、來源、身分與授權。
第三方服務失效時如何替代，則是故障處理與備援設計的問題。例如摘要服務無法使用時，可以依需求回到固定模板或原始紀錄；同步失敗時，則清楚顯示「已存本機、尚未同步」。這些行為也要先定義並查證，不能只靠劃出邊界就認定故障已被隔離。
另外就是隱私權的部分。我們都知道醫療軟體當中可能會收集許多病人的資訊，如果我們將這些資訊完完全全不做任何保護就傳遞出去，很有可能將病人的隱私也一併傳遞出去，造成病人的隱私受害，所以我們需要保護病人的隱私。
那我們該怎麼做呢？先確認資料的用途、必要欄位、接觸者與保存期限，再安排授權、加密、日誌與備份等保護；需要去識別化時，再依用途與適用要求選擇方法。
以美國 HIPAA 的適用情境為例，Safe Harbor 是去識別化方法之一，要求移除規定的 18 類識別資訊，並且沒有實際知悉剩餘資訊能單獨或結合其他資料識別個人；它不是禁止系統儲存這些資料的清單。HIPAA 是否適用，也要依機構、業務關係與資料情境確認。另外，即使完成去識別化，也不能把再識別風險視為零，所以我們還是需要特別小心。HHS 去識別化說明
接下來是身分驗證的部分。它確認操作者控制與帳號綁定的驗證方式，例如密碼或通行密鑰。登入後的工作階段與 Token，也需要依風險設計有效期限、登出及必要的撤銷機制，不能只因曾經登入成功，就永久信任後續操作。
在授權方面，每次查看或修改資料，都要依當時有效的角色、照護關係與家屬委派判斷。如果照護關係或委派已被撤銷，就要阻止後續存取該病人的相關資料；這不一定代表停用整個帳號，因為他可能還有其他合法任務。
所以在隱私權的方面，我們需要特別小心注意，以免不小心將病人的資訊洩露出去。同時，也要避免已經失去特定授權的帳號，繼續存取不再允許查看或修改的資料。
資料的其他副本也不能忽略。TLS 保護傳輸連線；全磁碟加密降低未解鎖磁碟被直接讀取的風險，但不能取代應用程式授權。稽核與除錯日誌要依用途選擇欄位，避免寫入不必要的健康資料、Token 或金鑰。備份除了保存，還要測試還原能力、確認金鑰可用，並安排期限與刪除流程，避免還原時讓已刪除的紀錄意外復現。祕密與金鑰也要有最小權限、輪替及撤銷安排。
第五個階段是驗證與維運階段。
從開發期間開始，我們就需要建立版本與組態紀錄，發布上市之後繼續維護。其中包括：
在開發與評估時，需要分清楚兩種目的不同的活動；它們不是只能依序做一次的兩階段測試：
查證（Verification）：
「Did we build the product right?」
確認開發產出是否符合規定的需求。測試可以依事先訂定的預期結果判定 Pass 或 Fail；查證也包括審查與分析，不只執行測試。
確效（Validation）：
「Did we build the right product?」
確認產品是否符合使用者需求及預期用途，需要依產品和風險安排相應的證據。
如果包含 AI 模型，還需要獨立於訓練及調參的測試資料，依任務與事先訂定的接受準則評估模型表現。統計指標是其中一部分，不能單獨代表整體產品確效已完成；文字摘要也不能只套用分類模型的指標。FDA 查證與確效說明 §3.1.2
工程測試可以確認警報是否依規格觸發，但使用者能不能注意、理解並完成安全操作，還要另外評量。形成性評量在設計與開發期間找問題，將回饋帶回設計，再反覆修改與評量。
等設計定下來後，總結性評量讓代表性的預期使用者，在接近實際使用的環境與訓練條件下操作。主持人不在途中教答案，操作後再透過訪談釐清困難與錯誤。若修改影響安全相關操作，還要評估再次確效的範圍；人因評量本身也不是整體產品確效的全部。
AI 摘要同樣需要先處理輸入條件。我們要提供觀察期間、實際紀錄與缺漏背景，先由程式檢查資料是否符合條件，再透過 Prompt 與工具限制處理範圍。
產生文字後，還要核對對象、日期、數值、單位及有沒有資料不支持的結論。檢查失敗或服務無法使用時，就回到固定模板或原始紀錄。Prompt、MCP 或輸出格式都不能保證內容正確，也不應讓整理紀錄的功能自行加入診斷、治療或用藥建議。延伸草案中的提醒狀態及模型比較，仍要保留為待實作、待執行的設計。
在需求規劃與後續開發當中，我們可以透過需求追溯矩陣（RTM），連結危害與風險控制、需求、設計／實作、測試案例，以及對應版本的實際執行結果。
正向追查，可以找出缺少設計、實作或證據的需求；反向追查，則確認功能與測試有沒有合理來源。即使表格已有連結，也要檢查案例是否涵蓋失敗條件，以及結果是否真的支持需求與控制效果。
RTM 幫助我們追查證據與缺口，但不能單靠表格宣告版本正確或可交付。還要結合風險評估、查證／確效結果、已知異常與發布審查，判斷是否符合放行條件。示例表格中的 Pass，也必須有對應的執行紀錄，才能當成實際證據。
在軟體終於上市之後，我們也要不斷去監控是否有出現問題需要修復。
當然我們前面有提到，如果我們採用的是第三方軟體，就要在有漏洞、有弱點被揭露的時候，對照受影響版本與實際使用路徑，評估風險、必要的暫時措施與修補時程。如果是我們自己的錯誤，同樣要保留問題紀錄，調查原因與影響範圍，控制變更，再安排查證、回歸測試與發布審查。必要的通知或通報，依事件與適用要求判斷，也可能和調查同步進行。
監控的對象除了當機與同步失敗，也包括資料缺漏、摘要核對失敗、使用者回饋及外部服務變更。若模型表現改變，先排查資料、裝置、前處理與評估條件，再決定是否重新訓練；更新後用獨立測試資料比較新舊版，並評估受影響的風險控制、使用流程及適用的法規程序。用途沒有改變，也不能直接推定免辦變更；若引用 PCCP，仍要確認適用市場、主管機關核准範圍與執行條件。
完成修正後，還要確認哪些版本已部署、受影響的使用者與既有錯誤資料如何處理，並保留結案依據。這些工作讓風險管理持續得到回饋；不能因為一次修補完成，就認為往後的風險都已受控。
終於完成這 30 天的文章，而我也剛好在新公司滿三個月（過試用期XD）。搭配了這 30 天的研究，我才了解到醫療軟體其實不只是改變寫軟體的內容而已。它需要我們從規劃、開發到生產的這條路，都好好地規劃與討論，我們也需要將風險以及可能的危害評估出來。
在這樣的情境之下，每一步都需要走得特別小心。因為 SaMD 具有醫療療效，如果不認真看待、不小心面對的話，很有可能會因為我們的疏失而造成使用者的危害，所以不得不小心。
最後完賽，好久沒有寫鐵人賽了。這 30 天真的是蠻辛苦的。
我要來開始好好的學習/享受醫療軟體的開發了。Go！
iThome鐵人賽
看影片追技術