前面幾天中，我們介紹了 FHIR、DICOM 這兩種醫療資料標準。不過當設計一套醫療軟體，只有資料是不夠的，還需要設計軟體架構，搭配一套 UI/UX，讓資料能夠正確地取得、儲存。

一個軟體系統，除了資料格式外，還需要處理輸入、儲存、權限、提醒、外部服務……我們需要知道資料的處理流程，有哪些邊界，那麼我們就可以知道哪些地方會有問題。譬如若資料流向外部服務時，外部服務掛掉後，我們該怎麼處理？

若我們以血壓紀錄 App 來看，輸入一筆資料需要確認使用者是誰，收縮壓、舒張壓是多少？單位是什麼？量測時間是何時？……每個問題都會在系統的不同位置處理，而這些處理數值的地方若有問題，我們儲存的數據就會有問題。

拆解簡化架構

一個軟體架構可以分為好幾個部分，將架構簡化如下：

• 輸入與檢查：欄位、單位、範圍、缺漏。
• 身分與權限：誰登入、誰可查看或修改紀錄。
• 資料保存：本機或主資料庫、同步狀態。
• 提醒與呈現：讀取紀錄後如何產生畫面或提醒。
• 稽核紀錄：記下哪些重要操作。
• 外部介面與裝置：同步服務、量測裝置或其他依賴。

資料流與信任邊界

接下來，我們可以以資料的流程來看系統的信任邊界。一筆資料在輸入後，會經過架構的哪些模組？我們可以從每一個模組的邊界，確認資料是否有正確輸出、輸入。

這裡說的「信任邊界」，不是每一個模組之間的連線，而是資料從我們不能完全控制的地方進來，或送到另一個系統的地方。譬如量測裝置把資料傳給 App，或 App 把資料送往外部服務。跨過這些邊界時，我們不能直接認定資料正確，或對方一定有權存取。

若架構中某些模組故障，該如何處理？例如網路不通時，原先要上傳的資料會怎麼處理？會有補傳機制嗎？如果資料已存於本機、卻尚未傳到伺服器，畫面也應讓使用者看得出這兩種狀態的差別。

而在資料流程中，需要注意哪些流程有接觸個資，哪些有經過外部模組。經過個資的部分、外部模組的部分都要特別處理；可能影響紀錄或提醒正確性的路徑，也需要標示出來。

把資料流畫出來

如果把剛才的血壓紀錄 App 畫成簡化架構，大致會像下面這樣。這裡先假設 App 可以把紀錄存於本機，再同步到伺服器；量測裝置則是可選的資料來源。

flowchart LR
    U[使用者] --> AUTH
    D[量測裝置／外部依賴] -.-> INPUT

    subgraph APP[手機 App]
        AUTH[身分與權限] --> INPUT[輸入與檢查／安全相關]
        INPUT --> LOCAL[本機紀錄／個資]
        LOCAL --> VIEW[畫面或提醒／安全相關]
        LOCAL --> SYNC[同步／個資]
        AUTH --> LOG[重要操作紀錄]
    end

    subgraph SERVER[伺服器]
        API[接收與權限檢查] --> DB[主資料庫／個資]
    end

    SYNC --> API

圖中的「個資」標出健康資料可能經過或停留的位置；「安全相關」則是出錯後可能影響紀錄或提醒正確性的地方。量測裝置、手機 App、伺服器分屬不同範圍，資料跨過這些地方時就要再檢查。操作紀錄也可能含有敏感資訊，不能因為它不是主資料庫就忽略。

如果其中一段故障呢？

回到一開始的問題：外部服務掛掉時，App 要怎麼辦？我們可以沿著這張圖，一段一段往下問：

• 網路不通：若這套 App 允許先存本機，就顯示「已存於本機、尚未同步」。等網路恢復後再嘗試上傳，並確認是否真的送達；不能只因為使用者按了儲存，就顯示伺服器同步成功。
• 量測裝置少傳了資料：例如只收到收縮壓，沒有舒張壓或量測時間。這時要讓使用者知道資料不完整，而不是直接把它當成一筆完整的血壓紀錄。
• 權限或儲存出了問題：若無法確認這筆紀錄屬於誰，或資料根本沒有存成功，就應停止這次操作，清楚告訴使用者目前的狀態。否則畫面看起來正常，紀錄卻可能存錯人或根本沒存下來。

這些只是用來檢查架構的例子。實際要採用哪種處理方式，仍要回到產品的預期用途、需求與風險評估。不過，至少我們已經知道：畫架構圖時，不能只畫出資料正常流動的箭頭，也要想清楚某一段停住後會發生什麼事。

小結

今天從一筆血壓紀錄出發，拆開了輸入、權限、儲存、提醒與外部服務，再把個資路徑、可能影響安全的路徑和信任邊界標在圖上。這張圖不代表軟體已經完成，而是幫我們找出後續還要寫成需求、處理方式與查證案例的地方。

下一篇會接著看資料完整性：即使每個模組都沒有壞，病人配對、時間、單位或重複紀錄出了問題，資料還是可能被誤解。