前面的文章介紹了 FHIR Resource、API、Profile 與 TW Core IG。我們知道 FHIR 可以讓不同醫療系統以較一致的格式交換病人資料。
但當醫療資料交換變得更方便時，也會出現一個非常重要的問題：
只要系統支援 FHIR，是不是任何人都能透過 API 讀取病歷？
答案當然不是。
FHIR 解決的是醫療資料「如何表示及交換」的問題，不代表病歷可以毫無限制地公開。真正使用 FHIR 傳輸醫療資料時，仍然必須搭配身分驗證、權限管理、加密、稽核紀錄及病人同意等安全措施。
提到 API，很多人可能會聯想到天氣、地圖或政府開放資料。這些服務可能允許一般使用者查詢部分公開資訊。
但是，FHIR API 傳輸的內容可能包含：
這些都屬於高度敏感的個人醫療資料。
因此，FHIR API 通常不是任何人取得網址後就能任意存取的公開服務。系統必須先確認使用者的身分、判斷其權限，並限制可以取得的病人與資料範圍。
FHIR 提供醫療資料交換的標準架構，也包含與安全及隱私相關的 Resource 和建議，但它不會自動替系統完成所有資安保護。
FHIR 不會因為資料使用 JSON 格式，就自動完成：
這些功能仍然需要由實際的醫療資訊系統、API 平台與組織管理制度負責。
可以將 FHIR 想成醫療資料的共同語言。即使大家使用相同語言溝通，也仍然需要確認談話對象是誰、對方可以知道多少資訊，以及對話過程會不會被其他人偷聽。
一般的帳號密碼若外洩，可能還有機會更換，但一個人的疾病、就醫及檢驗紀錄無法像密碼一樣重新設定。
醫療資料外洩可能造成：
在台灣，《個人資料保護法》第6條將病歷、醫療、基因、性生活、健康檢查及犯罪前科等資料列為原則上不得蒐集、處理或利用的資料，但法律同時規定特定例外情形與必要條件。
這代表醫療資料並非完全不能使用，而是必須具備合法目的與適當依據，並採取相應的安全保護措施。
資訊安全經常使用三個基本目標來說明保護需求。
| 目標 | 意義 | 醫療情境範例 |
|---|---|---|
| 機密性 | 資料只能由獲得授權的人查看 | 非照護相關人員不能任意讀取病歷 |
| 完整性 | 資料不能遭到未授權竄改 | 檢驗結果不能在傳輸途中被修改 |
| 可用性 | 獲得授權的人需要時可以使用資料 | 急診醫師能在必要時取得病人資料 |
安全不只是「不讓別人看到」。如果系統保護得過度嚴格，導致醫師在緊急情況下無法取得必要資訊，也可能影響病人安全。
因此，醫療資訊安全必須在隱私保護、臨床需求與系統可用性之間取得平衡。
身分驗證是確認「你是誰」。
例如，當醫師、護理師、藥師、病人或第三方應用程式要存取 FHIR API 時，系統必須先確認提出要求的一方是否具有真實且可信的身分。
常見的身分驗證因素包括：
如果只知道某位醫師的帳號，卻沒有通過正確的身分驗證，就不應該被視為該名醫師本人。
在重要系統中，也可能採用多因素驗證，降低密碼外洩後帳號立即遭到冒用的風險。
通過身分驗證，只能證明使用者是誰，並不代表他可以查看所有病歷。
授權要處理的是：
這個人可以做什麼？
例如：
即使兩位使用者都成功登入，他們能取得的 Resource、病人範圍及操作方式也可能完全不同。
醫療系統可能依據不同條件決定是否開放資料。
系統根據使用者的角色分配權限，例如醫師、護理師、藥師或行政人員。
這種方式容易理解，但如果只看職稱，可能不夠精確。某位醫師並不代表可以查看全院所有病人的病歷。
系統可以同時考慮多種條件，例如：
這種方式能更細緻地判斷權限，但規則也較複雜。
不論採用哪種方式，核心原則都是只提供完成工作所需要的適當權限，而不是成功登入後就能看到全部資料。
醫療資料交換並不是資料越多越好。
假設某個應用程式只需要顯示病人的預約時間，就不一定需要同時取得完整診斷、用藥與檢驗紀錄。
這與兩個重要原則有關：
如果一個系統只需要讀取資料，就不應該同時取得修改或刪除資料的權限；如果只需要 Observation，也不應該自動取得病人的所有 Resource。
限制資料範圍，可以降低帳號或應用程式遭到濫用時造成的影響。
FHIR 定義醫療資料格式，但應用程式仍需要安全地取得存取權限。這時經常會提到 SMART on FHIR。
SMART on FHIR 是建立在 FHIR、OAuth 2.0 與 OpenID Connect 等技術上的應用授權架構，讓醫療應用程式可以在受到控制的情況下存取 FHIR 資料。
它主要處理的問題包括：
例如，一個病人健康管理程式可以申請讀取該名病人的部分健康資料，但不代表它能查看所有病人的資料，也不代表它能修改醫院的完整病歷。
在授權過程中，Scope 可以用來描述應用程式申請的權限範圍。
概念上，它可以區分：
因此，權限不是單純的「允許」或「拒絕」，而是可以細分成：
誰，在什麼情境下，因為什麼目的，可以對哪些資料進行哪些操作？
這樣才能避免應用程式取得超過實際需求的權限。
不一定。
病人的同意可能包含不同條件，例如：
FHIR 提供 Consent Resource，可以表達與同意及隱私授權相關的資訊。
但是，建立一筆 Consent Resource 並不代表系統已經自動符合所有法規。實際上仍須配合當地法律、醫療機構政策與存取控制機制。
此外，醫療資料的合法使用也不一定全部建立在病人同意上。特定的醫療照護、公務、法律義務或研究情境，可能有不同的法律依據與條件，不能只用一句「病人有同意」概括所有情況。
FHIR 資料可能透過網路在不同系統之間傳送。如果傳輸過程沒有適當保護，資料就可能遭到攔截或竄改。
因此，正式環境通常需要使用安全的加密連線，例如 HTTPS 所使用的 TLS，保護傳輸中的資料。
加密可以降低第三方直接讀取資料內容的風險，但加密也不是完整的資安方案。
即使傳輸過程已經加密，如果：
仍然可能發生資料外洩。
因此，加密只是整體安全措施的一部分。
醫療系統除了限制存取，也需要留下適當的稽核紀錄。
FHIR 提供 AuditEvent Resource，用來記錄與安全或隱私相關的事件，例如：
稽核紀錄可以協助醫療機構進行：
如果某個帳號在短時間內大量查閱與工作無關的病歷，稽核資料就可能成為發現異常的重要線索。
不過，稽核紀錄本身也可能包含敏感資訊，因此同樣需要受到權限與安全管理。
除了記錄誰存取資料之外，醫療系統還需要了解資料的來源與變更過程。
FHIR 的 Provenance Resource 可以表達：
AuditEvent 比較關注系統中發生的安全或操作事件；Provenance 則比較關注一筆資料的來源、建立與變更歷程。
| Resource | 主要關注內容 |
|---|---|
| AuditEvent | 誰在何時執行了什麼系統操作 |
| Provenance | 這筆資料如何產生、由誰建立或修改 |
| Consent | 資料主體的同意與授權規則 |
三者從不同角度協助醫療資料的安全、可信度與責任追蹤。
FHIR Resource 的 meta.security 可以放置 Security Label，標示資料的安全或隱私屬性。
例如，不同資料可能具有不同的機密程度，或只能用於特定目的。
不過，Security Label 只是提供系統判斷的資訊，不會自動阻止未授權存取。真正是否允許讀取，仍須由存取控制政策及系統程式進行判斷。
可以把它想成文件上的「機密」標籤。標籤提醒系統應如何處理文件，但仍然需要門禁、權限規則與人員管理，才能真正保護內容。
醫療資料若要用於研究或統計，可能會移除姓名、身分證統一編號等直接識別資訊，這類處理常被稱為去識別化。
但是，拿掉姓名不代表資料一定無法辨識個人。
如果資料中仍然包含：
仍可能產生重新識別的風險。
因此，去識別化需要考慮整體資料內容、使用目的、資料環境及重新識別可能性，而不是只刪除姓名就完成。
假設一名醫院行政人員成功登入院內系統，是否代表他可以查看任何病人的完整病歷？
不可以。
系統還應考慮：
同樣地，醫療人員即使具有臨床職務，也不代表可以因為好奇而查看與自己工作無關的病人資料。
「具有帳號」與「具有合理存取權限」是兩件不同的事。
一個處理真實病歷的 FHIR 系統，通常需要從多個層面進行保護。
| 保護層面 | 目的 |
|---|---|
| 身分驗證 | 確認使用者或應用程式的身分 |
| 授權管理 | 限制可存取的病人、Resource 與操作 |
| 傳輸加密 | 保護資料在網路傳送過程中的機密性 |
| 儲存保護 | 保護資料庫、備份與裝置中的資料 |
| 稽核紀錄 | 追蹤誰曾經存取或修改資料 |
| 同意管理 | 記錄及執行適用的病人授權規則 |
| 資料最小化 | 避免提供超過用途所需的資料 |
| 弱點與更新管理 | 降低系統漏洞遭到利用的風險 |
| 人員與制度管理 | 降低帳號共用、誤用及內部濫用風險 |
| 事件應變 | 發生異常時能及時控制、調查與處理 |
由此可見，FHIR 資安不是只靠某一項技術完成，而是技術、流程、制度及人員共同組成的防護。
FHIR 能讓醫療資料以標準格式交換，但不代表病歷可以直接公開。FHIR 解決的是資料結構與交換方式，真正的安全仍然需要醫療系統與管理制度共同負責。
一套安全的 FHIR 資料交換機制，需要先確認使用者身分，再依照角色、照護關係、使用目的及資料敏感程度決定權限，同時搭配傳輸加密、最小權限、病人同意及稽核紀錄等措施。
FHIR 也提供 Consent、AuditEvent、Provenance 與 Security Label 等設計，協助系統表達同意、事件紀錄、資料來源及敏感程度。不過，這些 Resource 與標籤本身並不會自動完成安全控管，仍然必須配合實際的資安機制與適用法規。
下一篇將進入 Day 29｜把一次門診資料串起來：Resource 如何互相連結？，把前面介紹過的 Patient、Encounter、Condition、Observation、MedicationRequest 與 DiagnosticReport 放回同一個門診情境中，理解它們彼此之間的關係。
iThome鐵人賽
看影片追技術