Bearbeiten

Remote-Patientenüberwachung

Azure Data Lake Storage
Azure Databricks
Azure Event Hubs
Azure Machine Learning
Azure Synapse Analytics
Power BI

Gesundheitssysteme, Krankenhäuser und große Arztpraktiken gehen mehr und mehr zu „Hospital-at-Home“-Initiativen über (auch als Remote-Patientenüberwachung bekannt). Remote-Patientenüberwachung ist ein Teilbereich der klinischen Versorgung, bei dem Aktivitäten und physiologische Daten des Patienten mithilfe von medizinischen Remote-Geräten gemäß individuellen Pflegeplanparametern abgerufen und bereitgestellt werden können.

Dieser Artikel bietet einen Leitfaden für die Gestaltung einer Lösung mit Azure Health Data Services und Geräten für die intelligente Remote-Patientenüberwachung. Diese Lösung hilft ihnen, viele der Herausforderungen bei der Geräteintegration zu verringern, die Ihre Organisation bei der Erstellung einer solchen Lösung in großem Maßstab bewältigen werden muss.

Aufbau

Architecture diagram of remote patient monitoring architecture using healthcare devices and Azure services.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Datenfluss

  1. Patientengeräte generieren physiologische und Aktivitätsdaten. Die Daten werden dann mit einem der verfügbaren Microsoft Open-Source-SDKs (OSS) aus den Geräten ausgelesen und von Azure Event Hubs erfasst.

  2. Die Life365.health-Plattform unterstützt über 300 Geräte, die physiologische und Aktivitätsdaten generieren Die Life365-API erfasst die physiologischen und Aktivitätsdaten der Patientenüberwachungsgeräten in Azure Event Hubs.

  3. Der Azure Medizintechnikdienst ruft die Gerätemessungen aus Event Hubs ab, wandelt sie in das FHIR-Format Fast Healthcare Interoperability Resources (FHIR®) um und übergibt sie an den Azure FHIR-Dienst. Der Arbeitsbereich von Azure Health Data Services ist ein logischer Container für Pflegedienstinstanzen wie z. B. die FHIR- und Medizintechnikdienste.

  4. Der Arbeitsbereich von Azure Health Data Services sendet Benachrichtigungen an Ereignisabonnenten, wenn eine FHIR-Ressource erstellt, aktualisiert oder im Azure FHIR-Dienst gelöscht wird. Die Benachrichtigungen können an mehrere Endpunkte gesendet werden und Automatisierungen auslösen, um Workflows zu starten oder E-Mails und Textnachrichten zu senden.

  5. FHIR Analytics-Pipelines exportieren inkrementell anonymisierte FHIR-Daten zu Azure Data Lake, wodurch sie mit verschiedenen Azure-Datendiensten analysiert werden können. Die exportierten Daten können auch mit Tools wie den Open-Source-Tools für die Anonymisierung von Gesundheitsdaten von Microsoft anonymisiert werden. Die Standardmäßige Anonymisierung basiert auf der HIPAA Safe Harbor-Methode, die bei Bedarf erweitert und geändert werden kann.

    Wichtig

    Die exportierten FHIR-Daten in diesem Datenfluss sind Rohdaten und enthalten PHI-Informationen. Die Anonymisierung kann verwendet werden, um persönliche Identifikatoren für Forschungs- oder Freigabezwecke aus den Daten zu entfernen. Wenn Sie anonymisierte Datensätze wünschen, müssen Sie vor dem Export Maßnahmen ergreifen, um die Daten zu anonymisieren, indem Sie ein Tool wie das oben genannte verwenden.

  6. Die weitere Analyse der FHIR-Daten in Parquet- und JSON-Formaten erfolgt mithilfe von Spark-Pools in Azure Synapse, Azure Databricks und Azure ML-Diensten (Machine Learning).

  7. SQL-Ansichten werden in den serverlosen SQL-Pools in Azure Synapse erstellt. Für jede FHIR-Ressource wird auf Basis der Parquet-Dateien im Azure Data Lake eine SQL-Ansicht erstellt. Auf Basis dieser Ansichten können Datentechniker und Entwickler native SQL in Microsoft SQL Management Studio oder einen anderen SQL-Editor schreiben, um FHIR-Ressourcen abzufragen.

  8. Power BI und der Power Query Connector für FHIR werden verwendet, um Daten direkt vom FHIR Service-API-Endpunkt zu importieren und zu formen. Power BI bietet zudem Parquet- und SQL-Connectors für den Zugriff auf die FHIR-Ressource direkt im Parquet-Format oder über die SQL-Ansichten in Synapse.

