昨天的文章中，我們已經知道一般軟體與醫療軟體的差異，可以開始開發醫療軟體了嗎？
在開始開發醫療軟體之前，我們需要更進一步了解，究竟你開發的是「一般醫療軟體(General Health/Medical SW)」還是「醫療器材軟體(Software As s Medical Device)]」。

對於第一次看到這兩個名詞的人來說，這兩個名字看起來很相似，但是它們兩個卻又代表著不同意思。

首先，我們用一個簡單的範例來說明，假設我們開發了一個 App，可以用來紀錄血壓，我們可以與數位血壓計連線，每次量測的數值都會自動傳上去 App 內，我們可以在 App 內看到每次量測的內容，用來觀察身體的狀況，必要時還能提供給醫生作為參考。我們稱這個 App 為「血壓量測 App」；又假如，有另一個 App，除了可以紀錄血壓外，還能夠依據量測的血壓數據給予醫療建議，並給予藥物劑量，與前面的 App 比較，這個 App 多出了「療效」、「建議」，我們稱這個 App 為「血壓量測 Plus App」

這兩個 App -「血壓量測 App」、「血壓量測 Plus App」對應到的醫療軟體名稱就是「一般醫療軟體」以及「醫療器材軟體」

如同上一篇文章所提到的，不論是一般軟體還是一般醫療軟體，其實都是屬於一般軟體，也就是就算是提供給醫療產業使用，只要不涉及診斷、治療、緩解、直接輔助臨床決策，就不屬於 SaMD，也就不需要讓主管機關監管。

將一般醫療軟體與醫療器材軟體以預期用途以及風險責任來區分，詳細如下：

• 預期用途（Intended Use）： 主管機關（如 TFDA、FDA）監管醫療軟體的核心並非看程式碼寫法或運行平台（Web、App），而是看廠商宣稱的預期用途。
  • 一般醫療/健康軟體： 僅用於行政流程（如掛號、病歷調閱）、衛生教育或單純的健康數據紀錄，不對疾病進行診斷或處置。
  • SaMD（Software as a Medical Device）： 軟體本身即為醫療器材，具備一個或多個醫療用途（如疾病診斷、治療、緩解、直接臨床決策或風險預測）。
• 錯誤後果與風險責任的不同：
  • 一般軟體若故障，主要造成行政不便或流程延遲。
  • SaMD 若數值錯誤或演算法出錯，會直接導致誤診、延誤治療或錯誤用藥，對病人安全造成直接危害。因此，開發者必須對軟體的輸出結果負起法規與臨床責任，確保功能與精度完全符合宣稱

小結

一般醫療軟體與醫療器材軟體雖然名稱相近，但是目標、目的不同，一開始進入時，可以先以一般醫療軟體確認市場是否存在，在依照技術力提升軟體效益，之後若能達到宣稱的效果時，就可以成為醫療器材軟體，不過這時候就需要受到監管機關的監控，且開發的各個環節都要特別小心。