Aidbox Subscriptions: Ein umfassender Überblick über Datenintegration, Herausforderungen und Lösungen

Subscriptions bieten einen standardisierten Weg, um automatisierte, ereignisgesteuerte Datenflüsse einzurichten und so über wichtige Datenänderungen informiert zu bleiben. Diese Möglichkeit eröffnet neue Perspektiven für eine verbesserte Versorgungskoordination, eine erweiterte klinische Entscheidungsunterstützung und die Optimierung von Workflows im gesamten Gesundheitswesen.

Häufige Anwendungsfälle für Subscriptions:

• Datenreplikation: Automatisches Weitergeben von Datenänderungen an warteschlangen- oder nachrichtenbasierte Dienste.
• Datenaggregation: Sammeln und Zentralisieren von Daten aus mehreren FHIR-Serverquellen in einem zentralen Clinical Data Repository (CDR).
• Datenreplikation in Analysesysteme: Übertragen von Daten in externe Systeme für Analysen oder Berichte.
• Workflow-Automatisierung: Auslösen von Workflows auf Basis bestimmter Bedingungen.
• Systemerweiterung und -anpassung: Erweitern Sie die Funktionalität Ihres bestehenden Systems. Zum Beispiel kann eine Task-Ressource automatisch erstellt werden, wenn ein Appointment angelegt wird.
• Benutzerspezifische Benachrichtigungen: Ermöglichen Sie Endbenutzern, bestimmte Ereignisse zu abonnieren, etwa den Empfang einer E-Mail bei Stornierung eines Appointments.

Wesentliche Ziele bei der Implementierung von Subscriptions

Bei der Implementierung von Subscriptions müssen drei grundlegende Ziele berücksichtigt werden:

• Ereignisverarbeitung: Effizientes Erfassen von Änderungen auf Anwendungs- oder Datenbankebene.
• Race Conditions: Sicherstellen, dass Ereignisse korrekt verarbeitet werden, um Inkonsistenzen zu vermeiden.
• Zustellungsgarantien: Garantieren der Zustellung von Ereignissen zur Sicherstellung der Datenzuverlässigkeit.

Ereignisverarbeitung: Erfassung auf Anwendungs- und Datenbankebene

Erfassung auf Anwendungsebene

Dieser Ansatz umfasst die ausschließliche Erfassung von Ereignissen über die API auf der Anwendungsschicht. Obwohl er einfacher zu implementieren ist, werden Datenbankmigrationen oder die Massenaufnahme von Daten auf Datenbankebene nicht erfasst. Dies kann zu verpassten Ereignissen führen, wenn umfangreiche Datenaktualisierungen außerhalb der API der Anwendung stattfinden.

Erfassung auf Datenbankebene

Dieser Ansatz erfasst alle möglichen Änderungen direkt aus der Datenbank und bietet damit eine vollständigere Lösung. Er ist jedoch komplexer und aufwendiger in der Implementierung und Wartung. Darüber hinaus kann eine granulare Ereignisfilterung anspruchsvoll sein und eine Nachverarbeitung erfordern, um unnötige Ereignisse herauszufiltern.

Race Conditions

Die Aufrechterhaltung der korrekten Reihenfolge von Ereignissen ist entscheidend, insbesondere in Szenarien, in denen gleichzeitige Aktualisierungen auftreten können. Betrachten Sie eine Situation, in der zwei gleichzeitige Anfragen dasselbe Appointment aktualisieren:

• Request_A setzt Appointment.status: 'canceled'

• Request_B setzt Appointment.status: 'pending'

Wenn Ereignisse auf Anwendungsebene in separaten Threads oder über verschiedene Anwendungsinstanzen verarbeitet werden, können sie in der falschen Reihenfolge verarbeitet werden. Die Ereignisreihenfolge könnte beispielsweise so aussehen: status = pending, status = canceled.

Die tatsächliche Commit-Reihenfolge in der Datenbank könnte jedoch status = canceled, status = pending sein.

Als Ergebnis zeigt der endgültige Datenbankzustand pending, aber das letzte vom Subscriber verarbeitete Ereignis zeigt canceled.

Zur Lösung dieses Problems gibt es folgende Optionen:

Einzelthread-, Einzelinstanz-Ausführung

Dies kann für Anwendungen mit minimalen Workloads praktikabel sein, stellt jedoch keine skalierbare Lösung dar. Hochleistungssysteme erfordern in der Regel Multi-Threading und Multi-Replica-Setups für Leistung und Hochverfügbarkeit.

Optimistisches Sperren

