本頁面說明如何使用 SMART (可替換醫療應用程式、可重複使用的技術) 在 FHIR 1.1.0 版標準中,存取 Cloud Healthcare API 中的 FHIR 儲存庫資料。
總覽
SMART on FHIR 是一種資料標準,可讓應用程式存取電子健康記錄 (EHR) 系統中的資訊。應用程式開發人員可以編寫單一應用程式,連結至任何採用此標準的電子病歷系統。
舉例來說,如果您將病患資料儲存在 Cloud Healthcare API 中的 FHIR 儲存庫中,就可以開發應用程式來執行以下操作:
- 向 FHIR 儲存庫進行驗證。
- 擷取病患的資料。
- 在使用者介面中顯示病患資料。
FHIR 上的 SMART 支援 OpenID 和 OAuth 2.0 授權模型,可用於授權和驗證。
SMART 應用程式啟動架構、範圍和啟動內容
Cloud Healthcare API 支援 SMART 應用程式啟動架構、範圍和啟動情境,如下所示:
- SMART 應用程式啟動架構
Cloud Healthcare API 支援 SMART 應用程式啟動架構的獨立啟動序列。
應用程式可在現有的電子病歷系統或患者入口平台工作階段中啟動,這兩種情況都稱為「電子病歷啟動」,或稱為獨立應用程式。
- 範圍
臨床資料範圍會定義患者專屬和使用者層級存取權的讀取和寫入權限。Cloud Healthcare API 支援下列資料範圍,如要求臨床資料的範圍所定義:
patient
user
system
- 啟動背景
說明目前的患者、接觸情形或其他提出要求的背景。Cloud Healthcare API 支援來自用於要求背景資料的範圍的病患啟動背景。
設定 FHIR 上的 SMART 授權伺服器
Cloud Healthcare API 提供內建支援,可根據輸入的 SMART 授權範圍和病患背景,強制執行 FHIR 的 SMART。FHIR 儲存庫管理員會在 Cloud Healthcare API 外建立及設定授權伺服器,授予 SMART 授權範圍和病患背景資訊。
如果用戶端應用程式取得代表核准 SMART 授權範圍和病患背景的存取權權杖,Cloud Healthcare API 不會指定用戶端應用程式需要與外部授權伺服器搭配使用的啟動工作流程。
設定及驗證 SMART 授權範圍
如果您使用的是 SMARTProxy,可以略過本節。SMARTProxy 會自動設定及驗證 SMART 授權範圍。
SMART 授權範圍採用以下格式:
( 'patient' | 'user' | 'system') '/' ( resourceType | '*' ) '.' ( 'read' | 'write' | '*' )
系統會使用 X-Authorization-
HTTP 標頭,將 SMART 授權範圍和病患背景傳遞至 Cloud Healthcare API。Cloud Healthcare API 會使用這些標頭,對 FHIR 儲存庫中的資料強制執行存取權控管。
您的授權伺服器會授予 SMART 授權範圍和病患背景資訊,並在存取權杖中加密這些資訊。然後 Proxy 會讀取存取權憑證中的資訊,並將其傳遞至 FHIR 要求標頭。
如果您沒有授權伺服器,可以使用 Apigee 上的 HealthAPIx 加速器,加速 Apigee 互通性。
透過 Proxy 提出要求時,請使用下列 SMART on FHIR HTTP 標頭。用戶端應用程式不需要設定這些標頭,因為這些標頭只會從 Proxy 傳遞至 Cloud Healthcare API。
X-Authorization-Scope
:使用標準 SMART 授權範圍格式的一或多個授權範圍。舉例來說,將授權範圍設為user/Observation.read
表示要求只能讀取 Observation 資源。Cloud Healthcare API 會強制執行這項存取權控管機制。X-Authorization-Patient
:要求的病患背景資訊。設定這個標頭時,要求中任何可位於病患區的資源類型,都必須屬於所提供病患 ID 的病患區。Cloud Healthcare API 會強制執行這項存取控制機制。X-Authorization-Subject
:存取 FHIR 用戶端應用程式中的 SMART 的使用者 ID。Cloud Healthcare API 會將主題記錄在稽核記錄中。X-Authorization-Issuer
:SMART 存取權杖發出者。Cloud Healthcare API 會在稽核記錄中記錄發出者。
設定授權伺服器存取權權杖
如要發出 JWT 權杖,您必須設定授權伺服器。JWT 權杖包含 SMART 授權範圍,以及選用的病患背景資訊。Cloud Healthcare API 並未針對授權伺服器如何鑄造 SMART JWT 權杖提出特定要求。舉例來說,您的應用程式可能會針對部分範圍註冊,或是顯示病患選取小工具來設定病患背景。
如果您沒有設定 SMART JWT 權杖的授權伺服器,可以在 Apigee 上使用以 Apigee 為基礎的互通性加速器 HealthAPIx,設定簽署 JWT 權杖的驗證伺服器。
範例存取權杖
下列範例顯示以 base64 編碼的存取權杖:
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzM4NCJ9.eyJpc3MiOiJzbWFydC50b2tlbi5vcmciLCJpYXQiOjE2MTI4ODQwODUsImV4cCI6MTY0NDQyMDA4NSwiYXVkIjoid3d3LmV4YW1wbGUuY29tIiwic3ViIjoiZG9jdG9yLmpvZUBleGFtcGxlLmNvbSIsInNjb3BlIjoidXNlci9QcmFjdGl0aW9uZXIucmVhZCBwYXRpZW50LyouKiIsInBhdGllbnQiOiJwYXRpZW50MTIzIn0.lC0ouNuXNcj7FxQ83NU_MInULWo0wvyiNuaMt2RbFzBOnnMP_IXJdCeNnw3SQzUV
解碼存取權權杖後,權杖會包含下列酬載:
{
"iss": "smart.token.org",
"iat": 1612884085,
"exp": 1644420085,
"aud": "www.example.com",
"sub": "doctor.gabriela@example.com",
"scope": "user/Practitioner.read patient/*.*",
"patient": "patient123"
}
在 Cloud Healthcare API 中設定 FHIR 的 SMART
本節說明如何開始使用 Cloud Healthcare API 中的資料,在 FHIR 上使用 SMART。
設定 SMARTProxy
如果您使用的是自家的授權伺服器 (而非 SMARTProxy),請略過本節,繼續設定 Google Cloud 服務帳戶。
SMARTProxy 是 Google 推出的開放原始碼 Proxy,提供下列功能:
- 允許 Cloud Healthcare API 接受及驗證 SMART 存取權權杖。
- 允許 Cloud Healthcare API 中的 FHIR 實作項目,將 SMART 存取權杖納入 API 管理和權限模型。
當您透過 SMARTProxy 提出要求,從 Cloud Healthcare API 擷取資料時,要求會依照下列步驟執行:
- SMARTProxy 會接受來自用戶端的含有 SMART 權杖的要求。
- SMARTProxy 會透過 JWT 授權伺服器驗證 SMART 權杖。
- SMARTProxy 會從 SMART 權杖讀取範圍和病患背景資訊,並使用四個 HTTP 標頭將這些資訊傳遞至 Cloud Healthcare API。
- Cloud Healthcare API 會接收標頭並驗證,以便對要求實施存取權控管。接著,Cloud Healthcare API 會透過 SMARTProxy 將回應傳回給用戶端。
設定 Google Cloud 服務帳戶
代理程式只能有一個 Google Cloud 服務帳戶。如果有多個用戶端使用相同的 Proxy,則用戶端必須使用相同的服務帳戶。請注意,以下幾點原因不建議您與多個用戶端共用服務帳戶:
- 為了讀取 Cloud Healthcare API 中的 FHIR 資料,服務帳戶擁有廣泛的讀取和寫入權限。
Cloud 稽核記錄的主體電子郵件地址會與服務帳戶綁定。
舉例來說,如果您使用 Google 帳戶呼叫 Cloud Healthcare API 進行驗證,Cloud 稽核記錄會將您的電子郵件地址記錄為主要電子郵件地址。當您使用 Proxy 呼叫 Cloud Healthcare API 時,Proxy 會使用自己的服務帳戶,而服務帳戶的電子郵件地址就是主要電子郵件地址,因此原始呼叫端會遭到遮蔽。如要將使用者儲存至稽核記錄的中繼資料,請在 JWT 權杖的
sub
欄位中傳入使用者的電子郵件地址。
設定 FHIR 儲存庫
您不需要設定儲存您要存取的 FHIR 資料的 FHIR 儲存庫。
提出 FHIR 的 SMART 要求
本節將概略說明 Cloud Healthcare API 支援的 FHIR 的 SMART 方法,以及在提出 FHIR 的 SMART 要求時,如何強制執行資源存取權。
提出要求時,授權伺服器會負責使用相關的 SMART 授權範圍和啟動內容產生存取權杖。
支援的方法
Cloud Healthcare API 支援所有 projects.locations.datasets.fhirStores.fhir
方法的 FHIR 的 SMART,但以下方法除外:
資源存取權強制執行
向 FHIR 儲存庫提出 SMART on FHIR 要求時,存取控管會依下列順序進行:
- Cloud Healthcare API 會檢查在 Proxy 中設定的 Google Cloud服務帳戶權限。如果服務帳戶在 FHIR 儲存庫中具有正確的 IAM 權限,要求就會繼續處理。
- Cloud Healthcare API 會驗證 SMART 權杖是否具備適當權限,可存取要求中要求的每項 FHIR 資源。
病患專區對於 Cloud Healthcare API 中的存取權執行邏輯至關重要。SMART on FHIR 提供可納入病患區塊的 FHIR 資源類型清單。資源類型也有自己的納入條件。在本節的其餘部分中,符合資格的資源類型稱為「患者區隔適用的資源類型」。不符合資格的資源類型稱為「不符合病人隔間資格的資源類型」。
針對 FHIR 存放區提出的 SMART on FHIR 要求,必須符合下列規定:
在 SMART 授權範圍中提供
patient
、user
或system
角色。如果您提供patient
角色,則必須提供病患背景資訊。病患背景資訊是病患資源的邏輯 ID。病患資源必須已存在 FHIR 儲存庫中,或在提出要求後才存在,否則 Cloud Healthcare API 會拒絕要求。建立、讀取、更新或刪除資源時,
resourceType
和作業類型 (read
或write
) 必須相符,否則 Cloud Healthcare API 會拒絕要求。如果您提供的
patient
範圍包含不符合病患區隔資格的資源類型 (例如patient/Practitioner.*
),範圍驗證檢查就會失敗,Cloud Healthcare API 也會拒絕該範圍。您可以使用
user
範圍設定所有資源類型。如果病患背景資訊包含user
範圍,則病患區隔適用的資源類型會限制在病患背景資訊。其餘資源類型會忽略病患背景資訊。病患背景資訊的存在會將病患隔間適用資源類型限制在特定病患。舉例來說,Observation 資源必須包含
subject
欄位,才能參照指定的 Patient 資源,讓 Observation 可供存取。如要查看各病患區塊資源類型必須參照給定病患的欄位清單,以便將資源視為位於病患區塊內,請參閱「資源區塊定義 - 內容」中的病患區塊存取類型。要求可同時包含
patient
和user
範圍。請勿將
system
範圍與病患背景搭配使用,否則要求會失敗。請勿將
system
範圍與patient
範圍或user
範圍搭配使用。如果您呼叫的為存取多個資源的方法 (例如
fhir.Patient-everything
、fhir.executeBundle
或fhir.search
方法),則存取控制會套用至每個個別資源。