Komponenten

Geräte

Verbrauchergeräte

Microsoft bietet Open-Source-SDKs an, um die Übertragung von Daten von verschiedenen Verbrauchergeräten für die Erfassung durch Azure Event Hubs zu erleichtern:

Life365.health-unterstützte medizinische Geräte

Die Life365.health-Plattform bietet Integration mit über 300 Bluetooth-Überwachungsgeräten für die Erfassung durch Azure Event Hubs. Die Geräte umfassen mehrere Kategorien und Hersteller, darunter Spirometer, Thermometer, Waagen, Tablettenerinnerungen, Aktivitäts-Tracker, Blutzuckermessgeräte, Blutdrucküberwachungsgeräte, EKG, Fötaldoppler, Herzfrequenzüberwachugnsgeräte, Pulsoximeter, Schlaf-Tracker und mehr. Die Life365-App ermöglicht zudem die manuelle Aufzeichnung von erfassten Werten, die von nicht Bluetooth-Geräten stammen. Diese Architektur nutzt die Life365-API, um Gerätemessungen aus den Life365-Geräten in Event Hubs zu erfassen.

Andere

Während die obigen Optionen Vereinfachungen bieten, unterstützt diese Architektur alle ähnlichen Datenquellen, die sicher in Event Hubs erfasst werden können, ob direkt oder indirekt über eine zwischengeschaltete API.

Azure-Dienste (Sammlung und Speicherung von Daten)

  • Azure Event Hubs: Vollständig verwalteter Echtzeitdienst zur Datenerfassung, der einfach, vertrauenswürdig und skalierbar ist. Streamen Sie Millionen von Ereignissen pro Sekunde aus beliebigen Quellen, um dynamische Datenpipelines zu erstellen, und reagieren Sie sofort auf geschäftliche Herausforderungen. In dieser Architektur kommt dies beim Sammeln und Aggregieren der Gerätedaten für die Übertragung an Azure Health Data Services zum Einsatz.

  • Azure Health Data Services besteht aus einer Reihe verwalteter API-Dienste, die auf offenen Standards und Frameworks basieren und Workflows zur Verbesserung des Gesundheitswesens sowie skalierbare und sichere Lösungen in diesem Sektor bieten. Zu den in dieser Architektur verwendeten Diensten gehören die Folgenden:

    • Arbeitsbereich von Azure Health Data Services: Stellt einen Container für die anderen Instanzen von Azure Health Data Services bereit, wodurch ein Compliancebereich (HIPAA, HITRUST) erstellt wird, durch den geschützte Gesundheitsinformationen übertragen werden können.

    • Azure FHIR-Dienst: Erleichtert das sichere Speichern und Austauschen geschützter Gesundheitsinformationen (PHI, Protected Health Information) in der Cloud. Gerätedaten werden in FHIR-basierte Beobachtungsressourcen umgewandelt, um die Remote-Patientenüberwachung zu unterstützen.

    • Azure Medizintechnikdienst: Ein Eckpfeiler von Microsoft Cloud for Healthcare, der zur Unterstützung der Remote-Patientenüberwachung dient. MedTech ist eine Platform-as-a-Service (PaaS), mit der Sie Daten aus verschiedenen medizinischen Geräten in Echtzeit sammeln, in ein FHIR-kompatibles Serviceformat umwandeln und in einem FHIR-Dienst speichern können. Die Gerätedatenübersetzungsfunktionen des Medizintechnikdiensts ermöglichen es, eine Vielzahl von Daten in ein einheitliches FHIR-Format zu transformieren, das sichere Datenverwaltung in einer Cloudumgebung erlaubt.

      Der Medizintechnikdienst ist für die Remote-Patientenüberwachung wichtig, da der Zugriff auf und die Analyse von Gesundheitsdaten schwierig sein können, wenn Daten von verschiedenen oder inkompatiblen Geräten bzw. Systemen stammen und/oder in verschiedenen oder inkompatiblen Formaten vorliegen. Schwierigkeiten bei der Erfassung medizinischer Informationen können klinische Erkenntnisse und den Gesundheitsplan des Patienten beeinträchtigen. Die Möglichkeit, Gesundheitsdaten in ein einheitliches FHIR-Format zu übersetzen, ermöglicht dem Medizintechnikdienst die erfolgreiche Verknüpfung von Geräten, Gesundheitsdaten, Labors und Remote-Personenversorgung. Somit kann diese Funktion die Entdeckung wichtiger klinischer Erkenntnisse und die Erfassung von Trends erleichtern, um Mediziner, Pflegekräfte und Familien zu unterstützen. Sie ermöglicht auch die Verbindung zu neuen Geräteanwendungen und fortschrittliche Forschungsprojekte. Genauso wie Pflegepläne für jeden Fall individuell angepasst werden können, können Remote-Patientenüberwachungsszenarien und Anwendungsfälle je nach Einzelfall variieren.

  • Azure Event Grid: Der Azure Health Data Services-Ereignisdienst generiert Ereignisse, wenn eine FHIR-Ressource erstellt, aktualisiert oder gelöscht wird (CUD, Created, Updated or Deleted). Diese Ereignisse können von Azure Event Grid an nachgelagerte Verbraucher übertragen werden, damit diese auf ereignisbasierte Daten reagieren können.

