Von allen Anwendungsfällen, über die ich in meiner Arbeit bei awaBerry sprechen darf, ist das Gesundheitswesen derjenige, der mich jedes Mal innehalten lässt. Nicht, weil er technisch am komplexesten ist – obwohl er zweifellos anspruchsvoll ist –, sondern weil die Einsätze so greifbar sind. Wenn wir über sicheren Zugriff auf Patientendaten sprechen, sprechen wir nicht über Bequemlichkeit. Wir sprechen über Forschung, die Leben rettet.
Gestatten Sie mir, Sie durch ein Szenario zu führen, das nicht hypothetisch ist. Es ist die Art von Arbeitsablauf, die unsere Kunden in der pharmazeutischen Forschung heute bereits nutzen.
Der Forscher und die Herausforderung
Dr. Elena Vasquez ist leitende pharmazeutische Forscherin und arbeitet an einer multizentrischen Studie zu einer seltenen Autoimmunerkrankung. Daten relevanter Patienten für ihre Forschung existieren in fünf Krankenhäusern auf drei Kontinenten – alle speichern ihre Aufzeichnungen im OMOP Common Data Model, dem internationalen Standard für strukturierte klinische Beobachtungsdaten.
Der traditionelle Weg zum Zugriff auf diese Daten umfasst Monate der Datenfreigabevereinbarungen, VPN-Konfigurationen in jedem Krankenhaus, maßgeschneiderte Extraktionsskripte für jede einzelne Stelle und eine kleine Armee von IT-Mitarbeitern, die über Zeitzonen hinweg koordiniert werden. Bis die Daten an einem Ort sind, hat sich das Zeitfenster für die Forschung oft erheblich verengt.
Elenas Team nutzt stattdessen awaBerry.
Die awaBerry Agentic API im Gesundheitswesen
Jedes teilnehmende Krankenhaus hat seinen Forschungsservers mit Forschungsdaten bei awaBerry registriert. Die Geräte sind über reine ausgehende HTTPS-Tunnel verbunden – nichts im Krankenhausnetzwerk exponiert einen eingehenden Port zum Internet. Die awaBerry Agentic API ist mit einem projektspezifischen Project Key für Elena's Forschungskonsortium konfiguriert, mit präzise definierten Berechtigungen: Lesezugriff auf spezifische OMOP-strukturierte Verzeichnisse, keine Schreibberechtigungen, Standardbenutzerprivilegien und eine explizite Befehls-Allowlist, die jede Aktion außerhalb der genehmigten Datenextraktionsabfragen verhindert.
Wenn Elena bereit ist, einen Datenabruf durchzuführen, sieht der Arbeitsablauf wie folgt aus:
- Sie beschreibt ihre Abfrage in natürlicher Sprache – zum Beispiel: „Rufen Sie anonymisierte Datensätze von Patienten im Alter von 18–65 Jahren ab, bei denen in den letzten fünf Jahren die Erkrankung X diagnostiziert wurde, einschließlich Medikationshistorie und Laborwerten, von allen fünf Partnerstandorten.“
- Ihr KI-Agent übersetzt dies in strukturierte OMOP-Abfragen unter Verwendung des Datenmodellwissens ihrer Organisation.
- Der Agent authentifiziert sich bei der awaBerry Agentic API unter Verwendung des Project Key und Secret des Konsortiums.
- Ein projektbezogener, verschlüsselter Tunnel wird zu jedem der fünf Krankenhaus-Forschungsserver geöffnet – einer nach dem anderen oder parallel, wenn die Projektkonfiguration dies zulässt.
- Die genehmigten Abfragen werden lokal auf dem Server jedes Krankenhauses ausgeführt. Anonymisierte, aggregierte Ergebnisse werden über den verschlüsselten Tunnel zurückgegeben.
- Der Agent synthetisiert die Ergebnisse und liefert eine strukturierte analytische Ausgabe – bereit für das Forschungsteam von Elena zur Bearbeitung.
Der gesamte Prozess – von der Eingabe in natürlicher Sprache bis zu aggregierten, anonymisierten Erkenntnissen – dauert Sekunden bis Minuten, nicht Monate.
Warum Zero-Trust im Gesundheitswesen nicht verhandelbar ist
Es ist erwähnenswert, was Zero-Trust in diesem Kontext bedeutet, da das Gesundheitswesen spezifische Anforderungen hat, die allgemeine Remote-Access-Tools einfach nicht erfüllen können.
Jedes Zugriffsereignis über die awaBerry Agentic API generiert eine vollständige Audit-Trail: die aufrufende Identität, den Zeitstempel, das spezifische zugegriffene Gerät, die ausgegebenen Befehle und die zurückgegebenen Daten. Dieser Audit-Trail ist im awaBerry-Dashboard zur Inspektion verfügbar und kann direkt in ein SIEM eingespeist werden. Für das Informationssicherheitsteam eines Krankenhauses ist dies kein „Nice-to-have“ – es ist eine Compliance-Anforderung.
Das projektbezogene Berechtigungsmodell bedeutet, dass selbst wenn Elenas Project Key kompromittiert würde, der Angreifer nicht über die enge Bandbreite von schreibgeschützten OMOP-Abfragen in den genehmigten Verzeichnissen hinaus eskalieren könnte. Es gibt keine laterale Bewegung. Es gibt keinen Netzwerkzugriff auf den Rest der Infrastruktur des Krankenhauses. Der Schlüssel ist für alles außerhalb des Umfangs, für den er ausgestellt wurde, nutzlos.
Und wenn das Forschungsprojekt abgeschlossen ist, wird das Projekt im awaBerry-Dashboard gelöscht. Der Zugriff endet sofort. Keine VPN-Anmeldeinformationen, die widerrufen werden müssen. Keine Firewall-Regeln, die bereinigt werden müssen. Keine verbleibenden Artefakte.
OMOP und das Versprechen strukturierter klinischer Daten
Das OMOP Common Data Model ist eine der wichtigsten Entwicklungen in der klinischen Forschung des letzten Jahrzehnts. Durch die Standardisierung der Struktur von beobachtungsbezogenen Gesundheitsdaten über Institutionen hinweg ermöglicht es, dieselbe Frage an die Daten mehrerer Krankenhäuser zu stellen, ohne dass eine benutzerdefinierte Übersetzung an jedem Standort erforderlich ist. Die Agentic API von awaBerry ist eine natürliche Ergänzung zu OMOP-strukturierten Umgebungen: Sie bietet die sichere, auditierbare Zugriffsschicht, die es KI-Agenten ermöglicht, OMOP-fähige Forschungsnetzwerke zu durchqueren, ohne diese Netzwerke unnötigerweise zu exponieren.
Das ist es, was ich meine, wenn ich sage, dass awaBerry für das KI-Zeitalter entwickelt wurde. Es wurde nicht nachgerüstet, um agentische Arbeitsabläufe zu unterstützen. Es wurde von Grund auf als sichere Zugriffsschicht konzipiert, die autonome Systeme – seien es KI-Agenten oder Skript-Pipelines – benötigen, um verantwortungsvoll mit der physischen und klinischen Welt zu interagieren.
Die Daten, die Leben retten, verdienen das Zugriffsmodell, das sie schützt. Erkunden Sie die Agentic API →
