Erfahren Sie, wie OCI KI und ML die Patientenerfahrung verbessern

Wie bei jedem Unternehmen benötigt das Gesundheitswesen die Möglichkeit, auf große Datenmengen zuzugreifen, zu analysieren, zu manipulieren und zu speichern. Diese Art der Datenverarbeitung steht im Mittelpunkt der Technologien hinter dem Oracle Cloud Infrastructure Lakehouse (Data Lakehouse), mit denen künstliche Intelligenz (KI) und maschinelles Lernen (ML) die Patientenerfahrung verbessern können.

Die Einrichtung eines Gesundheitssystems im Hinblick auf die Patientenerfahrung sollte Folgendes berücksichtigen:

• Genaue Patienteninformationen für Ärzte so schnell wie möglich zu erhalten, mit einer Benutzerfreundlichkeit, die unnötige Belastungen beseitigt, sodass der Arzt möglichst viel Zeit für den Fall des Patienten aufwenden kann.
• Den Patienten so schnell wie möglich von Symptomen zur Genesung zu bewegen.
• Sicherstellen, dass der Prozess so kosteneffizient wie möglich ist, unabhängig davon, ob der Patient, seine Krankenversicherung oder ein Gesundheitsdienst (e.g, National Health Service in UK) die Kosten übernimmt.

Ein Hausarzt (GP) oder ein Erstversorgungsunternehmen (PCP) glauben, dass der Patient Anzeichen einer Pneumonie aufweist. Sie verwiesen den Patienten auf ein medizinisches Zentrum (Krankenhaus oder Bildgebungszentrum) für einen Brust-Röntgen, um zu untersuchen, ob Pneumonie oder etwas anderes die Symptome des Patienten verursacht. Der erste Schritt in diesem Prozess ist die Einrichtung eines Termins mit dem medizinischen Zentrum und die gemeinsame Nutzung des elektronischen medizinischen Datensatzes (EMR) oder des elektronischen Gesundheitsdatensatzes (EHR). Idealerweise würden diese Daten in das Daten-Lakehouse eingebunden.

Die Radiologie-Mitarbeiter im medizinischen Zentrum würden die Röntgenaufnahmen nehmen, aber ab diesem Zeitpunkt spielen die Datenlakehouse und verwandte Technologien eine aktive Rolle im Diagnoseprozess. Das Röntgenbild wird mit dem Radiologieinformationssystem (RIS) erstellt und entweder mit dem Bildarchivierungs- und Kommunikationssystem (PACS) oder einer neueren Generation von Datenspeichern wie dem Vendor Neutral Archive (VNA) gespeichert. Die Bilder werden wahrscheinlich mit einem medizinischen Bildformat wie Digital Imaging and Communications in Medicine (DICOM) gespeichert, das ein sehr hochauflösendes Bild mit seinen zugehörigen Metadaten speichert, wie z.B. Details darüber, wo und wann das Bild erzeugt wurde, und die Art der Modalität (wie das Bild erfasst wurde). Diese Metadaten sind mit dem korrekten Patienten und dessen Aufzeichnungen verknüpft.

Sobald Bilder erfasst wurden, prüft und interpretiert ein Arzt jeden einzelnen, um die klinischen Bedürfnisse des Patienten zu ermitteln. Dies ist ein zeitaufwändiger Prozess, der oft dazu führt, dass der Patient zu Hause auf weitere Informationen wartet.

Dieses Playbook konzentriert sich darauf, wie ein Data Lakehouse an Lösungen beteiligt ist, die Ergebnisse liefern, die wir beschrieben haben.

Dieses Playbook wird sich auf die Systeme konzentrieren, die an einem Anwendungsfall beteiligt sind, an dem ein regionales Krankenhaus beteiligt ist, und wird verwandte Bereiche aufrufen, aber nicht in Lösungsdetails gehen.

Architektur

Diese Architektur zeigt ein medizinisches Zentrum, das auf ein OCI-Data Lakehouse zugreift und diese verwendet.

Beschreibung der Abbildung Healthcare-lakehouse-topology-diagram.png

