電子病歷交換單張實作指引(EMR-IG)
0.1.0 - ci-build

This page is part of the 電子病歷交換單張實作指引(EMR-IG) (v0.1.0: Releases) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions

安全性

專案概述

本API規範需求源自於醫療領域中迫切需要確保醫療資料的安全性和有效性，以促進各種數位健康系統和應用程式之間的順暢交流。為實現這一目標，本架構定義明確的標準機制，以確保FHIR API的適當性和互通性。此外，在醫療應用程式的多樣性要求導入清晰的介接標準，以促進各種系統的順暢整合。在確保整合性的同時，資料安全架構著重於強化授權和身份驗證機制，以保障只有經過授權的應用程式和使用者能夠存取FHIR API，進而維護醫療資料的隱私和安全性。

為符合相關的法規、標準與應用情境，本規範基於醫療機構電子病歷製作與管理辦法、資通安全管理辦法以及SMART on FHIR制定，確保FHIR API的使用符合實務需求。最後，為監控和紀錄API的使用情況，本架構建立了相應的機制，以追蹤連線請求活動並紀錄相關資訊，以進行事後分析和追踪。

總體而言，這個文件旨在建立一套安全、互通且合規的FHIR API標準機制，以應對當前醫療領域的數位轉型需求。

文件目的與系統描述

FHIR資料交換應以保護隱私的方式交換電子健康紀錄，確保數據的機密性、完整性和可用性、並促進患者安全。醫療紀錄與大多數醫療服務提供者及其合作夥伴必須遵守「醫療機構電子病歷製作及管理辦法」、「個人資料保護法」以及其他相關資料安全規範來保護健康資訊。 然而，數字健康紀錄被越來越多的傳統醫療保健組織之外的新型組織管理、共享或使用，如數位化生理資訊整合廠商。為確保資料受到安全管理、完整的保護以及確保病人安全與隱私，應納入一套完善的授權機制，以因應實務操作與醫療服務需求。確保數位醫療資料的機密性、完整性和可用性對於提供安全照護並支持所有個人和社區的健康和福祉至關重要。當交換數位健康資料時，安全照護和健康的基本步驟由於將數據與個人正確配對開始，以便根據準確的資訊向正確的個人提供護理。在可能的情況下，完善的授權、驗證機制，並透過國際標準的FHIR API進行數據格式交換。在適用法律的範圍內，將制定政策來解決如何在其架構中強制執行同意和／或授權。並透過驗證機制監督適當的數位醫療資料取用、交換或使用應用。

名詞定義

參考自：數位發展部依國際標準訂定「共通性應用程式介面指引」

英文名稱 中文名稱 定義
API (Application Programming Interface) 應用程式介面 為「『電腦作業系統（Operating system）』或『程式函式庫』提供給應用程式呼叫使用的程式碼」。其主要目的是讓應用程式開發人員得以呼叫一組常式功能，而無須考慮其底層的原始碼為何、或理解其內部工作機制的細節。API本身是抽象的，它僅定義了一個介面，而不涉及應用程式在實際實現過程中的具體操作。
REST 含狀態傳輸 全名為Representational State Transfer，是一種軟體架構設計風格。資源由URI指定，對資源的操作包括取得、創建、修改和刪除資源，這些操作正好對應HTTP協議提供之GET、POST、PUT和DELETE方法。
RESTful 含狀態傳輸的 Web 服務 是一個使用HTTP並遵循REST原則，以 URL 定位資源，根據 HTTP 內容指示操作動作與回應訊息。
JSON - 一種常見的輕量級資料交換格式。

API介接機制

採用RESTful API架構，並使用JSON或XML進行數據交換，確保不同系統能夠理解和解析相同的數據。此架構使得通信變得簡單且輕量，通常使用HTTP協議進行。這種架構的特點包括有狀態的、可緩存的通信，使得介接更直觀和容易實現。

以下是 RESTful 架構的主要特點：

  1. 資源（Resources）：將所有資訊和功能都被視為資源，每個資源都有一個唯一的標識符（URI）。
  2. 表現層（Representation）：資源的狀態以及與之相關的操作應透過表現層進行描述，接受JSON、XML兩種格式，應依照實際需求進行採納。
  3. 狀態轉換（Stateless）：通訊的過程中，伺服器不保留連線端的狀態。每個請求從連線端包含所有必要的資訊(傳送資料、授權資料、驗證資料以及相關的附註說明)，伺服器在處理後不保留任何相關狀態。
  4. 統一接口（Uniform Interface）：使用統一接口進行標準化操作， GET（獲取資源）、POST（創建新資源）、PUT（更新資源）、DELETE（刪除資源）等。
  5. 無狀態通訊（Stateless Communication）：連線端和伺服器之間的通訊無狀態紀錄，每個請求都包含了足夠的資訊，伺服器不需要保留先前的請求狀態。

透過RESTful架構建構為輕量、簡單、易於擴展的架構。

資料存取授權架構

採用OAuth 2.0架構作為資料存取授權之基礎，OAuth 2.0是一個授權框架，用於授權第三方應用程式代表使用者查閱受保護的資源。定義了授權伺服器、連線端應用程式和資源伺服器之間的互動流程，以確保安全的資源連線請求。

  1. 授權（Authorization）：允許使用者授權應用程式查看其受保護的資源。
  2. 存取權杖（Token）：獲得授權後，應用程式會收到一個存取權杖（Access Token）。該存取權杖用於向受保護的資源發送請求，以獲取授權的資源。
  3. 使用者（Resource Owner）： 使用者是資源的擁有者，有權授權給應用程式查閱其受保護的資源。
  4. 用戶端（Client）： 用戶端是希望獲得使用者授權的應用程式。是應用程式、行動應用程式或其他任何需要查閱受保護資源的應用程式。
  5. 授權伺服器（Authorization Server）： 授權伺服器負責確認使用者或用戶端身份，並發放存取權杖給用戶端。這是整個 OAuth 流程的核心。
  6. 資源伺服器（Resource Server）： 資源伺服器是儲存受保護資源的地方。它驗證請求中的存取權杖，並確保用戶端有權查閱特定資源。