Azure-Dienste und -Tools (Datenanalyse)

  • FHIR Analytics-Pipelines: Ein OSS-Projekt, das zum Erstellen von Komponenten und Pipelines dient, die für die Rechteckigmachung und das Verschieben von FHIR-Daten von Azure FHIR-Servern in Azure Data Lake verwendet werden. In dieser Architektur werden die Daten in die Formate JavaScript Object Notation (JSON) und Parquet konvertiert, wodurch sie für Analysen mit verschiedenen Azure-Datendiensten verfügbar werden.

  • Tools für die Anonymisierung von Gesundheitsdaten: Ein OSS-Projekt, das vom Microsoft Healthcare-Team unterstützt wird und dabei hilft, Gesundheitsdaten lokal oder in der Cloud zu anonymisieren, wodurch diese für sekundäre Nutzungszwecke wie Forschung, das Gesundheitswesen und vieles mehr verwendet werden können. Das Anonymisierungskernmodul verwendet eine Konfigurationsdatei, um verschiedene Parameter anzugeben, sowie Anonymisierungsmethoden für verschiedene Datenelemente und Datentypen.

  • Azure Synapse Analytics: Ein uneingeschränkter Analysedienst, der Datenintegration, Data Warehousing für Unternehmen und Big Data-Analysen vereint. Ermöglicht flexible Datenabfragen nach Ihren Vorgaben mit serverlosen oder dedizierten Optionen im großen Stil. Azure Synapse vereint diese Ansätze in einer vereinheitlichten Oberfläche für die Erfassung, Erkundung, Aufbereitung, Transformation, Verwaltung und Verarbeitung von Daten für dringende BI- und Machine Learning-Anforderungen.

  • Apache Spark-Pools: Apache Spark ist ein Framework für die Parallelverarbeitung, das In-Memory-Verarbeitung unterstützt, um die Leistung von Big Data-Analyseanwendungen zu steigern. Apache Spark in Azure Synapse Analytics ist eine der cloudbasierten Apache Spark-Implementierungen von Microsoft. Azure Synapse vereinfacht das Erstellen und Konfigurieren eines serverlosen Apache Spark-Pools in Azure. Spark-Pools in Azure Synapse sind mit Azure Storage sowie mit Azure Data Lake Storage der zweiten Generation kompatibel. Dadurch können Sie Spark-Pools für die Verarbeitung Ihrer in Azure gespeicherten Daten verwenden.

  • Azure Databricks: Eine Datenanalyseplattform, die für die Microsoft Azure-Clouddienstplattform optimiert ist. Databricks bietet eine einheitliche Analyseplattform für Datenanalysten, technische und wissenschaftliche Fachkräfte für Daten sowie technische Fachkräfte für maschinelles Lernen. Sie bietet drei Umgebungen für die Entwicklung datenintensiver Anwendungen: Databricks SQL, Databricks Data Science & Engineering und Databricks Machine Learning.

  • Azure ML: Ein Azure-Clouddienst zum Beschleunigen und Verwalten des Lebenszyklus von Machine Learning-Projekten. Machine Learning-Experten, wissenschaftliche Fachkräfte für Daten und Techniker können sie in ihren täglichen Workflows verwenden: Trainieren und Bereitstellen von Modellen und Verwalten von MLOps. Sie können ein Modell in Azure Machine Learning erstellen oder ein Modell verwenden, das auf einer Open-Source-Plattform wie Pytorch, TensorFlow oder scikit-learn erstellt wurde. MLOps-Tools helfen Ihnen beim Überwachen, erneuten Trainieren und erneuten Bereitstellen von Modellen.

  • Power BI: Bietet Self-Service-Analysen im Unternehmensmaßstab und ermöglicht Folgendes:

    • Schaffung einer datengesteuerten Kultur mit Business Intelligence für alle.
    • Schutz Ihrer Daten mit branchenweit führenden Sicherheitsfunktionen wie Vertraulichkeitskennzeichnungen, End-to-End-Verschlüsselung und Echtzeitzugriffsüberwachungen. Wird für eine weitere Analyse von FHIR-Daten verwendet.

  • Power Query Connectors für die Verwendung mit Power BI umfassen:

  • SQL Server Management Studio: Eine Desktop-App für die Erstellung nativer SQL-Abfragen an SQL-Datenspeicher, z. B. Azure Synapse Analytics SQL-Pools.