1. Beim anfänglichen Setup ist wahrscheinlich die effiziente, kostengünstige und schnelle Migration aller vorhandenen Daten aus der PACS-Lösung in Oracle Cloud Infrastructure (OCI) zur Verarbeitung erforderlich. Wenn die Konnektivitätsperformance für laufende Vorgänge problematisch war, kann dies auf tägliche Transfers erweitert werden. Zusätzlich zu den PAC-Daten kann dies eine Möglichkeit sein, Patientendatensätze und zugehörige Informationen im Massenversand zu versenden.
2. Weitere Datenquellen wie die Zusammenarbeit beim Austausch von EMRs zwischen Gesundheitsdienstleistern könnten den GP oder den PCP des Patienten umfassen.
3. Funktionen werden bereitgestellt, um komplexe Datenmanipulationen durchzuführen. Beispiel: Sie extrahieren die Metadaten aus einem DICOM-Image. Diese Prozesse sind zu komplex, um innerhalb der Persistenztools und Geschäftslogik effektiv umgesetzt zu werden. Dies bedeutet, dass wir bei jedem Einführen eines neuen komplexen unstrukturierten Datenobjekts, wie z.B. eines neuen Bildtyps, neue Logik einheften können.
4. Daten in und aus den Diensten unterstützen den Austausch von EHR/EMR für Patienten.
5. Je mehr Daten im Zusammenhang mit den Anwendungsfällen bezogen werden können, wie z.B. zusätzliche Einblicke in die Patienten, desto mehr Erkenntnisse können erzielt werden. Beispiel: Der CDC-Datensatz Social Determinants of Health (SDOH) stellt APIs für sozioökonomische Indikatoren für verschiedene Gesundheitsbedingungen bereit.
6. Dies spiegelt die Anzahl der Services wider, die direkt oder indirekt zur Unterstützung der Sicherheits- und Plattform- und Lösungsoperabilität verwendet werden.
7. Data Lakehouse-Services sind gruppiert. Je nach Anwendungsfall sind möglicherweise nicht alle Services erforderlich.
8. Es wird davon ausgegangen, dass die primäre Erwartung Web Service-orientiert ist, da Dritte die Verarbeitung ihrer Daten verbergen. Dies spiegelt auch die Richtung der Entwicklung von Standards wie FHIR wider.

Wie das Diagramm zeigt, werden die Daten, die zwischen dem medizinischen Zentrum und der OCI-Umgebung fließen, über ein VPN gesichert und in Bezug auf die Performance mit Oracle Cloud Infrastructure FastConnect (FastConnect) gewährleistet, obwohl die große Anzahl der Bildgebungsdaten hin- und herverschoben wird.

Die PACS- oder VNA-Lösung kann je nach Fähigkeiten der PACS-Lösung auf verschiedene Weise integriert werden, von der einfachen Freigabe des PACS-Speichers an einen eingeschränkten FTP-Server, der regelmäßig abgefragt werden kann (e.g, alle 10 bis 15 Minuten), bis hin zu API-Spezifikationen, die mit dem DICOM Communication Model for Message Exchange abgestimmt sind. Im Architekturdiagramm sehen wir, dass die Nutzung von OCI-Funktionen zum Verschieben von On-Premise-PACS auch eine Möglichkeit ist.

Benutzerdefinierte Funktionen werden bereitgestellt, die bildbezogene Metadaten in DICOM extrahieren können. Die extrahierten Metadaten können separat gespeichert werden, um eine schnelle Suche des Inhalts zu unterstützen, da die Bilder nicht bei jeder Suche abgefragt werden müssen.

Obwohl die Integration mit anderen Datenquellen über verschiedene Protokolle und Technologien erfolgen kann, ist der bevorzugte Mechanismus die Einführung von FHIR-REST-APIs. Die verfügbaren Integrationstools bieten jedoch ein breites Spektrum an Integrationstechnologien und -protokollen. Beachten Sie, dass die Abbildung mit FHIR nicht unterstützt werden kann, da der Standard solche Daten derzeit nicht unterstützt.