Verwenden Sie optimistisches Sperren mit dem FHIR-Header If-None-Match: W/"[ETag]" zur Verwaltung von Aktualisierungen. Dies ist jedoch häufig unpraktisch und nicht zielführend, insbesondere wenn die ursprüngliche Anfrage nicht geändert werden kann.

Serialisierung auf Datenbankebene

Verwenden Sie Mechanismen auf Datenbankebene, um die Ereignisserialisierung sicherzustellen. In PostgreSQL kann beispielsweise ein Replikations-Slot garantieren, dass alle Ereignisse sequenziell in der Commit-Reihenfolge verarbeitet werden. Dieser Ansatz hat jedoch erhebliche Nachteile, darunter Leistungsengpässe bei sehr hohen Workloads, da der Replikations-Slot nur von einem Thread gelesen werden kann. Zudem kann die Wartung dieses Setups komplex sein.

Zustellungsgarantien

Bei der Implementierung von Subscriptions sind drei Ebenen von Zustellungsgarantien zu berücksichtigen:

At Most Once

Ereignisse werden ohne Empfangsbestätigung gesendet. Dieser Ansatz eignet sich für Szenarien, in denen Ereignisse mit hoher Rate erzeugt werden und die Ressourcennutzung minimiert werden soll.

At Least Once

Dieser Ansatz garantiert, dass jedes Ereignis mindestens einmal zugestellt wird, auch im Fehlerfall, wobei Duplikate auftreten können. Er eignet sich für kritische Vorgänge, wie Datenänderungen auf Systemebene, bei denen Zuverlässigkeit unerlässlich ist, Duplikate jedoch auf der Empfängerseite verwaltet werden müssen.

Exactly Once

In diesem Modell garantiert das System, dass jedes Ereignis genau einmal zugestellt wird, und gewährleistet damit sowohl Zuverlässigkeit als auch das Vermeiden von Duplikaten. Diese Garantiestufe erfordert Unterstützung sowohl auf der sendenden als auch auf der empfangenden Seite und kann ressourcenintensiver in der Implementierung sein.

Aidbox-Funktionalitäten

Die Aidbox FHIR Platform bietet mehrere Implementierungen von Subscriptions:

Aidbox Subscriptions — Optimal für einfache, nicht kritische Interaktionen zwischen Diensten.

• Einfach zu verwenden mit minimalem Einrichtungsaufwand.

• Keine strengen Zustellungsgarantien sind geeignet, wenn Nachrichtenverlust akzeptabel ist.

• Ideal für leichtgewichtige Systeme, bei denen Einfachheit Priorität hat.

FHIR topic-based subscriptions — Optimal für Systeme mit hohen Anforderungen an Konsistenz und Zustellung, die jedoch nicht unter sehr hohen Workloads betrieben werden.

• FHIR-konform.

• Keine Race Conditions bei Zustellungsgarantien.

Aidbox topic-based subscriptions — Optimal für hochlastige Systeme, die Skalierbarkeit und Zustellungsgarantien erfordern.

• Integration mit Kafka für nachrichtendurchsatzstarkes Messaging.

• Aufrechterhaltung hoher Leistung unter starker Last.

• Unverzichtbar für Anwendungen, bei denen Datenverlust nicht akzeptabel ist.

Beispiele

• Aidbox topic-based subscriptions Demo — https://github.com/Aidbox/examples
• FHIR topic-based subscriptions — https://github.com/Aidbox/aidbox-project-template/tree/topic-based-subscription-r4b-fhir-schema-mode

Die Zukunft der Aidbox Subscriptions

Aidbox Topic-based Subscriptions entwickeln sich zur bevorzugten Lösung für Echtzeit-Benachrichtigungen und -Aktualisierungen in Gesundheitsanwendungen und bieten eine ideale Kombination aus Einfachheit, Skalierbarkeit und Zuverlässigkeit.

Wir sind bestrebt, Aidbox Topic-Based Subscriptions kontinuierlich zu verbessern, indem wir AidboxTopicDestination um die Unterstützung weiterer Kanäle wie Webhooks, RabbitMQ, Amazon SNS und mehr erweitern. Wir arbeiten außerdem an einer Event- (oder Message-)API, ähnlich wie Amazon SNS, um noch mehr Flexibilität für Ihre Integrationsanforderungen zu bieten.

Kontaktieren Sie uns mit Ihren Anwendungsfällen und Anforderungen oder starten Sie kostenlos mit Aidbox topic-based subscriptions über unsere Entwicklungslizenzen.

Autor: Marat Surmashev, VP of Engineering bei Health Samurai

Siehe auch: Verwaltung von Multi-Klinik-Daten mit OrgBAC.