Alternativen

Life365.health

Der Vorteil von Life365.health liegt darin, dass Sie über einen Integrationspunkt Messungen aus einer Vielzahl von Geräten im Life365-Ökosystem zu Azure Health Data Services weiterleiten können. Es gibt auch andere APIs für tragbare Geräte, z. B. Garmin Activity API und Polar AccessLink-API, für die ähnliche Integrationsmuster erreicht werden können. Diese APIs sind jedoch ausschließlich für Messungen von Geräten ihrer eigenen Hersteller wie Garmin und Polar geeignet.

Geräte und Patienten müssen definiert und mit Azure Health Data Services und der Life365-API verknüpft und synchronisiert werden. Diese Konfiguration erfolgt über die Synchronisierung von Patienten- und Geräte-IDs zwischen der Azure Health Data Services- und Life365-API. Im Wesentlichen werden ein neuer Patient und ein neues Gerät zunächst im Azure FHIR-Dienst erstellt und verknüpft. Anschließend werden der entsprechende Patient und das entsprechende Gerät in der Life365-API erstellt und verknüpft. Die IDs der Patienten und Geräte, die zuerst in Azure Health Data Services erstellt wurden, werden dann als externe IDs in den jeweiligen Patienten- und Geräteentitäten in der Life365-API aktualisiert.

Microsoft Cloud für das Gesundheitswesen

Dieses Beispiel behandelt eine Möglichkeit zur Implementierung einer Remote-Patientenüberwachungslösung. Microsoft Cloud for Healthcare bietet auch eine Lösung für die Remote-Patientenüberwachung. Weitere Informationen zu dieser Lösung finden Sie in der Interaktiven Tour zur Remote-Patientenüberwachung.

Szenariodetails

Es gibt heute eine Fülle an medizinischen und tragbaren/Verbrauchergeräten. Um auf Gerätemessungen zugreifen zu können, bieten viele der In-Home-Überwachungsgeräte (z. B. Blutdruckmessgeräte, Waagen... usw.) Bluetooth-Konnektivität (z. B. Bluetooth Low Energy oder andere ältere Versionen des Bluetooth-Standards). Es gibt auch tragbare Verbrauchergeräte sowie fortschrittlichere In-Home-Geräte, die API-Konnektivität für den Zugriff auf Gerätemessungen bieten. In diesem Fall können die Geräte die Messwerte direkt über die (WLAN-fähige) API synchronisieren oder (über Bluetooth) eine Verbindung mit einer mobilen App auf einem Smartphone herstellen, sodass die App den Messwert wieder mit der API synchronisieren kann.