Während Daten zentralisiert sind, um das Provisioning der Datenbank zu nutzen, ermöglicht die Verwendung von Oracle Cloud Infrastructure Data Catalog und API-Gateway Unternehmen die Entwicklung zu den Ideen eines Data Mesh. Insbesondere die Dezentralisierung der Dateneigentümerschaft durch die Offenlegung von Daten in einer Weise, in der die Dateneigentümer zufrieden sind. Darüber hinaus bietet die API eine Möglichkeit, einen effizienten Zugriff auf Daten zu erreichen und gleichzeitig die Zugriffskontrolle durchzusetzen. Dies bedeutet, dass dieselben Daten verschiedenen Verbrauchern für verschiedene Zwecke zur Verfügung gestellt werden können, während sie nicht durch das Verhalten und die Bedürfnisse der Verbraucher beeinträchtigt werden (e.g, Daten werden sowohl mobilen Mitarbeitern als auch Ärzten mit Patienten auf medizinischen Visualisierungsplattformen zur Verfügung gestellt).

Diese Architektur unterstützt die folgenden Data Lakehouse-spezifischen Services:

• Objektspeicher

  Mit Object Storage können Sie schnell auf große Mengen an strukturierten und unstrukturierten Daten eines beliebigen Inhaltstyps zugreifen, darunter Datenbankbackups, Analysedaten und umfangreiche Inhalte, wie Bilder und Videos. Sie können Daten sicher und geschützt speichern und dann direkt aus dem Internet oder aus der Cloud-Plattform abrufen. Sie können den Speicher nahtlos skalieren, ohne dass die Performance oder Servicezuverlässigkeit beeinträchtigt wird. Verwenden Sie Standardspeicher für "Hot Storage", auf den Sie schnell, sofort und häufig zugreifen müssen. Verwenden Sie Archivspeicher für "Cold Storage", den Sie über lange Zeiträume beibehalten haben, und auf den Sie nur selten zugreifen.

  In diesem Kontext würde Object Storage verwendet, um unstrukturierten Inhalt wie Röntgenbilder zu speichern und dann von strukturierteren Daten, einschließlich der Bildmetadaten, referenziert zu werden, um die Bilder schnell durchsuchbar zu machen.

• Data Catalog

  Oracle Cloud Infrastructure Data Catalog ist eine vollständig verwaltete Selfservice-Lösung für Daten-Discovery und Governance für Ihre Unternehmensdaten. Sie stellt Data Engineers, Data Scientists, Data Stewards und Chief Data Officers eine einzelne kooperative Umgebung zur Verwaltung der technischen, geschäftlichen und betrieblichen Metadaten der Organisation bereit.

  Der Datenkatalog in seinem Kontext trägt dazu bei, die Datenassets zu verstehen und zu erfahren, wie sie im Lakehouse verarbeitet werden können, um zusätzliche Einblicke zu erhalten. Dies deckt intern gespeicherte Daten- und Drittanbieter-Datenressourcen ab, die über Mechanismen wie API-Aufruf und Dateiübertragung in das Lakehouse übertragen werden können. Andere Technologien sind für die Datenaufnahme verfügbar, APIs und Dateien sind jedoch die gängigsten Modelle.

• Datenintegration

  Mit Oracle Cloud Infrastructure Data Integration können Sie einen optimalen Datenfluss zwischen Systemen erzielen.

  Sie unterstützt deklarative und No-Code- oder Low-Code-ETL- und Datenpipeline-Entwicklung. Für das Lakehouse wäre dies eines der primären Datenmanipulations- und Verarbeitungstools.

  Data Integration kann auch angewendet werden, um Aufgaben auszuführen, wie die Transformation von Daten aus halbstrukturierten in vollständig strukturierte, minierbare Daten. Führen Sie Aktivitäten wie die Datenbereinigung aus, damit schmutzige oder beschädigte Daten die Ergebnisse nicht verfälschen können.

• Datenfluss

  Oracle Cloud Infrastructure Data Flow ist ein vollständig verwalteter Apache Spark-Service, der Verarbeitungsaufgaben für riesige Datasets ausführt - ohne dass die Infrastruktur bereitgestellt oder verwaltet werden muss. Entwickler können auch Spark Streaming verwenden, um Cloud-ETL für ihre kontinuierlich produzierten Streamingdaten auszuführen. Dies ermöglicht eine schnelle Anwendungsbereitstellung, da Entwickler sich auf die App-Entwicklung konzentrieren können, nicht auf die Infrastrukturverwaltung.

  Data Flow unterstützt die Verarbeitung von Daten in einer Ereignis- oder Timerreihe. Dies bedeutet, dass mehr Analysen durchgeführt werden können, wenn Dinge geschehen, anstatt zu warten, bis alle Daten empfangen wurden.

