回顧昨天範例，我們收集完血壓數據之後，會透過 AI 來做摘要。也就是說，血壓數據會先儲存在本機端一段時間後，才會透過呼叫外部 API 來做AI 摘要。別忘了，醫療軟體需要包含操作日誌。而在軟體中，一般會埋下 GA 來分析使用者操作路徑。

所以一筆資料可能有不同用途。以這個示範案例來看，可能會經過以下四種用途：

1. 本機資料庫
2. 操作日誌
3. 使用分析
4. 外部 AI 服務

將這四種用途整理成下表：

去識別化

去識別化其實就是透過技術手段，將個人資料中的識別代碼移除、遮蔽或替換，讓這些資料在沒有額外資訊輔助的情況下，使其無法對照、查到原本特定個人的過程。

隨著各國的隱私法規越來越嚴格（例如台灣的《個人資料保護法》、歐盟的 GDPR、美國的 HIPAA 等等），如果企業或機構需要使用或分享這些包含個資的資料，就需要先進行去識別化，以避免法律風險。

其實，「去識別化」不是醫療軟體獨有的技術，在一般軟體中，也是必須要被考慮的，不過雖然兩種類型的軟體都需要「去識別化」，醫療軟體與一般軟體的需要被去識別化的資料還是有一些不同。一般軟體的資料敏感度是比較低的，包含姓名、Email、一些消費紀錄等等；但是醫療軟體，可能會儲存病歷，以及手術影像、診斷號碼、健保卡號碼等等...。

若沒有做好隱私保護，醫療軟體不小心就將用戶的病況、隱私... 洩漏出去後，將他人的個資傳進別人的伺服器內，下一個被告的就是我。

去識別化真的有效嗎？

我們在討論去識別化的時候，可能會直覺地認為，只要把個人資料移除，這筆資料就不會被辨識出來。但實際上，事情並沒有那麼簡單。

原因在於，當我們把某些欄位移除之後，在特定情境下，我們還是有辦法透過其他方式，從剩下的資料中重新識別出資料當事人。

單一個欄位不具識別性，可是我們如果把它組合起來，可能就會具有獨特性。

像姓名、身分證字號屬於「直接識別碼」，通常會被移除；可是像出生年月日、郵遞區號、性別就屬於「準識別碼」。當我們把郵遞區號、出生年月日加上性別組合起來，就可以辨別出像是全美 87% 的人口。

另外，有些時候，系統會使用可逆的代碼、未加鹽的單向雜湊演算法來取代姓名或病歷號，攻擊者可利用暴力破解列舉所有可能的數值組合並計算雜湊，從而還原原始身份。

沿著資料流，看看還有哪些地方會洩漏

回到前面的血壓紀錄 App。假設我們在呼叫外部 AI 服務前，已經把姓名移除，只送出摘要需要的量測紀錄。不過，為了方便除錯，程式在處理資料時，先把包含姓名的完整紀錄寫進操作日誌。

這時候，送給 AI 的資料雖然經過處理，但是日誌裡仍然留著原始內容。如果日誌平台的存取權限設定過寬，原本不應該看到健康資料的人，就可能從另一個地方取得資料。

也就是說，我們需要沿著資料流繼續問：資料在哪裡被複製、留下來？哪些人有辦法接觸？如果有人想取得這些資料，他可能從哪裡下手？

這些問題可以整理成一個簡化的威脅模型。以前面的假設情境來看：

這只是其中一條假設路徑。我們還可以用同樣的方式，檢查本機資料庫、使用分析平台和外部 AI 服務。每增加一個資料接收者，就要再確認資料會如何被處理與保存。

小結

今天從一筆血壓紀錄出發，看到它可能被用於保存紀錄、追查操作、分析功能使用，以及產生 AI 摘要。用途不同，需要的資料也不同。

去識別化可以降低個人被辨識出來的風險，但還要看剩下的欄位能否與其他資訊連結，以及原始資料有沒有留在其他地方。因此，在使用或分享健康資料前，我們要先弄清楚用途與流向，再決定需要哪些欄位、誰能接觸，以及保存多久。

下一篇會接著討論身分驗證與授權：知道登入的人是誰之後，系統還要確認，他是否有權查看這筆健康紀錄。