EHR Healthcare
一句話描述:一家服務多家醫療院所、保管大量電子病歷資料的 SaaS 公司,必須在 HIPAA 合規、零停機容忍、跨區 DR 的三重壓力下,把關鍵系統從舊機房搬到 GCP。
🏢 商業背景
電子病歷(Electronic Health Record, EHR)是醫療院所的神經中樞:醫師下處方、護理師給藥、藥局調劑、健保申報、保險理賠,全部串在這套系統上。系統一停,急診室的醫師就無法查詢患者過敏史,手術室的流程會被迫延後—這不只是營運問題,更直接影響病人安全。因此醫療 SaaS 跟一般企業軟體最大的差別,是 SLA 要做到接近 100%,而且必須用「年可停機分鐘數」而不是「三個九」來看待。
從規模看,一家中型 EHR SaaS 公司的用戶可能涵蓋數百家診所、數十家中大型醫院,同時線上使用者可達數萬人,每天產生數十萬筆診療紀錄、影像檔案(X 光、MRI、CT)動輒每份數十 MB 到數 GB。這些資料不只量大,而且屬於最敏感的「受保護健康資訊」(PHI),在美國受 HIPAA 規範,在歐盟受 GDPR 規範,在台灣受個資法與醫療法雙重約束—任何外洩都可能讓公司直接倒閉。
商業上還有一個常被忽略的現實:醫療資料的保留期限極長。美國 HIPAA 要求保留 6 年以上,部分州要求兒童病歷保留到病人成年後數年,加總起來單一病歷可能存在系統裡 20-30 年。這讓「長期冷儲存 + 加密金鑰管理 + 可稽核存取紀錄」成為架構設計的硬需求,不是 nice-to-have。
⚡ 主要技術挑戰
- HIPAA 合規必須落地到每一層從 IAM、加密、稽核日誌到資料出境,每一個 GCP 服務都要有對應控制,而且要能向稽核員舉證。
- 零停機遷移舊系統搬到 GCP 的過程,醫院病患還在掛號、醫師還在開藥,不允許週末維護視窗。
- 跨區 DR + 低 RPO/RTO不能只備份,要做 active-active 或 active-passive 架構,讓區域故障時服務仍能繼續。
- 資料外洩風險極高單次洩漏事件的罰款與訴訟成本可能達數百萬美元,防禦必須是 defense-in-depth。
- 長期合規保留病歷要存 10-20 年以上,成本要合理但又不能為了省錢犧牲可讀性與可稽核性。
🏗️ 建議 GCP 架構
這個案例的核心是「隔離 + 加密 + 可稽核」。建議採用:單一 Organization 下分多個 Project(prod / staging / audit),所有 PHI 資料置於 VPC Service Controls 周邊防護圈內;運算層用 GKE 私有叢集、禁用 external IP;資料庫用 Cloud SQL 跨區 HA + Cloud Healthcare API 管 FHIR/DICOM 資料;影像檔案走 Cloud Storage 配 CMEK(客戶管理加密金鑰);所有 API 呼叫都經 Cloud Audit Logs 記錄並匯入 BigQuery + Security Command Center。遷移策略採「並行運作 + 逐院切換」,把每家醫院視為獨立 cohort 分批移轉。
[醫院端 / 醫師 / 行政]
│ (TLS 1.3 + Identity-Aware Proxy)
▼
┌─────────────────────────┐
│ External HTTPS LB │
│ + Cloud Armor (WAF) │
└──────────┬──────────────┘
│
┌─────────────────────┴──────────────────────┐
│ VPC Service Controls Perimeter (PHI 禁區) │
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ GKE Private │ │ Cloud │ │
│ │ Cluster (us) │ │ Healthcare │ │
│ │ Region A │◄──►│ API │ │
│ └──────┬───────┘ │ (FHIR/DICOM) │ │
│ │ └──────┬───────┘ │
│ ▼ │ │
│ ┌──────────────┐ ▼ │
│ │ Cloud SQL │ ┌──────────────┐ │
│ │ (HA + CMEK) │ │ Cloud Storage│ │
│ │ 跨區備援 │ │ (CMEK, 影像) │ │
│ └──────────────┘ └──────────────┘ │
│ ▲ │
│ ┌───────┴────────┐ │
│ │ Cloud SQL │ [Region B DR site] │
│ │ read replica │ │
│ └────────────────┘ │
└─────────────────────────────────────────────┘
│
▼
┌──────────────────────┐
│ Cloud Audit Logs │──► BigQuery (合規查詢)
│ + Security Command │──► Cloud Monitoring alerts
│ Center │
└──────────────────────┘
為什麼堅持 VPC Service Controls?這是 GCP 上防止「API 層級資料外流」的關鍵機制—即使攻擊者拿到有效的服務帳號憑證,只要他不在 perimeter 內部,也不能把 PHI 複製到外部 bucket。為什麼用 Cloud Healthcare API 而不是自己建 FHIR server?它原生支援 FHIR R4、DICOM、HL7 v2 的解析,並且通過 HIPAA 認證,可大幅縮短合規舉證時間。為什麼影像檔用 CMEK?金鑰在 Cloud KMS 由客戶管理,即使 Google 員工也無法存取資料—這是醫療合規稽核會檢視的重點。
🎯 關鍵設計決策
| 決策 | 選這個的理由 | 替代方案 |
|---|---|---|
| VPC Service Controls 包圍所有 PHI | API 層級的邊界防護,能擋住「憑證外洩 + 跨 Project 搬資料」這類攻擊路徑,這是 HIPAA 合規硬需求 | 單純 IAM + firewall(擋不住 API 層外流)、自建 proxy(維運成本高且無第三方認證) |
| Cloud SQL 跨區 HA + CMEK | 跨區主備可達 RPO 小於 1 分鐘、RTO 小於 5 分鐘;CMEK 讓金鑰由公司自控,符合 HIPAA BAA 要求 | BigQuery(不適合線上交易)、Spanner(成本高且 HIPAA 目前主流仍用 Cloud SQL) |
| 逐院 cohort 遷移策略 | 每家醫院獨立切換,風險隔離,單一醫院出問題可立即回滾而不影響其他客戶 | 全量同時切換(風險集中、一旦失敗影響全部客戶)、DNS 分流(舊系統仍是單點) |
📝 PCA 考點拆解
考點 1:VPC Service Controls vs IAM 差別
題目出現「防止 service account 被濫用把資料搬到外部 Project」「符合 HIPAA / PCI 邊界要求」這類描述,答案就是 VPC Service Controls。IAM 管「誰可以呼叫 API」,VPC-SC 管「這個 API 呼叫是從哪個網路周邊發出」,兩者缺一不可。
考點 2:CMEK vs Google-managed keys
金融、醫療、政府案例幾乎都會考這題。Google-managed keys 預設就有、夠用但金鑰生命週期由 Google 控制;CMEK 讓客戶在 Cloud KMS 管金鑰、可輪替、可吊銷,符合稽核要求;CSEK 則是客戶提供金鑰材料,最高控制權但管理負擔大。
考點 3:RPO / RTO 與 DR 分級
題目問 DR 策略時,要能分辨 backup/restore(RTO 幾小時)、pilot light(RTO 30 分鐘-1 小時)、warm standby(RTO 幾分鐘)、multi-region active-active(RTO 秒級)。醫療場景通常是最後兩者。
考點 4:Cloud Audit Logs 的四個類別
合規案例必考:Admin Activity(預設啟用、免費)、Data Access(必須啟用,HIPAA 要求)、System Event(預設)、Policy Denied(預設)。醫療場景下 Data Access log 是合規稽核的命脈。
換你練習
合規場景是 PCA 考試最容易丟分的部分。到 PCA 架構師設計工作坊 把 EHR Healthcare 當情境,重點走完「網路與安全」「災難復原」「資料治理」三步—把 VPC-SC、CMEK、跨區 DR 的搭配實際畫一次,遠勝反覆翻答案。
前往工作坊🔗 延伸閱讀
- Google Cloud 官方 PCA exam guide — 原始情境敘述來源
- GCP HIPAA 合規指引 — 官方 HIPAA 覆蓋範圍與責任切分
- VPC Service Controls 官方文件 — 邊界防護設計原則
- Cloud Healthcare API — FHIR / DICOM / HL7 v2 的 managed service