本文討論排程和追蹤患者、提供者和護理經理之間的虛擬訪問的潛在解決方案。
架構
在此架構圖中，藍色線條方塊代表Microsoft 服務，這些Microsoft 服務是 Microsoft Cloud for Healthcare 所需的 基礎服務或附加元件，每個服務都必須分別獲得授權。 這些元件共同協助加速開發整合式醫療保健解決方案，以進行病患參與、健康小組共同作業，以及改善臨床和運算元據深入解析。
資料會透過各種外部醫療系統流入系統，例如患者和提供者排程、醫療記錄、可穿戴裝置等等。 此資料是使用 Azure 擷取。 然後，它會儲存在 Microsoft Dataverse 中，這是由 Power Apps 平臺提供的資料存放區。 此資料會格式化為使用實體和它們之間的關聯性，並使用 Common Data Model （CDM） 建立，這是代表醫療資料的業界標準。 患者、提供者和護理管理員之間的所有互動都會使用此儲存在 Dataverse 中的 CDM 資料進行。
已建立的病患可以安全地登入病患入口網站，這是 Power Apps 入口網站中裝載的網站。 在此入口網站中，患者可以與 智慧型助理 交談。 這是 Azure Health Bot 服務的 實例 ，它會收集其徵兆、提供建議，並視需要建議呼叫從業者。 如果患者選擇連線到其醫療提供者，Health Bot 實例會從 Dataverse 取得可供虛擬造訪的提供者及其排程上的資料。 一旦患者選取提供者和時間，Bot 就會呈現其連絡資訊，該資訊是從 儲存在 Dataverse 中的 EMR/EHR 資料取得。 患者可以驗證或變更這項資訊，並使用 Bot 儲存資料。
若要排程約會，健康情況 Bot 實例會使用 Microsoft Graph API 連線到 Bookings 應用程式，並在提供者的行事曆上預約約會。 具有約會資訊的電子郵件會使用 Microsoft Outlook 傳送給雙方。 病患已獲指示登入病患入口網站，以進行攝入量程式。 此程式涉及確認或變更其連絡人、付款和保險資訊，然後簽署虛擬訪問的同意表單。 簽署同意之後，就會提供約會的 Microsoft Teams 連結。
提供者會登入 Teams，以檢查其約會排程和每個專案的摘要資訊。 Teams 會使用 約會佇列 應用程式來呈現這項資訊。 然後，提供者就可以在 Teams 上開始進行排程約會的虛擬造訪。 在通話期間，提供者可以記筆記，並將其新增至病患的記錄。
患者醫療記錄上的新附注會觸發指派給病患之護理經理的檢閱通知。 當護理經理收到此通知時，他們可以登入 Teams，在那裡他們可以看到指派給他們的病人，並檢視筆記。 透過護理管理應用程式，他們可以對病人的護理計畫進行必要的變更。
元件
架構包含下列元件：
PAS 。 患者管理員管理系統（PAS）是自動化醫療保健組織中系統管理檔的系統，例如醫院。 它們是這類組織 IT 基礎結構的核心元件。 PAS 會記錄患者的人口統計，例如姓名、住址、出生日期等等。 它還記錄了病人與醫院的所有接觸詳細資訊，包括門診和住院人員。 在 PAS 的説明下，新式醫院能夠報告及排程整個組織的資源。 PAS 是此解決方案中排程資料的重要來源。 由於此資料是外部資料，而且可能是非標準格式，因此請務必將它轉換成此解決方案的所有元件所瞭解的格式。
EMR/EHR 。 電子醫療記錄（EMR） 和 電子健康記錄（EHR） 提供患者醫療健康資訊的數位記錄，包括診斷、藥物、免疫等。 它們可以限定為單一練習辦公室，例如EMR，或設計為範圍更大，與病人一起前往他們去的哪個設施，例如EHR。 這些是此解決方案中重要的外部資料源，而且可能是非結構化的非標準格式。 因此，此資料必須轉換成此解決方案中元件可以使用的格式。
Azure API for FHIR 。 Azure 是將資料帶入 Microsoft 生態系統和 Microsoft Cloud for Healthcare 的過程中的第一個步驟。 此層提供此架構外部資料和內部元件之間的安全介面。 Azure API for FHIR 會擷取來自不同來源的資料，例如 EMR、PAS、裝置，不論結構化還是非結構化，將其轉換成 FHIR，並保存在 Azure 中。 然後，此資料可以在適用于醫療保健的 Microsoft Cloud 中用於不同服務。 Azure API for FHIR 是以安全性與合規性為建置，專為 PHI （受保護的健康情況資訊） 資料所設計。 如需此層的詳細資訊，請參閱 適用于醫療保健 的 Azure 和適用于 FHIR 的 Azure API
一般資料模型 。 透過 Common Data Model，Microsoft 提供可擴充且可針對特定商務需求自訂的標準化元資料定義系統。 CDM 實體適用于主題領域，例如 CRM、醫療保健、Talent 等等。 如需詳細資訊，請參閱 Common Data Model 使用資訊 。 除了這些實體之外，客戶還可以定義 Common Data Model 中的實體資料表和基礎欄位來提取專屬資料，然後在整個解決方案中順暢地與其他實體搭配使用。
Microsoft Dataverse 。 Dataverse 是支援 Microsoft Dynamics 365 的關係資料庫，是 Common Data Model 中所代表資料的存放庫。 它會保存患者資訊的資料庫，其中包含其名稱、家庭資訊、醫療狀況、藥物歷程記錄等詳細資料。 它還保存從患者使用和註冊的任何可穿戴裝置取得的資訊，以及醫療保健組織的排程和管理資料。 此資料是使用 Common Data Model 來定義。
病患入口網站 。 此 Power Apps 入口網站 可讓患者檢視其醫療記錄、預約約會、與健康 Bot 實例聊天等等。 此入口網站可以擴充以支援其他資料。 此入口網站是適用于醫療保健的 Microsoft Cloud 的一部分，可讓您輕鬆地啟動入口網站，該入口網站可與 Dataverse 中的實體連線、提取患者資訊、護理計畫、約會等資料。
智慧型協助 。 這是 Azure Health Bot 服務的 實例 ，可透過病患入口網站存取患者。 此健康情況 Bot 實例會在Azure App 服務網站內載入。 這是可自訂的，而且可以使用客戶所需的案例進行程式設計。
Bookings 應用程式 。 Bookings App 是 Microsoft 365 服務，包含在適用于醫療保健的 Microsoft Cloud 中。 它有助於排程行事曆活動，並允許建立 Teams 會議。
Microsoft Outlook 。 此解決方案會使用 Microsoft Outlook 做為電子郵件客戶程式。 傳送電子郵件通知的 Bookings 應用程式已與 Outlook 整合。 或者，也可以使用醫療保健提供者慣用的電子郵件客戶程式。
Microsoft Teams。 Microsoft Teams 是適用于醫療保健的 Microsoft Cloud 元件，並提供患者、提供者和護理經理之間互動的前端。 使用者可以使用本機安裝的版本或 Web 版本。 如需 Teams 的詳細資訊，請參閱 Microsoft Teams 檔 。
約會佇列 。 此工具會產生 HTML 頁面，其中包含使用 Dynamics 365 Web API 從 Dataverse 提取的資料。 它會向提供者呈現排定當天的約會相關資訊，以及每個約會的摘要。 它也提供連結，以透過護理管理應用程式存取患者資訊。 約會佇列是針對支援此案例而開發的，不是適用于醫療保健的 Microsoft Cloud 的一部分。 此工具的資料來源主要是 PAS 系統和 EMR/EHR 記錄。 如果這些系統已整合工具來呈現此資料，這些工具可能是實際部署中此元件的取代專案。
護理管理 。 護理管理工具是適用于醫療保健的 Microsoft Cloud 元件。 它是透過 Dynamics 365 部署的 Power Apps 應用程式。 它會提取以 CDM 格式儲存在 Dataverse 中的 EMR/EHR 病患資料，並在 Teams 中呈現匯總檢視。 護理中心的解決方案可能會根據他們想要呈現此資訊的方式，選擇使用自己的系統來提供其功能。
Power BI 分析 。 這是針對此案例建立的分析工具，不適用於適用于醫療保健的 Microsoft Cloud。 在此解決方案中，它會產生衍生自患者 IoMT 裝置的資訊。 這可能是心率、血氧水準等資料。 護理管理應用程式會使用此資料，根據患者的每日活動，向醫療提供者提供關於其患者的其他見解。
連線裝置 。 這些是 醫療物聯網（IoMT） 裝置，這些裝置是醫療或醫療保健用途的智慧型裝置。 IoMT 裝置的範例包括可穿戴裝置，例如 Apple Watch 或 Fitbit、醫療或重要監視器等等。 患者可以透過 Azure 布建其裝置，並選擇允許其醫療保健管理系統收集此 IoMT 資料供其提供者使用。 提供者可以近乎即時地從這類裝置取得其他見解，並連結異常狀況，例如一段時間的心率升高，以及患者的目前症狀。
使用 Power Automate 進行 自動化。 這是為了支援此案例而建立的自訂工具，不適用於適用于醫療保健的 Microsoft Cloud。 由於這是虛擬訪問案例，因此提供者可能只是待命醫生，而不是病人的一般醫生。 此工具可讓提供者的附注觸發 Teams 通知給 護理經理 。 護理經理是醫療小組的成員，負責初級護理醫生（PCP）與病人之間的聯絡，並負責長期護理管理。 傳送給護理經理的通知，指出為患者新增的新筆記，可讓他們在看診後檢閱和對患者護理管理進行適當的變更。
替代項目
適用于醫療保健服務的 Azure，例如 Azure API for FHIR 和 Azure Health Bot、Common Data Model 介面、Microsoft Dataverse 和 Microsoft Teams，會形成此解決方案的核心元件。 此系統的大部分其他元件都可以由醫療保健設施目前使用的系統所取代：
如果 EMR/EHR 系統隨附內建的預約、排程和護理管理，則可以使用這些內建元件，而不是此解決方案中的對應元件。
預約和 Outlook 排程和電子郵件通知可由醫療保健設施所使用的系統交換。 這些作業可以透過 EHR 系統或使用協力廠商應用程式來完成。 應用程式應該提供健康情況 Bot 實例可用來建立和排程約會的 API，以及建立虛擬會議的功能。
如果提供者已經透過其 EMR/EHR 系統實作病患入口網站，則可能會使用它，而不是病患入口網站。 將這類外部元件與這個解決方案整合很容易，因為這些元件會使用標準介面， 例如 iFrame 介面來與健康情況 Bot 實例通訊。 支援此流程的元件可以在專屬入口網站上建立，例如患者在加入 Teams 會議之前需要簽署的同意表單。
值得注意的是，實際部署需要此解決方案中某些元件的取代工具，例如約會佇列、自動化通知和 Power BI 分析工具。 這些元件必須針對醫療保健提供者的商務需求建立和自訂。
案例詳細資料
在目前的 COVID-19（二進位）大流行中，大量患者可能希望盡可能親自就醫，而不是親自看病。 改善醫療保健的臨床和營運見解，在這樣的虛擬世界中非常重要。 這包括跨系統連線資料、建立深入解析來預測風險，並協助改善病患護理、品質保證和營運效率。
此解決方案的基礎是適用于醫療保健 的 Microsoft Cloud。 Microsoft Cloud for Healthcare 將 Microsoft 365、Azure、Dynamics 365、Power Platform 和 Microsoft 廣泛的合作夥伴生態系統整合在一起，協助醫療保健組織建立快速、有效率且安全的醫療保健解決方案。
潛在的使用案例
此解決方案的目標是在目前的大流行中提供虛擬患者護理。 不過，醫療保健提供者可以輕鬆地將其套用至下列案例：
排程虛擬後續人員造訪。
在旅行時為患者提供非緊急醫療指導。
考量
這些考慮會實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可用來改善工作負載的品質。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework 。
安全性
安全性可提供針對蓄意攻擊和濫用寶貴資料和系統的保證。 如需詳細資訊，請參閱 安全性要素 概觀。
由於系統是以病患資料為建置基礎，因此開發此解決方案時，應該套用私人資訊的基本安全性考慮：
只有必要的資料應該在任何指定時間流經系統。 例如，只從虛擬造訪排程和管理所需的 EMR/EHR 系統提取該資料。 檢閱已建立 的 HIPAA 合規性規則 ，以取得患者資料應儲存位置、使用哪些專案以及誰可以存取該資料的指導。 在開發解決方案時，請注意醫療保健合規性的重要性。 如需進一步指引，請參閱 適用于醫療保健 的 Microsoft Cloud 合規性。
只有獲授權的人員才能存取病患資料，且只能存取其角色所需的資料。 在系統的各個時間點，例如護理管理和分析饋送至其中、預約佇列或通知系統，應謹慎驗證和授權人員，並限制他們只存取所需的患者資訊。
與患者互動的模組，例如智慧型協助和 Bookings 應用程式、接受、儲存和使用病患資料。 這些模組的適當存取控制和驗證可確保解決隱私權考慮。
由於涉及私人資料的本質， 安全性和 合規性 會形成 Microsoft Cloud for Healthcare 的基本原則。
此範例也依賴 Dynamics 365 和 Teams 所設定的安全性規則：
Microsoft Cloud for Healthcare 中包含的個別服務提供自己的安全性與合規性層級：
針對自訂安全性控制，請考慮使用 Microsoft Entra 識別碼 和 角色型存取控制 。
最後，實作此解決方案時，請記住 開發安全 Azure 解決方案 的最佳做法和指引。
成本最佳化
成本優化是考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱 成本優化要素 概觀。
如需適用于醫療保健的 Microsoft Cloud 的詳細資訊，請參閱 如何購買適用于醫療保健 的 Microsoft Cloud。 組成 Microsoft Cloud for Healthcare 的元件有自己的授權需求，例如：
若要重新建立此架構中自訂的元件，請考慮您選擇使用之基礎服務的定價資訊。
部署此案例
解決方案應分階段部署：
某些產品/服務必須安裝為 Microsoft Cloud for Healthcare 的必要條件。 如需授權需求 ， 請參閱本文的詳細清單。
您可以使用 Dynamics 365 所提供的部署 Microsoft Cloud for Healthcare 解決方案中 提供的指示來部署適用于醫療保健的 Microsoft Cloud。
適用于醫療保健的 Microsoft Cloud 提供基本元件，可開始建置虛擬健康解決方案，例如病患入口網站、Teams、Bookings 等等。 將用來提供這些建置組塊的資料，應該根據業務需求來自訂。
Microsoft Cloud for Healthcare 及其必要條件中提供的元件，應自訂以支援商務需求：
應該建立 Power Automate 流程以支援護理管理員通知。
應設定病患入口網站。 可能需要為簽入/同意表單等專案建立其他表單。 如需詳細資訊，請參閱 設定及設定病患存取入口網站 。
Azure Health Bot 服務應該連線到 Dataverse 資料庫，並針對其與病患的通訊進行自訂。 如需詳細資訊，請參閱 使用 Microsoft Health Bot 設定自動聊天。
請參閱 使用 Azure FHIR 同步代理程式和 內嵌 Power BI 報告來設定與臨床資料的同步處理，以取得分析 ，以瞭解一些可能需要的其他設定。
針對此解決方案特別建立的其他元件不適用於生產等級的使用。 醫療保健設施可能需要建立自己的這些應用程式版本：
約會佇列
使用 Power Automate 自動通知
使用 Power BI 的報告應用程式
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者：
- 斯拉維卡·弗雷賈尼奇 |主體群組計畫管理員
- 達納什裡·克斯希爾薩加 |資深內容 PM
若要查看非公用LinkedIn設定檔，請登入 LinkedIn。
下一步
- 什麼是適用于醫療保健的 Microsoft Cloud？
- 在適用于醫療保健的 Azure 中深入瞭解 Azure 的醫療保健供應專案 — 醫療保健解決方案
- EMR 與 EHR 之間的差異
- HIPAA 合規性規則
- 什麼是 Azure API for FHIR？
- 什麼是 Microsoft Dataverse？
- 什麼是 Azure Health Bot 服務？
- Power BI 是什麼？
- 瞭解如何使用 Microsoft Dynamics 365