In diesem Artikel wird eine mögliche Lösung für die Planung und Nachverfolgung von virtuellen Besuchen zwischen Patienten, Gesundheitsdienstleistern und Pflegemanagern beschrieben.
Aufbau
Laden Sie eine Visio-Datei herunter, die dieses Architekturdiagramm enthält.
In diesem Architekturdiagramm stellen die blauen Felder die Microsoft-Dienste dar. Dabei handelt es sich entweder um die zugrunde liegenden Dienste oder Add-Ons, die für die Microsoft Cloud for Healthcare erforderlich sind und jeweils separat lizenziert werden müssen. Diese Komponenten ermöglichen eine schnellere Entwicklung von integrierten Lösungen im Gesundheitswesen für Patientenbetreuung, Zusammenarbeit des Gesundheitspersonals sowie Verbesserung von Erkenntnissen aufgrund von klinischen und betrieblichen Daten.
Die Daten fließen aus verschiedenen externen medizinischen Systemen, z. B. Patienten- und Arztterminpläne, Krankenakten, Wearables usw., in das System ein. Diese Daten werden mithilfe von Azure erfasst. Die Daten werden dann in Microsoft Dataverse gespeichert, einem Datenspeicher der Power Apps-Plattform. Das Datenformat verwendet Entitäten und Beziehungen zwischen diesen Entitäten, die mit dem Common Data Model (CDM), einem Industriestandard für die Darstellung medizinischer Daten, erstellt wurden. Alle Interaktionen zwischen Patient, Gesundheitsdienstleister und Pflegemanager erfolgen mit den in Dataverse gespeicherten CDM-Daten.
Ein registrierter Patient kann sich sicher beim Patient Portal, einer in den Power Apps-Portalen gehosteten Website, anmelden. In diesem Portal kann der Patient mit einem intelligenten Assistenten kommunizieren. Dabei handelt es sich um eine Instanz des Azure Health Bot-Dienstes, die Symptome erfasst, Vorschläge bereitgestellt und bei Bedarf empfiehlt, einen praktischen Arzt anzurufen. Wenn der Patient einen Arzt konsultieren möchte, ruft die Health Bot-Instanz Daten zu den verfügbaren Gesundheitsdienstleistern für virtuelle Besuche und deren Terminpläne aus Dataverse ab. Nachdem der Patient einen Gesundheitsdienstleister und eine Uhrzeit ausgewählt hat, zeigt der Bot die zugehörigen Kontaktinformationen an, die aus den in Dataverse gespeicherten EPA/EGA-Daten abgerufen werden. Der Patient kann diese Informationen im Bot überprüfen oder ändern und die Daten speichern.
Um einen Termin zu planen, stellt die Health Bot-Instanz über die Microsoft Graph-API eine Verbindung zur Bookings-App her und bucht einen Termin im Kalender des Gesundheitsdienstleisters. An beide Beteiligten wird mit Microsoft Outlook eine E-Mail mit den Termininformationen gesendet. Der Patient erhält Anweisungen, um sich beim Patientenportal für den Aufnahmeprozess anzumelden. Dieser Prozess umfasst das Bestätigen oder Ändern der Kontakt-, Zahlungs- und Versicherungsinformationen und das anschließende Unterzeichnen einer Einverständniserklärung für den virtuellen Besuch. Nachdem die Einverständniserklärung unterzeichnet wurde, wird der Microsoft Teams-Link für den Termin mitgeteilt.
Der Gesundheitsdienstleister meldet sich bei Teams an, um den Terminplan und zusammenfassende Informationen zu den einzelnen Terminen zu überprüfen. Teams stellt diese Informationen mithilfe der Appointment Queue-Anwendung dar. Der Gesundheitsdienstleister kann dann in Teams den virtuellen Besuch zum geplanten Termin starten. Während des Anrufs kann der Gesundheitsdienstleister Vermerke erstellen und der Krankenakte des Patienten hinzufügen.
Ein neuer Vermerk in der Krankenakte des Patienten löst eine Überprüfungsbenachrichtigung an den für den Patienten zuständigen Pflegemanager aus. Wenn der Pflegemanager diese Benachrichtigung erhält, kann er sich bei Teams anmelden, wo er die ihm zugewiesenen Patienten sehen und die Vermerke anzeigen kann. Über die Care Management-Anwendung kann er erforderliche Änderungen am Pflegeplan des Patienten vornehmen.
Komponenten
Die Architektur umfasst die folgenden Komponenten:
PAS. Bei PAS (Patient Administration Systems) handelt es sich um Systeme, die die Verwaltungsarbeit in Gesundheitsorganisationen (z. B. in Krankenhäusern) automatisieren. Sie bilden die Kernkomponenten der IT-Infrastruktur einer solchen Organisation. Ein PAS zeichnet die demografischen Daten des Patienten auf, z. B. Name, Privatadresse, Geburtsdatum usw. Außerdem werden ausführliche Informationen zu sämtlichen Kontakten des Patienten im Krankenhaus, sowohl ambulant als auch stationär, aufgezeichnet. Mithilfe von PAS können moderne Krankenhäuser Ressourcen in der gesamten Organisation melden und planen. PAS ist in dieser Lösung eine wichtige Quelle für Planungsdaten. Da diese Daten extern sind und u. U. nicht in einem Standardformat vorliegen, müssen sie in ein Format konvertiert werden, das von allen Komponenten dieser Lösung verstanden wird.
EPA/EGA. Elektronische Patientenakten (EPA) und elektronische Gesundheitsakten (EGA) stellen die medizinischen Daten und Gesundheitsdaten eines Patienten, z. B. Diagnosen, Medikamente, Impfungen usw., in digitaler Form zur Verfügung. Sie können für eine einzelne Praxis gültig (EPA) oder viel umfassender sein (EGA), sodass der Patient die Daten bei den jeweiligen Einrichtungen immer verfügbar hat. Hierbei handelt es sich um wichtige externe Datenquellen in dieser Lösung, die ein unstrukturiertes, nicht standardisiertes Format aufweisen können. Daher müssen diese Daten in ein Format konvertiert werden, das von den Komponenten in dieser Lösung verwendet werden kann.
Azure API for FHIR. Azure ist der erste Schritt beim Einbinden von Daten in das Microsoft-Ökosystem und die Microsoft Cloud for Healthcare. Diese Ebene stellt eine sichere Schnittstelle zwischen den externen Daten und den internen Komponenten dieser Architektur zur Verfügung. Die Azure API for FHIR übernimmt strukturierte oder unstrukturierte Daten aus unterschiedlichen Quellen, z. B. EPA, PAS und Geräten, konvertiert diese Daten in FHIR und speichert sie in Azure. Diese Daten können dann in der Microsoft Cloud for Healthcare für verschiedene Dienstleistungen verwendet werden. Die Azure API for FHIR wurde unter Berücksichtigung von Sicherheits- und Konformitätsaspekten für geschützte personenbezogene Gesundheitsdaten konzipiert. Weitere Informationen zu dieser Ebene finden Sie unter Azure für das Gesundheitswesen und Azure API for FHIR.
Common Data Model. Mit dem Common Data Model stellt Microsoft ein standardisiertes Metadatendefinitionssystem bereit, das für bestimmte Geschäftsanforderungen erweitert und angepasst werden kann. Es gibt CDM-Entitäten für Fachbereiche wie CRM, Gesundheitswesen, Talentsuche usw. Weitere Informationen finden Sie in den Informationen zum Common Data Model. Zusätzlich zu diesen Entitäten können Kunden proprietäre Daten einbeziehen, indem die betreffende Entitätstabelle und die zugrunde liegenden Felder im Common Data Model definiert werden, sodass diese Daten problemlos mit anderen Entitäten in der gesamten Lösung verwendet werden können.
Microsoft Dataverse. Dataverse, eine relationale Datenbank, die Microsoft Dynamics 365 unterstützt, ist das Repository für die Daten, die im Common Data Model dargestellt werden. Sie umfasst Datenbanken für Patienteninformationen mit Details zu deren Namen, Familieninformationen, Erkrankungen, medizinischen Behandlungen usw. Sie enthält außerdem Informationen von registrierten Wearables, die von den Patienten verwendet werden, sowie Termin- und Verwaltungsdaten der Gesundheitsorganisation. Diese Daten werden mit dem Common Data Model definiert.
Patient Portal. In diesem Power Apps-Portal können Patienten ihre Krankenakten anzeigen, Termine buchen, mit der Health Bot-Instanz chatten usw. Dieses Portal kann erweitert werden, sodass weitere Daten unterstützt werden. Dieses Portal ist Bestandteil der Microsoft Cloud for Healthcare und ermöglicht das einfache Einrichten eines Portals, das eine Verbindung mit Entitäten in Dataverse herstellen kann, um Daten wie Patienteninformationen, Pflegepläne, Termine usw. abzurufen.
Intelligent Assistance. Dabei handelt es sich um eine Instanz des Azure Health Bot-Diensts, auf die Patienten über das Patient Portal zugreifen können. Diese Health Bot-Instanz wird in einer Azure App Service-Website geladen. Sie kann angepasst und für die vom Kunden benötigten Szenarien programmiert werden.
Bookings-App. Die Bookings-App ist ein Microsoft 365-Dienst, der in der Microsoft Cloud for Healthcare enthalten ist. Sie ermöglicht die Planung von Kalendereinträgen und das Erstellen von Teams-Besprechungen.
Microsoft Outlook. In dieser Lösung wird Microsoft Outlook als E-Mail-Client verwendet. Die Bookings-App, die die E-Mail-Benachrichtigung sendet, ist in Outlook integriert. Alternativ kann der bevorzugte E-Mail-Client des Gesundheitsdienstleisters verwendet werden.
Microsoft Teams. Microsoft Teams ist eine Komponente der Microsoft Cloud for Healthcare und stellt das Front-End für Interaktionen zwischen den Patienten, Gesundheitsdienstleistern und Pflegemanagern bereit. Benutzer können eine lokal installierte Version oder die Webversion verwenden. Weitere Informationen zu Teams finden Sie in der Microsoft Teams-Dokumentation.
Appointment Queue. Dieses Tool generiert eine HTML-Seite mit Daten, die über die Dynamics 365-Web-API aus Dataverse abgerufen werden. Der Gesundheitsdienstleister enthält Informationen zu den für den jeweiligen Tag geplanten Terminen sowie eine Zusammenfassung der einzelnen Termine. Außerdem wird ein Link für den Zugriff auf die Patienteninformationen über die Care Management-Anwendung bereitstellt. Das Appointment Queue-Tool wurde zur Unterstützung dieses Szenarios entwickelt und ist nicht Bestandteil der Microsoft Cloud for Healthcare. Datenquellen für dieses Tool sind hauptsächlich die PAS-Systeme sowie EPA/EGA-Akten. Wenn diese Systeme über integrierte Tools für die Darstellung dieser Daten verfügen, können diese Tools in einer realen Bereitstellung als Ersatz für diese Komponente verwendet werden.
Care Management. Das Care Management-Tool ist eine Komponente der Microsoft Cloud for Healthcare. Dabei handelt es sich um eine über Dynamics 365 bereitgestellte Power Apps-Anwendung. Sie ruft die in Dataverse im CDM-Format gespeicherten EPA/EGA-Patientendaten ab und stellt in Teams eine aggregierte Ansicht dar. Abhängig von der gewünschten Anzeige dieser Informationen können in der Lösung eines medizinischen Versorgungszentrums ggf. eigene Systeme dafür verwendet werden.
Power BI Analytics. Hierbei handelt es sich um ein für dieses Szenario erstelltes Analysetool, das nicht zur Microsoft Cloud for Healthcare gehört. In dieser Lösung werden Informationen generiert, die von den IoMT-Geräten des Patienten stammen. Dabei kann es sich um Daten wie Herzfrequenz, Blutsauerstoffgehalt usw. handeln. Die Care Management-App verwendet diese Daten, um Ärzten anhand der täglichen Aktivitäten der Patienten weitere Erkenntnisse zu geben.
Verbundene Geräte. Hierbei handelt es sich um IoMT-Geräte (Internet of Medical Things) ,d. h. intelligente Geräte für den medizinischen oder Gesundheitsbereich. Beispiele für IoMT-Geräte sind Wearables wie Apple Watch oder Fitbit, medizinische Überwachungseinrichtungen oder Vitaldatenmonitore usw. Patienten können ihre Geräte über Azure bereitstellen und festlegen, dass ihr Pflegemanagementsystem diese IoMT-Daten für die Verwendung durch den jeweiligen Gesundheitsdienstleister erfassen kann. Gesundheitsdienstleister können mithilfe solcher Geräte nahezu in Echtzeit weitere Erkenntnisse erhalten und Anomalien, z. B. eine höhere Pulsfrequenz für einen bestimmten Zeitraum, mit den aktuellen Symptomen der Patienten verknüpfen.
Automatisierung mit Power Automate. Dieses benutzerdefinierte Tool, das zur Unterstützung dieses Szenarios entwickelt wurde, gehört nicht zur Microsoft Cloud for Healthcare. Da es sich hierbei um ein virtuelles Besuchsszenario handelt, kann der Gesundheitsdienstleister ein Bereitschaftsarzt und nicht der behandelnde Arzt des Patienten sein. Mit diesem Tool können die Vermerke des Gesundheitsdienstleisters eine Teams-Benachrichtigung an den Pflegemanager auslösen. Der Pflegemanager ist ein Mitglied des medizinischen Teams, das als Kontaktperson zwischen dem primär zuständigen Arzt und dem Patienten dient und das langfristige Pflegemanagement übernimmt. Eine Benachrichtigung, die mit neuen Vermerken für den Patienten an den Pflegemanager gesendet wurde, kann der Pflegemanager nach dem Besuch überprüfen, sodass entsprechende Änderungen in der Gesundheitsversorgung des Patienten vorgenommen werden können.
Alternativen
Die Dienste von Azure für das Gesundheitswesen wie Azure API for FHIR und Azure Health Bot, Common Data Model Interface, Microsoft Dataverse und Microsoft Teams bilden die Kernkomponenten dieser Lösung. Die meisten anderen Komponenten dieses Systems können durch Systeme ersetzt werden, die derzeit von der Gesundheitseinrichtung verwendet werden:
Wenn das EPA/EGA-System über integrierte Komponenten für Voranmeldung, Zeitplanung und Pflegemanagement verfügt, können diese anstelle der entsprechenden Komponenten in dieser Lösung verwendet werden.
Die Zeitplanfunktionen und E-Mail-Benachrichtigungen von Bookings und Outlook-können durch Systeme, die von der Gesundheitseinrichtung verwendet werden, ersetzt werden. Diese Funktionen können über das EGA-System oder von einer Drittanbieteranwendung durchgeführt werden. Die Anwendung muss eine API bereitstellen, mit der die Health Bot-Instanz Termine erstellen und planen kann, sowie die Möglichkeit bieten, virtuelle Besprechungen zu erstellen.
Wenn der Gesundheitsdienstleister bereits über ein über das jeweilige EPA/EGA-System implementierte Patientenportal verfügt, kann dieses anstelle von Patient Portal verwendet werden. Eine solche externe Komponente kann ohne großen Aufwand in diese Lösung integriert werden, da diese Komponenten Standardschnittstellen verwenden, z. B. eine iFrame -Schnittstelle für die Kommunikation mit der Health Bot-Instanz. Komponenten, die diesen Ablauf unterstützen, können im proprietären Portal erstellt werden, z. B. die Eiverständniserklärung, die der Patient vor der Teilnahme an der Teams-Besprechung unterzeichnen muss.
Beachten Sie, dass in einer realen Bereitstellung für einige Komponenten in dieser Lösung Ersatztools benötigt werden, z. B. für das Appointment Queue-Tool, automatisierte Benachrichtigungen und Power BI-Analysetools. Diese Komponenten müssen für die Geschäftsanforderungen des Gesundheitsdienstleisters erstellt und angepasst werden.
Szenariodetails
In der aktuellen COVID-19-Pandemie (Coronavirus) möchten viele Patienten ihren Arzt nach Möglichkeit lieber virtuell und nicht persönlich aufsuchen. In einer solchen virtuellen Welt wird die Verbesserung von klinischen und betrieblichen Erkenntnissen im Gesundheitswesen von Bedeutung. Dies umfasst die systemübergreifende Verknüpfung von Daten, die Schaffung von Erkenntnissen für die Prognose von Risiken sowie die Verbesserung von Patientenversorgung, Qualitätssicherung und Betriebseffizienz.
Diese Lösung basiert auf der Microsoft Cloud for Healthcare. Microsoft Cloud for Healthcare vereint vertraute Funktionen von Microsoft 365, Azure, Dynamics 365, Power Platform und des umfangreichen Partnerökosystems von Microsoft, damit Gesundheitsorganisationen in kurzer Zeit effiziente und sichere Lösungen für das Gesundheitswesen erstellen können.
Mögliche Anwendungsfälle
Diese Lösung ist für die virtuelle Patientenversorgung in der aktuellen Pandemie konzipiert. Gesundheitsdienstleister können die Lösung jedoch leicht auf die folgenden Szenarien übertragen:
Planung der virtuellen Nachverfolgung nach persönlichen Arztbesuchen.
Bereitstellung von medizinischen Anleitungen für Patienten bei Reisen, sofern es sich nicht um Notfälle handelt.
Überlegungen
Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.
Sicherheit
Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.
Da im System Patientendaten verarbeitet werden, müssen bei der Entwicklung dieser Lösung grundlegende Sicherheitsüberlegungen für personenbezogene Informationen berücksichtigt werden:
Durch das System dürfen immer nur die erforderlichen Daten übertragen werden. Rufen Sie aus den EPA/EGA-Systemen beispielsweise nur die Daten ab, die für Terminplanung und Verwaltung des virtuellen Besuchs erforderlich sind. Beachten Sie die festgelegten HIPAA-Konformitätsregeln. Diese regeln, wo die Patientendaten gespeichert werden sollen, wie sie verarbeitet werden können und wer darauf Zugriff haben sollte. Beachten Sie bei der Entwicklung ihrer Lösung die Wichtigkeit der Konformität im Gesundheitswesen. Weitere Informationen finden Sie unter Konformität in Microsoft Cloud for Healthcare.
Nur befugte Mitarbeiter dürfen Zugriff auf Patientendaten und lediglich die Daten haben, die für ihre Funktion erforderlich sind. An verschiedenen Stellen im System, z. B. in der Care Management-App und in den darin eingehenden Analysen, im Appointment Queue-Tool oder in den Benachrichtigungssystemen, muss darauf geachtet werden, dass Mitarbeiter authentifiziert und autorisiert werden und deren Zugriff auf die absolut erforderlichen Patienteninformationen beschränkt wird.
Module mit Patienteninteraktion, z. B. die Apps Intelligent Assistance und Bookings, übernehmen, speichern und nutzen Patientendaten. Durch eine geeignete Zugriffssteuerung und Authentifizierung bei diesen Modulen wird sichergestellt, dass Datenschutzaspekte berücksichtigt werden.
Da personenbezogene Daten verarbeitet werden, sind Sicherheit und Konformität in Microsoft Cloud for Healthcare grundsätzlich von hoher Bedeutung.
Dieses Beispiel basiert ebenfalls auf den Sicherheitsregeln, die von Dynamics 365 und Teams festgelegt wurden:
Die einzelnen Dienste, die in Microsoft Cloud for Healthcare enthalten sind, stellen eine eigene Sicherheits- und Konformitätsebene bereit:
Für benutzerdefinierte Sicherheitskontrollen sollten Sie die Verwendung von Microsoft Entra ID und der rollenbasierten Zugriffssteuerung in Erwägung ziehen.
Beachten Sie schließlich bei der Implementierung dieser Lösung die bewährten Methoden und Anleitungen für die Entwicklung sicherer Azure-Lösungen.
Kostenoptimierung
Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.
Ausführliche Preisinformationen zur Microsoft Cloud for Healthcare finden Sie unter Wie lässt sich Microsoft Cloud for Healthcare kaufen?. Für die Komponenten, aus denen Microsoft Cloud for Healthcare besteht, sind eigene Lizenzen erforderlich, z. B.:
Für die Neuerstellung von kundenspezifischen Komponenten in dieser Architektur müssen Sie die Preisinformationen für die zugrunde liegenden Dienste, die Sie verwenden möchten, berücksichtigen.
Bereitstellen dieses Szenarios
Die Lösung sollte in Stufen bereitgestellt werden:
Einige Produkte/Dienste müssen als erforderliche Komponenten für Microsoft Cloud for Healthcare installiert werden. Weitere Informationen zu den Lizenzanforderungen finden Sie in der detaillierten Liste in diesem Artikel.
Informationen zur Bereitstellung von Microsoft Cloud for Healthcare finden Sie im Artikel zur Bereitstellung von Microsoft Cloud for Healthcare-Lösungen von Dynamics 365.
Microsoft Cloud for Healthcare stellt die grundlegenden Komponenten wie Patient Portal, Teams, Bookings usw. bereit, um in kurzer Zeit eine virtuelle Gesundheitslösung erstellen zu können. Die für diese Bausteine verwendeten Daten müssen den jeweiligen geschäftlichen Anforderungen entsprechend angepasst werden.
Die Komponenten, die in Microsoft Cloud for Healthcare und den erforderlichen Komponenten verfügbar sind, müssen so angepasst werden, dass die geschäftlichen Anforderungen erfüllt werden:
Zur Unterstützung von Benachrichtigungen an den Pflegemanager sollten Power Automate-Abläufe erstellt werden.
Patient Portal muss konfiguriert werden. Für Elemente wie Eincheckformulare und Einverständniserklärung müssen ggf. weitere Formulare erstellt werden. Weitere Informationen finden Sie im Artikel zum Einrichten und Konfigurieren eines Patientenzugriffsportals.
Der Azure Health Bot-Dienst muss mit der Dataverse-Datenbank verbunden und für die Kommunikation mit den Patienten angepasst werden. Weitere Informationen finden Sie im Artikel zum Konfigurieren automatischer Chats mit Microsoft Health Bot.
Informationen zu möglicherweise weiteren erforderlichen Konfigurationen finden Sie in den Artikeln zum Konfigurieren der Synchronisierung klinischer Daten mit dem Azure-FHIR-Synchronisierungs-Agent und Einbetten von Power BI-Analyseberichten.
Die zusätzlichen Komponenten, die speziell für diese Lösung erstellt wurden, sind nicht für den produktiven Einsatz verfügbar. Die Gesundheitseinrichtung muss eine eigene Version der folgenden Anwendungen erstellen:
Appointment Queue
Automatisierte Benachrichtigungen mit Power Automate
Berichtserstellung mit Power BI
Beitragende
Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:
Hauptautoren:
- Slavica Frljanic | Principal Group Program Manager
- Dhanashri Kshirsagar | Senior Content PM
Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.
Nächste Schritte
- Was ist die Microsoft Cloud für das Gesundheitswesen?
- Weitere Informationen zu den Azure-Angeboten für das Gesundheitswesen finden Sie unter Azure für das Gesundheitswesen.
- Unterschied zwischen EPA und EGA
- HIPAA-Konformitätsregeln
- Was ist Azure API for FHIR?
- Was ist Microsoft Dataverse?
- Übersicht über Health Bot
- Was ist Power BI?
- Informationen zur Verwendung von Microsoft Dynamics 365