Problembeschreibung

Angesichts der breiten Palette medizinischer tragbarer und In-Home-Geräte und der Konnektivitätsoptionen (von Bluetooth bis API) sowie der Anzahl der Patienten innerhalb einer Gesundheitsorganisation kann die Integration und Orchestrierung von Daten zu einer schwierigen Aufgabe werden.

Mögliche Anwendungsfälle

  • Klinische Studien und Forschung: Helfen Sie klinischen Forschungsteams bei der Integration und Bereitstellung eines breiten Spektrums an medizinischen tragbaren und In-Home-Geräten für Studienteilnehmer. Mit anderen Worten: Bieten Sie Ihren Studienteilnehmern eine Bring-Your-Own-Device-Option (BYOD).

  • Datenwissenschaften und Bevölkerungsgesundheitsanalysen: Die physiologischen und Aktivitätsdaten stehen im branchenüblichen FHIR-Format sowie in anderen Open-Source-Datenformaten (JSON und Parquet) zur Verfügung. Zusätzlich zum Datenformat werden systemeigene Connectors für die Datenanalyse und Transformation bereitgestellt. Dazu gehören Connectors wie der Power BI-Connector für FHIR, Synapse Serverless SQL-Ansichten und Spark-Cluster in Synapse.

    Diese Lösung bietet auch eine parametrisierte Methode für die Anonymisierung des Datensatzes für Forschungszwecke. Diese „Daten für die sekundäre Nutzung“ können analysiert und verwendet werden, um Best Practices zu erarbeiten und evidenzbasierte klinische Workflows zu unterstützen. Auf dem FHIR-Server gespeicherte Beobachtungen können verwendet werden, um die Varianten und Workflows zu finden, die zu den besten Ergebnisse und Methoden führen.

  • Möglichkeiten für Gesundheitsanbieter: Anbieter können:

    • bessere Einblicke in den Gesundheitsstatus des Patienten erhalten
    • proaktive digitale Gesundheitsversorgungsmodelle für die präventive medizinische Versorgung schaffen
    • mit besseren Informationen Maßnahmen auf Grundlage physiologischer Indikatoren ergreifen
    • Möglichkeiten zur Erstattung von physiologischen Remote-Überwachungen bereitstellen

  • Fragebogen für Patienteneinschätzungen (Patient Reported Outcome, PRO) und PRO-gesteuerte Pflege: Anhand von Ereignissen und PRO-Fragebögen können individualisierte Pflegepläne und Individualisierungsworkflows erstellt werden. Patienten erhalten mehr Autonomie und Kontrolle über den individualisierten Pflegeplan, was die Akzeptanz und nachhaltige Nutzung fördert. PRO-gesteuerte Pflege kann auch helfen, die Lücke zwischen Bildung und Patientenergebnissen zu schließen. RPM kann Bildungsfragebögen und PROs verknüpfen, um die medikamentöse Behandlung, die Behandlung an sich und/oder die Nachsorge zu verbessern. Dazu dienen z. B. die folgenden Fragen:

    • Nehmen Patienten ihre verschriebenen Medikamente richtig?
    • Wird die Waage zur richtigen Zeit und oft genug verwendet?
    • Werden PROs für die Patientenakzeptanz und die Planung individualisierter Pflege genutzt?

    Für Patienten, die iOS-Geräte verwenden, können Fragebogen-Apps mithilfe des Apple ResearchKit erstellt werden. Fragebogendaten werden von Azure Event Hubs aufgenommen und über den FHIR-Dienst verfügbar gemacht, genau wie Patientenaktivität an Geräten und physiologische Daten.

  • Ermöglichung verschiedenartiger und präziserer Gesundheitsgeräte: Verwenden Sie klinische und private medizinische Geräte, um Gesundheitsdaten nahezu in Echtzeit zu generieren, erfassen und analysieren.

Ü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.

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie in der Überblick über die Säule „Zuverlässigkeit“.

Die Verfügbarkeit von klinischen Daten und Erkenntnissen in Echtzeit ist für viele Organisationen im Gesundheitswesen von entscheidender Bedeutung. Hier finden Sie Möglichkeiten, Ausfallzeiten der in dieser Lösung angegebenen Azure-Dienste zu minimieren:

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“.