• Big Data-Service

  Mit Oracle Big Data Cloud Service können Datenexperten Raw-Daten verwalten, katalogisieren und verarbeiten. Oracle bietet Objektspeicher und Hadoop-basierte Data Lakes für Persistenz.

• Autonomous Database

  Oracle Cloud Infrastructure Autonomous Database ist eine vollständig verwaltete, vorkonfigurierte Datenbankumgebungen, die Sie zur Transaktionsverarbeitung und Data Warehousing-Workloads verwenden können. Sie müssen keine Hardware konfigurieren oder verwalten und keine Software installieren. Oracle Cloud Infrastructure verarbeitet das Erstellen der Datenbank sowie das Backup, Patching, Upgrade und Tuning der Datenbank.

Empfehlungen

Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt. Ihre Anforderungen können sich von der hier beschriebenen Architektur unterscheiden.

• Virtuelles Cloud-Netzwerk (VCN) und Subnetz

  Ein VCN ist ein anpassbares, Softwaredefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region einrichten können. Wie bei traditionellen Data Center-Netzwerken haben VCNs die vollständige Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere sich nicht überschneidende CIDR-Blöcke aufweisen, die Sie nach dem Erstellen des VCN ändern können. Sie können ein VCN in Subnetze segmentieren, die sich auf eine Region oder eine Availability-Domain skalieren lassen. Jedes Subnetz besteht aus einem nachfolgenden Adressbereich, der sich nicht mit den anderen Subnetzen im VCN überschneidet. Sie können die Größe eines Subnetzes nach der Erstellung ändern. Ein Subnetz kann öffentlich oder privat sein.

• Cloud Guard

  Mit Oracle Cloud Guard können Sie die Sicherheit Ihrer Ressourcen in Oracle Cloud Infrastructure überwachen und verwalten. Cloud Guard verwendet Detektorrezepte, mit denen Sie Ihre Ressourcen auf Sicherheitsschwächen untersuchen und Operatoren und Benutzer auf riskante Aktivitäten überwachen können. Wenn falsche oder unsichere Aktivitäten erkannt werden, empfiehlt Cloud Guard Korrekturmaßnahmen und hilft Ihnen, diese Aktionen basierend auf Responder-Rezepten auszuführen, die Sie definieren können.

• Sicherheitszone

  Sicherheitszonen stellen die Best Practices der Oracle-Sicherheit von Anfang an sicher, indem Policys wie das Verschlüsseln von Daten und das Verhindern des öffentlichen Zugriffs auf Netzwerke für ein gesamtes Compartment durchgesetzt werden. Eine Sicherheitszone ist mit einem Compartment mit demselben Namen verknüpft und enthält Sicherheitszonen-Policys oder ein "Rezept", das für das Compartment und die zugehörigen Sub-Compartments gilt. Sie können ein Standard Compartment zu einem Sicherheitszonen-Compartment hinzufügen oder verschieben.

• Netzwerksicherheitsgruppe (NSG)

  Netzwerksicherheitsgruppe (NSG) fungiert als virtuelle Firewall für Ihre Cloud-Ressourcen. Mit dem Zero-Trust-Sicherheitsmodell von Oracle Cloud Infrastructure wird der gesamte Traffic abgelehnt, und Sie können den Netzverkehr in einem VCN kontrollieren. Eine NSG besteht aus einer Gruppe von Ingress- und Egress-Sicherheitsregeln, die nur für eine angegebene Gruppe von VNICs in einem einzelnen VCN gelten.

• Load Balancer

  Der Oracle Cloud Infrastructure Load Balancing-Service ermöglicht automatisierte Trafficverteilung von einem einzelnen Einstiegspunkt auf mehrere Server im Backend.

Hinweise

Berücksichtigen Sie beim Deployment dieser Referenzarchitektur die folgenden Optionen.

• Datenquellen

  Wir sehen die Möglichkeit von IoT-Lösungen, kontinuierlich Daten über einen Patienten zu überwachen und zu melden, wie Herzfrequenz, und Apps, mit denen Patienten einfach Ereignisse wie Ernährungsgewohnheiten oder medizinische Ereignisse wie Anfälle und Anfälle aufzeichnen können. Diese Informationen können eine Menge zusätzlicher Erkenntnisse liefern, in medizinische Aufzeichnungen integriert werden und mit medizinischer Expertise analysiert werden, die von KI/ML unterstützt wird. Solche Datenfeeds empfehlen die Verwendung von Event-Stream-Technologien wie Kafka, die diese Ereignisse schnell und effizient erfassen und die Daten in natürlicher Zeitreihe speichern können.

  Bei der Suche nach Mustern und Anomalien, die bei der Diagnose helfen können, im Allgemeinen, desto mehr Daten über einen Patienten, der erfasst und in (halb-)strukturierte Daten organisiert werden kann, die leicht abgefragt werden können, desto besser. So können die Beschaffung von Patientendaten, wie Familiengeschichte und Daten anderer medizinischer Organisationen, mit der Erlaubnis des Patienten, Erkenntnisse offenbaren, ohne dass es notwendig ist, spezifische einzelne Fakten aufdecken.

• Performance

  KI-Schulungen erfordern die Verarbeitung hochauflösender Bilder und müssen in regelmäßigen Abständen wiederholt werden (z.B. um neuere Bildformate oder qualitativ hochwertigere Bildgebung zu ermöglichen). Diese Modellaktualisierung muss so durchgeführt werden, dass sie sich nicht auf Patienten auswirkt, die sich einer Diagnose oder Behandlung unterziehen. Führen Sie dazu Modellupdates in einer isolierten Umgebung aus, und skalieren Sie die aktuelle Umgebung dann so, dass sowohl die Betriebsumgebung als auch die Schulungsumgebung ohne Probleme bei der Ressourcenwettbewerb oder Ressourcenzuteilung gleichzeitig vorhanden sein können.

• Sicherheit

  In einem klinischen Kontext ist die Sicherheit von größter Bedeutung, da solche Anforderungen stark reguliert werden. Nicht nur können die Daten als wertvoll angesehen werden, sondern auch die Möglichkeit, den Zugriff und die Nutzung der Daten durch versehentliche oder absichtliche Maßnahmen zu stören, ist von entscheidender Bedeutung. Die mit diesen Daten verbundenen Dienste müssen daher sicher sein.

• Verfügbarkeit

  Durch die Migration von Services in Cloud-Umgebungen werden verschiedene Probleme bezüglich Resilienz und Verfügbarkeit vom medizinischen Zentrum entfernt. Der Cloud-Provider kann die Verfügbarkeit des Netzwerks nicht garantieren. Daher müssen die Optionen für Netzwerkresilienz und Fallback aktiv im Besitz sein, um im Falle eines "letzten Meile"-Fehlers eine kontinuierliche Verfügbarkeit sicherzustellen. Außerdem empfiehlt es sich, dass eine Organisation mit kritischen Abhängigkeiten von solchen Fehlerszenarios den Cut-over und Cut-Back regelmäßig ausübt. Wenn es also wirklich nötig ist, wird der Prozess so ausgeführt, als ob es sich um einen anderen regulären Prozess handelte.

• Kostenfaktor

  Für jeden speziellen Anwendungsfall sind möglicherweise nicht alle ermittelten Lakehouse-Services erforderlich. Diese spiegeln die Kommentartechnologien wider, die mit der Anwendung eines Lakehouse verbunden sind. Beispiel: Wenn Oracle Big Data Cloud Service nicht benötigt wird, darf dieser nicht bereitgestellt werden. Der Objektspeicher kann intelligent verwendet werden, indem nicht benötigte Bilder in eine Speicherkonfiguration mit geringerer Performance platziert werden. Wenn ein Ereignis im Zusammenhang mit dem Patienten auftritt, wird der Inhalt in eine Speicherkonfiguration mit höherer Performance verschoben. Dies bedeutet in vielerlei Hinsicht, dass eine Datenbank wie die gleichen Prinzipien auf ihre speicherbeweglichen Daten im Cache und aus dem Cache, den schnellen Zugriffsspeicher (e.g, NVMe) und langsamere Spinning-Datenträger anwendet.