在進入醫學軟體開發之前，可能會思考一個問題，那就是我需要了解醫學知識嗎？回答這個問題之前，我分享一下我的經驗，當我開發一個軟體，雖然可以在不完全知道開發項目的背景知識就開始進行開發。如果 Stakeholder 可以提出非常完整的設計稿、流程圖...，不過經常都是沒有那麼完整，所以這麼一來，我們就需要與 Stakeholder 討論出他的需求，才能進入開發，想想看，如果我們對於醫學知識沒那麼深，我們可能光是討論需求就需要討論很久才能夠進入開發。

既然如此，在進入開發之前，我們或多或少都需要一些相關的醫學知識才能夠進行有效率的開發。既然是醫療軟體，我們可以直接從軟體會使用到的醫學相關知識進行，只要有辦法了解數據的流動、資料的格式、使用情境... 將場景限縮，只要將打算開發的醫療軟體內的相關知識補齊，就沒有太大的問題，就如同馬斯克經常使用的第一性原理，我們先分解要解決的問題，找到其第一性原理，從最小的元件開始，慢慢擴大後，就能夠開發軟體所需要的內容補齊了。

資料要有語意脈絡

回到前面的範例，假設「血壓 App」，能讓我們透過 App 可以收集使用者的血壓，完成後能將其上傳至雲端分析。第一步，我們需要定義上傳的格式，如下：

{
	"blood_pressure":140
}

那麼問題來了，這個 JSON 只包含一個血壓值，對於判讀醫療資訊來說，著實不足夠，要能夠使其有效還需要加上姓名、時間，若是採用外接血壓計，也必須要將血壓計的型號紀錄下來，甚至可能還需要紀錄收縮壓與舒張壓...
每一次紀錄的時候，都是代表一個「語意脈絡」，意思是說，我們在這個當下所紀錄的數值都需要有完整的脈絡，有了完整的脈絡，醫生才能夠正確的判讀數據。所以對於開發者來說，需要了解每一次的紀錄需要包含哪些內容，就是非常重要的。
經過調整之後，我們會將內容改成

{
	"patient_name":"Andy",
	"date_time":"2026-09-19T10:00:00",
	"systolic_blood_pressure":120,
	"diastolic_blood_pressure":80,
	"unit": "mmHg",
	"blood_meter":"XYZ"
}

上面範例的格式雖然看起來可行，但是在醫療領域之中，我們會採用 FHIR 格式，FHIR 格式是一種 結構模組化的 JSON，Client 端以 FHIR 格式將資料上傳至有 FHIR Server，就能夠與不同的 Server 串接，至於什麼是 FHIR 我們將在後續的章節中介紹。

參考區間不能寫死

每一項醫療數據，都有其區間，但是每個區間都會因為其年齡、性別、國籍、慢性病史... 而有所調整，換句話說，若我們希望在我們的 App 中在取得數據之後，就依照收集到的數據給於建議、判斷，我們必須要將不同的因素考量進去，才能夠盡可能的產生出正確的內容。

補充小提醒： 「在醫療系統中，若缺漏數據或未量測，在資料庫中切記不能隨意預設補 0（例如血氧 0% 在臨床上代表極度危急），必須以 null 或專門的缺失狀態紀錄。」

主觀症狀 vs 客觀徵候

前面透過血壓計量測出來的數據是屬於客觀徵候，除了透過儀器量測到的數值外，我們在看醫生時，醫生都會有問診，而在這個過程中就會讓病患主動說明自身的感受，而這就是屬於主觀症狀。
每一個人當下的狀態都會包含這兩個狀態，我們能夠感受到自身的情況，但是有些客觀的徵象卻是無法感覺到的。
在開發軟體時，客觀的徵候是最主要的數值來源，現在有了 AI model，我們可以將主觀症狀也加入其中，搭配收集到的客觀徵候以透過訓練好的模型給予建議，相信能夠得到更精確的結果。

小結

軟體工程師進入開發醫療軟體的領域時，需要注意，1. 資料需要有語意脈絡，沒有語意脈絡的內容是不足以讓醫療人員判斷內容的，2. 提供數據是人，所以會有其數據會因為不同族群會有不同的區間，3. 除了客觀徵候外，主觀的症狀也是很重要的。
有了這三個基礎觀念，我們在開發醫療軟體時，就可以開發出有實際效用的軟體。