Gesundheitsdaten beinhalten oftmals geschützte, vertrauliche Gesundheitsinformationen (PHI) und personenbezogene Informationen. Die folgenden Ressourcen sind verfügbar, um diese Daten zu schützen:

  • Data Lake Storage verwendet die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) von Azure und Zugriffssteuerungslisten (Access Control Lists, ACLs), um ein Zugriffssteuerungsmodell zu schaffen

  • Azure Health Data Services ist eine Sammlung geschützter verwalteter Dienste unter Verwendung von Microsoft Entra ID, einem globalen Identitätsanbieter, der OAuth 2.0 unterstützt. Wenn Sie einen neuen Dienst für Azure Health Data Services erstellen, werden Ihre Daten standardmäßig mit von Microsoft verwalteten Schlüsseln verschlüsselt. Weitere Informationen finden Sie unter Authentifizierung und Autorisierung für Azure Health Data Services.

  • Azure Event Hubs ermöglicht die Verschlüsselung ruhender Daten mit Azure Storage Service Encryption (Azure SSE). Somit können die IP-Firewallregeln auf der Event Hubs-Namespaceebene angewendet werden. Ebenso kann der Zugriff auf private Endpunkte und virtuelle Netzwerke konfiguriert werden.

  • Synapse RBAC erweitert die Funktionen von Azure RBAC auf Synapse-Arbeitsbereiche und deren Inhalte. Azure RBAC dient zum Verwalten der Benutzer, die den Synapse-Arbeitsbereich und die zugehörigen SQL-Pools, Apache Spark-Pools und Integration Runtimes erstellen, aktualisieren oder löschen können.

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“.

Die Kosten vieler Azure-Komponenten finden Sie im Azure-Preisrechner. Letztendlich hängt der Preis für diese Lösung unter anderem von folgenden Faktoren ab:

  • Den verwendeten Azure-Diensten
  • Dem Datenvolumen in Bezug auf die Anzahl der Patienten/Geräte und die Anzahl der erfassten physiologischen und Aktivitätsdatentypen.
  • Den Kapazitäts- und Durchsatzanforderungen für Event Hubs.
  • Den erforderlichen Compute-Ressourcen für die Ausführung von Machine Learning-Trainings und -Bereitstellungen, Synapse Spark Pools und Databricks-Clustern.
  • Der Visualisierungs- und Berichterstellungslösung, z. B. Power BI.

Beachten Sie bei der Implementierung dieser Lösung die Datenaufbewahrungs- und Archivierungsrichtlinien für den zugrunde liegenden Azure Data Lake. Nutzen Sie die Azure Storage-Lebenszyklusverwaltung, die folgende Automatisierungen bietet:

  • Übertragung von Datei-Blobs auf die kalte Speicherebene
  • Archivspeicherebenen auf Basis des Zeitpunkts der letzten Dateiänderung.

Weitere Informationen zu Life365.health-Plänen und Kosten finden Sie im Angebot zu Life365 API Connect Data auf dem Microsoft Azure Marketplace

Effiziente Leistung

Leistungseffizienz ist die Fähigkeit Ihrer Workload, auf effiziente Weise eine den Anforderungen der Benutzer entsprechende Skalierung auszuführen. Weitere Informationen finden Sie unter Übersicht über die Säule „Leistungseffizienz“.

Diese Lösung bietet eine skalierbare Architektur für die Remote-Patientenüberwachung nahezu in Echtzeit. Es ist wichtig, den mehrschichtigen Datenfluss von der Schnittstelle zwischen den Geräten und der Life365-API bis zur Erfassung über die Life365-API und Azure Event Hubs, zur Transformation im Medizintechnikdienst in Azure Health Data Service und schließlich zu inkrementellem Export und Anonymisierung beim Wechsel in das Data Lake-Format zu beachten. Daher wird der Datenfluss nahezu in Echtzeit verarbeitet, worauf alle nachgelagerten Anwendungen und/oder Integrationen ausgerichtet sein sollten. Die Leistung dieser Lösung kann jedoch auf Unternehmensebene auf eine große Anzahl von Geräten und Patienten skaliert werden.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

Relevante Technologien und Ressourcen für die Implementierung dieser Architektur: