Der FHIR-Trend wird auch 2024 weiter dominieren. Die Regelungen der ONC stellen Anbieter vor erhebliche Herausforderungen, da sie für jeden Kunden eine HL7® FHIR-API mit SMART on FHIR-Unterstützung bereitstellen müssen.

Viele EHR-Anbieter stehen noch vor der Frage, wie sie den Aufwand für so viele FHIR-Server reduzieren können. Die Antwort ist einfach: Mandantenfähigkeit (Multitenancy) ist stets die richtige Lösung. In diesem Artikel finden Sie Antworten auf folgende Fragen:

• Was ist Multitenancy? Welche Vorteile bietet sie?
• Wie baut man eine mandantenfähige FHIR-API?
• Wie integriert man eine FHIR-API in eine bestehende EHR-Lösung?

Was ist Multitenancy?

Multitenancy ist ein zentraler Vorteil von SaaS-ERP-Systemen. Kurz gesagt handelt es sich dabei um eine Methode, gemeinsam genutzte Ressourcen mehreren Kunden (Mandanten) bereitzustellen, wobei jeder Kunde seine eigene dedizierte Umgebung erhält.

Die Mandanten sind voneinander isoliert, d. h. die Daten eines Mandanten sind für einen anderen in keiner Weise sichtbar. Benutzer können auf ihre eigenen Daten zugreifen, ohne die Privatsphäre oder die Daten anderer Mandanten zu beeinträchtigen.

Dies macht Multitenancy zu einer attraktiven Option für Unternehmen, die Ressourcen über mehrere Benutzer hinweg teilen müssen, dabei aber individuelle Datensicherheit und Privatsphäre wahren wollen.

Bei der Diskussion über Multitenancy sollte jedoch auch die physische Isolation berücksichtigt werden. Der Grad der physischen Isolation ist flexibel und kann von vollständiger physischer Trennung bis hin zu einer gemeinsam genutzten Hosting-Umgebung reichen, in der jeder Mandant seinen eigenen eindeutigen Plattformbereich hat.

Der Grad der physischen Isolation zwischen verschiedenen Mandanten wird durch die zugrunde liegende Technologie bestimmt, muss jedoch im Allgemeinen eine vollständige logische Isolation gewährleisten, um sicherzustellen, dass die Daten jedes Mandanten sicher bleiben (Gartner).

Welche Vorteile bietet Multitenancy?

Betrachten wir nun die Vorteile von Multitenancy für EHR-Anbieter und andere Plattformdienste:

• Betriebskosten senken: So wie es günstiger ist, eine Fahrt mit anderen zu teilen, ist es günstiger, Cloud-Ressourcen zu teilen. So erhalten Sie viele FHIR-Server zum Preis eines einzigen.
• Einfache Skalierung: Kunden haben die Möglichkeit, Ressourcen hinzuzufügen oder zu entfernen. Diese Anpassungsfähigkeit ist ideal für Unternehmen mit schnellem, aber unvorhersehbarem Wachstum.
• Datensicherheit gewährleisten: Während einzelne Mandanten sicherer sind, ist Multitenancy dennoch besser darin, Bedrohungen zu identifizieren und Mandantenressourcen zu isolieren.

Das gesagt: Keine Lösung ist perfekt. Aus Sicht des Betreibers ist Multitenancy komplexer als eine Einzelmandantenlösung. Wir bleiben nicht bei der Theorie, also lesen Sie weiter!

Starten Sie mit dem Aidbox FHIR-Server für Datenspeicherung, Integrationen, Gesundheitsanalytik und mehr, oder beauftragen Sie unser Team zur Unterstützung Ihrer Softwareentwicklungsanforderungen.

Was ist mit FHIR?

FHIR unterstützt Multitenancy nicht auf Spezifikationsebene. Tatsächlich ist das auch nicht notwendig. Viele FHIR-Server wie Aidbox vereinen jedoch das Beste aus zwei Welten: FHIR und mandantenfähige Architektur. Erfahren Sie mehr über Multitenancy in der Aidbox-Dokumentation.

Multitenancy ist eine Frage interner Architekturentscheidungen. FHIR stellt die FHIR_BASE_URL bereit, um die Funktionalität für andere zugänglich zu machen. Jeder Ihrer Kunden sollte seine eigene FHIR_BASE_URL erhalten. Wir werden dies später ausführlicher erläutern.

Implementierung von Multitenancy

Hier werden einige Techniken vorgestellt, die Ihnen helfen können, eine stark gemeinsam genutzte Lösung zu erstellen. Sie ermöglicht es außerdem, bei Bedarf zu einem niedrigeren Isolationsgrad zu migrieren, falls einige Kunden mehr dedizierte Ressourcen benötigen. Um dies umzusetzen, müssen wir einige wichtige Schritte betrachten:

• Mandanten explizit definieren;
• Daten mit einer Mandanten-ID kennzeichnen, sodass sie einem bestimmten Mandanten gehören;
• FHIR_BASE_URL mit der Mandanten-ID erweitern;
• AUTH_SERVER_BASE_URL mit der Mandanten-ID erweitern.

Am Ende des Prozesses wird Ihr Kunde vollständiges Vertrauen in seine vollständige Isolation auf Daten- und API-Ebene haben, was auch gerechtfertigt sein wird.

Mandanten explizit definieren

Die explizite Definition von Mandanten ist aus zwei wesentlichen Gründen entscheidend:

• Sie werden unweigerlich wissen wollen, welche Mandanten sich in Ihrem System befinden;
• Letztendlich werden Sie für sie individuelle Anpassungen vornehmen wollen.

Explizite Mandantenressourcen sind ein guter Ort, um sie zu verfolgen und spezifische benutzerdefinierte Konfigurationen zu hinterlegen. Sie können die Einführung zusätzlicher Ressourcen in Betracht ziehen:

id: my-clinic resource Type: Tenant name: My Clinic

Die Daten gehören dem Mandanten

Das ist der eigentliche Grund, warum wir Multitenancy einsetzen. Ich empfehle, den Mandanten als explizite Eigenschaft jeder Ressource zu definieren. Dies eröffnet einen großen Bereich, in dem Sie Daten speichern können, und ermöglicht es Ihnen außerdem, Migrationen durchzuführen und Ihre Infrastruktur weiterzuentwickeln, um wachsenden Leistungsanforderungen gerecht zu werden.

Mandantenzugehörigkeit ist eine Meta-Eigenschaft. Nehmen wir daher Aidbox als Beispiel und betrachten, wie wir sie im Meta-Feld von FHIR-Ressourcen speichern.

Aidbox format

meta: tenant: id: my-clinic resourceType: Tenant

FHIR format

meta: extension:

• url: https://aidbox.app/tenant-id valueReference reference: Tenant/my-clinic

Dies ist eine externe Darstellung. Was die interne Darstellung betrifft, können wir mit einem einfachen Ansatz aus infrastruktureller Sicht beginnen. Wir können Daten in einer Datenbank und einer Tabelle pro Ressourcentyp speichern.

Die einzige wesentliche Einschränkung, die ich sehe, besteht darin, dass Sie die Filterung nach Mandant auf Anwendungsebene implementieren müssen – ein durchaus vertretbarer Aufwand, um Ihre Infrastruktur so einfach wie möglich zu halten.

Falls ein Mandant mehr Ressourcen benötigt, eine hohe Last erzeugt und andere Mandanten beeinträchtigt, können Sie dessen Daten jederzeit in eine andere Datenbank migrieren und eine dedizierte Instanz derselben Anwendung für diesen Mandanten betreiben.

Die FHIR-Basis-URL sollte die Mandanten-ID enthalten

Wenn alle Ihre Kunden eine dedizierte FHIR-API haben, müssen Sie ihnen eine unterschiedliche FHIR_BASE_URL bereitstellen, unter der ihr virtueller FHIR-Server betrieben wird. Hierfür gibt es zwei Möglichkeiten:

• Sie können die Mandanten-ID im Domainnamen platzieren, z. B. my-clinic.aidbox.app/fhir-api;
• Die Mandanten-ID kann im URL-Pfad erscheinen, z. B. aidbox.app/tenant/my-clinic/fhir-api.

Beide Optionen sind in Ordnung, wobei die erste präziser und übersichtlicher wirkt.

Wenn Sie vollen Zugriff auf Ihre Domain haben und Subdomains für Ihre Mandanten reservieren können, sollten Sie erwägen, die Mandanten-ID in den Domainnamen aufzunehmen. Ihre Anwendung sollte außerdem in der Lage sein, mit verschiedenen Domains in derselben Instanz zu arbeiten, was in der Regel der Fall ist.

Die Mandanten-ID im URL-Pfad zu platzieren ist ebenfalls in Ordnung. Es erfordert nicht, auf so viele Domainnamen zu verzichten, selbst wenn Sie keinen Zugriff darauf haben. Die FHIR-API implementiert den REST-Stil, und die REST-API erwartet keine Sitzungen zwischen Anfragen, was bedeutet, dass keine Browser-Cookies benötigt werden.

Auth sollte dem Mandanten gehören

