本文描述 Azure 上取用者健康數位入口網站的範例架構，此架構可促進醫療照護提供者與患者之間的通訊。 此外，此平台可儲存醫療記錄、醫療影像、允許病患追蹤健康資料等。
架構
下載此架構的 Visio 檔案。
工作流程
- 此解決方案使用 Azure Front Door 的全球使用量和 Azure Web 應用程式防火牆 (WAF) 的邊緣安全功能來驗證傳入資料。
- 經過驗證的資料會由 Azure API 觀禮 (APIM) 路由至 Azure 應用程式服務上的使用者前端介面，或是 Azure Functions 中託管的 API。
此架構使用的主要後端資料服務是 Azure Cosmos DB。 Azure Cosmos DB 的多模型能力，以及其可擴展性和安全性，讓任何類型的取用者健康入口網站都能靈活運用。 任何非記錄格式的資料都會以物件的格式儲存在 Azure Blob 儲存體中。 這些資料可能包括醫療影像、取用者拍攝的相片、上傳的文件、歸檔資料等。 Blob 儲存體為大量非結構化資料提供經濟實惠的儲存方式。 此類資料未針對 Azure Cosmos DB 的儲存進行最佳化，可能會對其成本和效能造成負面影響。
元件
Azure HIPAA HITRUST 9.2 藍圖是使用 Azure 原則的 Azure 藍圖。 有助於評估 HIPAA HITRUST 9.2 控制，並為 Azure 工作負載部署一套核心原則。 雖然這並不能完全符合 HIPAA HITRUST 的規範，但它是一個很好的起點，可以在適用和必要的情況下增加更多的控制。 在此藍圖和適用於雲端的 Microsoft Defender 的介面中，也視覺化原則倡議的合規性。
Azure Front Door 用於管理大規模的邊緣流量，並透過呈現世界各地的端點來提高終端使用者的效能。 此技術是雲端原生技術，不需要任何授權；您只需為使用的內容付費。 在此工作負載情境中，Azure Front Door 充當取用者健康入口網站所有流量的輸入點。
Azure Web 應用程式防火牆可保護應用程式免受常見的網頁式攻擊，例如 OWASP 漏洞、SQL 隱碼攻擊、跨站指令碼等。 此技術是雲端原生技術，不需要任何授權，隨用隨付。
Azure API 管理有助於發佈、路由、保護、記錄和分析 API。 無論 API 是僅供終端使用者使用，或是與第三方整合以提供外部互通性，API 管理都可彈性處理 API 的擴充與呈現方式。
Azure 應用程式服務是用來託管 HTTP 型的 Web 服務的服務。 它支援多種語言，可在 Linux 或 Windows 上執行，與 CI/CD 管線完全整合，甚至可以作為 PaaS 產品執行容器工作負載。 應用程式服務除了與 Azure 的身分、安全性和記錄服務原生整合外，還允許向上擴展和向外縮放。 能夠滿足取用者健康入口網站的擴展需求，同時維持合規性。 在此架構中，託管前端 Web 入口網站。
Azure 函數應用程式是 Azure 上的無伺服器平台解決方案，可讓開發人員撰寫隨選計算的程式碼，而無需維護任何基礎系統。 在此架構中，Azure Functions 可託管 API，以及任何需要以異步方式完成的工作，例如執行定期工作和計算某段時間內的統計資料。
Azure Cosmos DB 是一款全面管理的多模型 NoSQL 資料庫產品，可提供個位數字的回應時間，並可在任何規模下保證效能。 取用者健康系統中的每位使用者都只有與自己相關的資料，這也是使用 NoSQL 資料結構的理由。 Azure Cosmos DB 擁有近乎無限的規模，以及多區域讀寫功能。 隨著這些類型的取用者健康系統所收集的資料量急遽成長，不論是有 100 個或 1,000,000 個活躍使用者，Azure Cosmos DB 都可以提供適當的安全性、速度和規模。
Azure Key Vault 是 Azure 原生服務，用於安全地儲存和存取機密、金鑰和憑證。 金鑰保存庫允許 HSM 支援的安全性，以及透過 Microsoft Entra 整合式角色存取控制進行稽核的存取。 這些應用程式絕不應在本機儲存金鑰或機密。 此架構使用 Azure Key Vault 來儲存所有機密，例如 API 金鑰、密碼、加密金鑰和憑證。
Azure Active Directory B2C 以巨大的規模提供商業對取用者的身分即服務，其成本會隨著您的活躍使用者數量而增加。 在此解決方案等面向取用者的應用程式中，使用者可能不需要建立新帳號，而是希望使用自己的身分。 它可以是任何社交識別碼、電子郵件帳戶或任何 SAML 提供者識別服務。 此方法可為使用者提供更輕鬆的上架體驗。 解決方案提供者只需參考使用者身分，而無需託管與維護。
Azure Log Analytics 是 Azure 監視器記錄工具，可用於診斷或記錄資訊，以及查詢這些資料，以對其進行排序、篩選或視覺化。 此服務依使用量計價，非常適合託管此解決方案中所有服務的診斷與使用記錄。
Azure Application Insights 是 Azure 監視器的另一項功能，是 Azure 中的原生應用程式效能管理 (APM) 服務。 可以輕鬆整合到前端應用程式服務以及所有 Azure Functions 程式碼中，以即時監控這些應用程式。 Application Insights 可以輕鬆地偵測到應用程式本身直接產生的效能、可用性異常和故障，而不只是來自託管這些應用程式的計算平台。
Azure 通訊服務是使用 REST API 和用戶端程式庫 SDK 的雲端式服務，可協助您將通訊整合至應用程式。 您不需要成為媒體編碼或電話語音等底層技術的專家，就可以將通訊新增至您的應用程式。 在此解決方案中，它可用於傳送與取用者健康入口網站相關的任何電子郵件、簡訊或自動電話，例如預約確認或提醒。
Azure 通知中樞是一個簡單且可擴展的推播通知引擎，可讓您傳送通知至任何行動平台。 使用行動應用程式的取用者健康入口網站可與 Azure 通知中樞整合，以符合成本效益的方式將通知推送給在行動裝置上安裝應用程式的使用者。 在此架構中，可傳送通知以提醒使用者約會、輸入斷線裝置的資訊、達到特定的健康目標等。
適用於雲端的 Microsoft Defender) 是這整個雲端原生解決方案的安全監控與勢態管理核心。 Microsoft Defender for Cloud 整合了 Azure 平台上幾乎所有的主要服務。 其功能包括安全警示、異常偵測、最佳實務建議、法規遵循分數以及威脅偵測。 除了 HIPAA/HITRUST 法規遵循監控，以及整體 Azure 安全性最佳實務監控外，此解決方案還使用下列功能集：
替代項目
Azure FHIR 服務作為 Azure 健康資料服務的一部分，可用於使用 HL7 或 FHIR 通訊標準的醫療記錄互通性。 如果您的應用程式需要從其他系統接收或傳輸醫療記錄，則應使用此服務。 例如，如果此解決方案是醫療提供者的入口網站，適用於 FHIR 的 Azure API 可以直接與提供者的電子醫療記錄系統整合。
Azure IoT 中樞是專為擷取裝置資料而微調的服務。 如果入口網站是從穿戴式裝置或任何其他醫療裝置收集資料的解決方案的前端，則應使用 IoT Hub 來擷取這些資料。 如需更多資訊，請參閱遠端患者監控解決方案架構的內嵌程序。
Microsoft 365 Email 是業界領先的服務，用於電子郵件和通訊。 許多組織已投資於此服務，該服務可作為功能更完整的 Azure 通訊服務的替代方案。 在此解決方案中，該服務可用於傳送任何與取用者健康入口網站相關的電子郵件，例如預約確認或提醒電子郵件。
案例詳細資料
在整個健康與生命科學產業中，各組織都在採用數位健康策略。 取用者健康入口網站是數位健康解決方案的核心支柱和必要元件之一。 取用者健康入口網站可用於追蹤穿戴式裝置的進度和統計資料、與醫療服務提供者聯絡，甚至追蹤健康飲食習慣。
潛在使用案例
- 追蹤穿戴式裝置的統計資料。
- 取得醫療記錄，並與醫療人員聯絡。
- 輸入用藥時間和劑量，可用於補充資料或自我追蹤用藥情況。
- 與減重或糖尿病的健康飲食教練互動。
考量
這些考量能實作 Azure Well-Architected Framework 的支柱，其為一組指導原則，可以用來改善工作負載的品質。 如需更多資訊，請參閱 Microsoft Azure 結構完善的架構。
可用性
本解決方案目前設計為單一區域部署。 如果您的方案需要多區域部署，以達到高可用性、災難復原，甚至是就近部署，您可能需要配對的 Azure 區域，並具備下列設定。
Azure Cosmos DB 已延展以啟用多區域設定。
Azure API 管理使用 CI/CD 部署到次要地區。 您也可能套用 API 管理的多區域部署功能。
Azure 應用程式服務和 Functions 會分別部署到多個區域。 此部署可透過建立平行部署，在 CI/CD 管線中完成。 請閱讀高可用性多區域 Web 應用程式以取得進一步的指引。
根據 RTO (復原時間目標) 的需求，Azure Blob 儲存體可以設定為異地備援儲存體 (GRS)，或是讀取存取異地備援儲存體 (RA-GRS)，允許直接從交替區域讀取。 若要了解詳情，請參閱 Azure 儲存備援文章。
Azure Key Vault 服務內建多層可用性和備援。
安全性
安全性可提供保證，以避免刻意攻擊和濫用您寶貴的資料和系統。 如需詳細資訊，請參閱安全性支柱的概觀。
以下各節將說明此解決方案中使用的每個服務的安全性最佳實務。
Azure Front Door
Azure Front Door 的 Web 應用程式防火牆 (WAF) 應該用來減緩許多不同的常見攻擊。 一個好的基準是一開始就使用最新版本的 Open Web Application Security Project (OWASP) 核心規則集 (CRS)，然後視需要新增自訂原則。 雖然 Azure Front Door 的設計可吸收大量流量，但仍可考慮使用此服務的快取機制，盡可能減少後端系統的流量負載。 為了排除故障和支援潛在的安全調查，應該為 Azure Front Door 和 Web 應用程式防火牆設定記錄。 您可以在 Azure Front Door 的安全實務中閱讀更多資訊。
Azure API 管理
APIM 的所有流量都應該經過驗證，可以使用 Azure AD B2C APIM 驗證或使用權杖辨識的工作階段。 設定 Azure API 管理以儲存資源記錄。 您可以在 Azure API 管理的安全實務中閱讀更多資訊。
Azure App Service
此架構的所有流量，包括 App 服務，都應使用 TLS 來確保端對端的安全性。 該應用程式服務服務應拒絕不安全的通訊協定，以縮小攻擊面。 此外，APIM 應該將用戶端驗證傳回 App Service，讓應用程式服務根據自己的用戶端驗證和授權進行驗證。 應用程式服務中使用的所有機密都應儲存在金鑰保存庫中，並盡可能使用受控服務識別。 應用程式服務也應儲存診斷記錄，以支援任何安全診斷工作，並應與適用於應用程式服務的 Microsoft Defender 整合。 您可以在 Azure 應用程式服務的安全實務中閱讀更多資訊
Azure Functions
此解決方案中對 Azure 函式的所有要求都應該要求使用 HTTPS、使用 Azure API 管理來驗證要求，並盡可能使用受控服務識別。 將所有金鑰儲存在 Azure Key Vault，而不是留在函式代碼中。 與任何應用程式一樣，務必在輸入時驗證資料，並與適用於雲端的 Microsoft Defender 整合。 最後，請務必設定 Azure Functions 的記錄和監控。 您可以在 Azure Functions 的安全實務中閱讀更多資訊。
Azure Blob 儲存體
盡可能透過使用 Microsoft Entra ID 來授權使用者存取，以及使用受控服務識別來授權資源存取 Blob 儲存體，以限制對 Blob 儲存體的存取。 如果這些驗證類型可能不適用於您的應用程式，請在最細緻的層級使用共用存取簽章 (SAS) 權杖，而非帳戶金鑰。 SAS 權杖會在帳戶金鑰輪替後失效。
確保對 Blob 儲存體也使用角色型存取控制。 使用 Azure 儲存體防火牆停用網路流量，但來自受信任的 Microsoft 服務的流量除外。 務必將 Azure 儲存體與適用於雲端的 Microsoft Defender 整合，並設定監控。 您可以在 Azure Blob 儲存體的安全實務中閱讀更多資訊。
Azure Cosmos DB
Azure Cosmos DB 管理應啟用角色型的存取控制。 Azure Cosmos DB 中資料的存取應該有適當的安全保護。 您可以設定 Azure Cosmos DB 以儲存控制平面作業的診斷記錄，並儲存資源記錄。 如需詳細資訊，請參閱 Azure Cosmos DB 的安全實務。
Azure Key Vault
對 Azure Key Vault 提出的要求應使用 Microsoft Entra ID 或 MSI 驗證，此外還應使用特權存取控制。 除了在 Azure 監視器中記錄金鑰保存庫的動作外，還應將金鑰保存庫與適用於雲端的 Microsoft Defender 整合。 您可以在 Azure Key Vault 管理的安全實務中閱讀更多資訊。
Azure AD B2C
使用 Azure AD B2C 中的內建功能來防止威脅，例如拒絕服務和密碼型的攻擊。 設定稽核記錄，以便進行安全調查，並針對 B2C 產生的任何威脅管理記錄建立記錄警示。 您可以在 Azure AD B2C 的安全實務中閱讀更多資訊。
Azure Log Analytics
應針對 Log Analytics 設定角色型的存取控制，僅允許授權使用者存取傳送到工作區的資料。 您可以在 Azure Log Analytics 的安全實務中閱讀更多資訊。
Azure Application Insights
任何個人資料在傳送至 Application Insights 之前都應該先進行混淆處理。 應用程式深入解析的角色型存取控制也應該到位，僅允許授權使用者檢視傳送至 Application Insights 的資料。 您可以在 Azure Application Insights 的安全實務中閱讀更多資訊。
此外，請參閱 Azure 通知中樞的安全實務。
成本最佳化
成本最佳化是關於考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱成本最佳化支柱的概觀。
此架構的定價基於您最終使用的服務層級、容量、輸送量、資料的查詢類型、使用者人數，以及商務連續性和災難復原等因素而有所不同。 起價約為 2,500 美元/月，並可依此擴展。
若要開始，您可以在這裡檢視 Azure 計算機一般估算。
根據您的工作負載規模以及對企業功能的需求，使用 Azure API 管理的使用量分層可以降低成本。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者：
- Matt Hansen | 雲端計畫架構
下一步
- 深入了解 Azure FHIR 服務。
- 深入了解 Azure 健康資料服務。
- 深入了解如何對外發佈內部 API。