授權流程：


授權流程圖


圖 1 授權流程圖

  1. 使用者管理授權：使用者透過授權伺服器授權應用程式(用戶端)查閱其資源。

  2. 用戶端獲取授權碼：用戶端向授權伺服器發出請求，授權伺服器驗證身分後，返回一個授權碼給用戶端。

取得授權碼流程如下圖:


取得授權碼流程


用戶端應用程式應根據RFC 6749第 4.1.1 節請求授權代碼。授權伺服器應依照RFC 6749第 4.1.2 節處理和回應授權碼請求。

  1. 用戶端獲取存取權杖：用戶端使用用戶端帳號、用戶端密碼、授權碼向授權伺服器請求存取權杖。


取得授權碼流程


用戶端應用程式應根據RFC 6749第 4.1.3 節交換存取存取權杖的授權代碼。對於使用共用金鑰進行身份驗證的客戶端應用程序，用戶端應用程式和伺服器應遵循RFC 6749 第 4.1.3 節和第 4.1.4 節中的存取權杖請求和回應協定。 身份驗證存取權杖的最大生命週期應為 5 分鐘。授權伺服器可以忽略身份驗證存取權杖中任何無法識別的聲明。身份驗證存取權杖應使用 JSON 緊湊序列化方法進行簽名和序列化。

  1. 用戶端使用存取權杖查閱資源：用戶端使用獲得的存取權杖向資源伺服器發送請求，以查閱使用者受保護的資源。

連線請求被拒絕回應處理

當存在存取被拒絕的情況時，伺服器必須仔細選擇回應，該情況可能是由於缺少但必要的身份驗證、使用者無權存取、使用者無權存取特定資料或其他管理因素。

為了平衡回傳狀態結果的可用性與適當的保護，管理單位應依照以下情境進行回應:

  • 回傳 404 “未找到(Not Found)” - 如無相關資料，回傳此數值，唯獨應該嚴格控管用戶端存取狀態，因為此狀態表示需求條件的資源不存在，伺服器無法區分，但此狀態回應確實表示了用戶端身份驗證已驗證的情況。
  • 回傳 403“禁止(Forbidden)” - 這表示存取失敗的原因是授權失敗。
  • 回傳 401“未經授權(Unauthorized)” - 這表示已嘗試進行用戶身份驗證但未能通過身份驗證。

資料安全規範

FHIR API傳輸機制應遵守相關的資訊安全規範，包含「醫療機構電子病歷製作及管理辦法」、「個人資料保護法」。並應符合以下規範:

  1. 數據加密：
    傳輸層加密：所有與 FHIR API 之間的通訊應使用 HTTPS 協定，以 TLS/SSL 進行加密，確保在傳輸過程中的機密性和完整性。
    敏感數據加密：對於在傳輸和儲存過程中的敏感資料（如病歷訊息），應使用符合規範之加密演算法。

  2. 查閱與連接控制：
    OAuth 2.0 實施：採用 OAuth 2.0 標準，要求所有應用程式通過授權流程進行身份驗證和連線請求控制。
    使用者和角色授權：確保每個使用者(端點)只能查閱其授權範圍內的資源，並實施角色基礎的查閱控制。

  3. 監控：
    API 使用監控：實施即時監控機制，追蹤 API 的使用情況，包括請求次數、響應時間、錯誤率等。
    異常行為檢測：建立異常行為檢測機制，識別可能的安全威脅或異常活動。

  4. 日誌記錄：
    全面紀錄：記錄所有重要的事件，包括端點登入、授權操作、資源查閱、錯誤和安全事件等。
    格式化和時間戳：紀錄應以結構化的格式和具有明確的時間戳記，以便進行分析和審核。 合規性紀錄：符合相關法規和合規性標準，確保記錄滿足法定要求。

  5. 安全事件回應：
    通知和應對：當發現安全事件時，立即通知相關人員，並採取適當的應對措施，如中斷連線請求、重置憑證等。
    安全漏洞修復：在發現安全漏洞或弱點時，應立即修復，並進行相應的安全更新。

  6. 定期審查和更新：
    安全審查：定期進行安全性審查，檢查系統的安全性措施是否符合標準，並及時更新。
    合規性審查：確保系統符合相關的法規和相關管理辦法標準，並應於法規更新時進行相應的調整。

  7. 資訊安全培訓：
    培訓計畫：實施資訊安全培訓計畫，定期培訓開發人員、管理人員和其他相關人員，提高對安全性的意識。

  8. 合規性標準：
    HL7 FHIR 標準：符合 HL7 FHIR 標準，並依照臺灣核心規範（TW Core IG）更新以反映最新版本的標準。
    相關法規和標準： 遵循「醫療機構電子病歷製作及管理辦法」、「個人資料保護法」。

附則

除上述規範外，應依照實際應用情境、流程以及資料交換內容，遵循以下法規：

  • 醫療機構電子病歷製作及管理辦法
    如交換資料屬醫療機構以電子文件方式製作及貯存之病歷，應遵循此法之規範。
  • 資通安全管理法
    資料存取、使用、控制、洩漏、破壞、竄改、銷毀或其他侵害等過程，應遵循此法規範，完成事件通報、應變及處理。