Jetzt haben wir eine dedizierte FHIR-API für jeden Kunden, und die Daten im Speicher gehören ebenfalls den Mandanten. Der letzte Schliff besteht darin, den Auth-Server zu dedizieren. Warum ist das so? Vielleicht fragen Sie sich, ob es möglich ist, einen einzigen Auth-Server zu haben. Ich glaube, das ist nicht möglich, und hier ist der Grund.

Angenommen, ein Benutzer hat ein Konto in zwei verschiedenen Mandanten. Was haben wir dann? Kann dieser Benutzer gleichzeitig bei beiden Mandanten angemeldet sein? Technisch gesehen ja. Google ist ein gutes Beispiel. Sie können Google-Dienste nutzen und mit wenigen Klicks zwischen Konten wechseln. Aber ist das die Benutzererfahrung (UX), die Sie anstreben? Ich glaube nicht. Dafür gibt es zwei Gründe:

• Ihre Benutzer müssen jedes Mal ihr Konto auswählen, wenn sie mit einem Ihrer Mandanten arbeiten, selbst wenn sie nur ein einziges Konto haben (Sie können nicht sicher sein, ob sie weitere Konten haben, und müssen jedes Mal nachfragen, wenn sie mit Ihrer FHIR-API interagieren möchten);
• Da Ihre Benutzer wissen, dass Sie verschiedene Mandanten haben, könnten sie theoretisch mit externen Datenlecks interagieren. Unser Ziel ist die vollständige Isolation auf Benutzerseite.

Aber damit ist es nicht getan, denn auch der Auth-Server muss mandantenfähig sein. Dies lässt sich erreichen, indem man dieselbe Methode anwendet, mit der wir FHIR-APIs für Mandanten getrennt haben: eine dedizierte AUTH_BASE_URL. Es spielt keine Rolle, ob die Mandanten-ID im Domainnamen oder im URL-Pfad erscheint. Das Einzige, was zählt, ist, dass Mandanten gleichzeitig bei allen Ihren Auth-Servern angemeldet sein und mit Ihren FHIR-Servern als unabhängige Einheiten interagieren können.

Fazit

Es gibt vier einfache Schritte zur Umsetzung von Multitenancy:

• Machen Sie Ihren Mandanten explizit und erstklassig;
• Speichern Sie einen Verweis auf den Mandanten in jeder Ressource;
• Fügen Sie die Mandanten-ID in eine FHIR-Basis-URL ein;
• Machen Sie auch Ihren Auth-Server mandantenfähig.

Sobald Sie diese vier einfachen Schritte angewendet haben, können Sie einen FHIR-Server ohne zusätzliche Infrastrukturkosten bereitstellen, da Sie lediglich eine Mandantenressource und einen virtuellen FHIR-Server erstellen müssen – der Auth-Server ist dann bereits für diesen bereitgestellt.

Falls einige Ihrer Mandanten ihre Zuteilung überschreiten, können Sie problemlos ein höheres Isolationsniveau dedizieren. Dazu müssen Sie lediglich:

• dieselbe Anwendung auf einem anderen Server bereitstellen;
• die Daten des Mandanten migrieren;
• Anfragen an die neue Anwendung umleiten.

Aktualisierung: Erweitertes organisationsbasiertes hierarchisches Zugriffssteuerungssystem

Wir haben das System kürzlich durch die Hinzufügung einer organisationsbasierten hierarchischen Zugriffssteuerung erweitert. Diese neue Funktion ermöglicht eine flexiblere und präzisere Datenzugriffsverwaltung auf Basis der Organisationshierarchie. Administratoren können nun Zugriffsberechtigungen auf verschiedenen Organisationsebenen festlegen und so sicherstellen, dass Benutzer nur die Daten sehen, für die sie berechtigt sind. Diese Verbesserung erhöht die Sicherheit und Verwaltbarkeit des Systems erheblich, insbesondere in großen Organisationen mit komplexen Strukturen. Detaillierte Informationen zur neuen Funktionalität finden Sie in der Aidbox-Dokumentation.

Um die Implementierung einer mandantenfähigen FHIR-API in Ihrem EHR-System zu erkunden, sollten Sie die kostenlose Version von Aidbox in Betracht ziehen. Sie bietet eine robuste Umgebung zum Testen und Entwickeln dieser Funktionen und stellt alle notwendigen Werkzeuge ohne Funktionseinschränkungen bereit.

Autor: Vlad Ganshin, Software Engineer bei Health Samurai

Wenn Sie eine mandantenfähige FHIR-API suchen, die Sie durch 2024 und darüber hinaus begleitet, testen Sie noch heute das von der ONC zertifizierte Aidbox FHIR-API-Modul.

Siehe auch: Warum Sie einen unabhängigen FHIR-Server benötigen.