🔥 Wie man eine mandantenfähige FHIR-API für ein bestehendes EHR-System entwirft

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 haben nach wie vor Fragen dazu, wie sie den Aufwand durch die Vielzahl an FHIR-Servern reduzieren können. Die Antwort ist einfach: Mandantenfähigkeit (Multitenancy) ist immer die richtige Lösung. In diesem Artikel finden Sie Antworten auf die folgenden Fragen:

Was ist Mandantenfähigkeit? Welche Vorteile bietet sie?
Wie erstellt man eine mandantenfähige FHIR-API?
Wie bindet man eine FHIR-API in eine bestehende EHR-Lösung ein?

Was ist Mandantenfähigkeit?

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

Die Mandanten sind voneinander isoliert, das heißt, 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 Mandantenfähigkeit zu einer attraktiven Option für Unternehmen, die Ressourcen über mehrere Benutzer hinweg teilen müssen, dabei jedoch individuelle Datenschutz- und Sicherheitsanforderungen wahren wollen.

Bei der Diskussion über Mandantenfähigkeit sollte jedoch auch die physische Isolation berücksichtigt werden. Der Grad der physischen Isolation ist flexibel und kann von einer vollständigen physischen Trennung bis hin zu einem gemeinsam genutzten Hosting-Bereich reichen, in dem jeder Mandant seinen eigenen einzigartigen 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 Mandantenfähigkeit?

Schauen wir uns nun die Vorteile der Mandantenfähigkeit für EHR-Anbieter und andere Plattformdienste an:

Betriebskosten senken: Ebenso wie eine gemeinsame Fahrt günstiger ist, ist die gemeinsame Nutzung von Cloud-Ressourcen kostengünstiger. Sie erhalten also viele FHIR-Server zum Preis von einem.
Einfach skalieren: Kunden haben die Möglichkeit, Ressourcen hinzuzufügen oder zu entfernen. Diese Anpassungsfähigkeit ist ideal für Unternehmen mit schnellem, aber unvorhersehbarem Wachstum.
Daten sicher halten: Während einzelne Mandanten sicherer sind, ist Mandantenfähigkeit dennoch besser darin, Bedrohungen zu erkennen und Mandantenressourcen zu isolieren.

Allerdings ist keine Lösung perfekt. Für den Betreiber ist Mandantenfähigkeit komplexer als eine Einzelmandantenlösung. Wir bleiben nicht bei der Theorie – lesen Sie weiter!

Starten Sie mit dem Aidbox FHIR Server für Datenspeicherung, Integrationen, Gesundheitsanalytik und mehr, oder beauftragen Sie unser Team, um Ihre Softwareentwicklungsanforderungen zu unterstützen.

Was ist mit FHIR?

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

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

Implementierung von Mandantenfähigkeit

Hier werden wir einige Techniken vorstellen, die Ihnen beim Aufbau einer stark gemeinsam genutzten Lösung helfen können. Diese gehen noch einen Schritt weiter und ermöglichen es Ihnen, bei Bedarf zu einer niedrigeren Ebene der Mandantenfähigkeit zu migrieren, falls einige Kunden mehr dedizierte Ressourcen benötigen. Um dies zu implementieren, müssen wir einige wichtige Schritte betrachten:

Mandanten explizit machen;
Daten mit einer Mandanten-ID versehen, sodass sie einem bestimmten Mandanten gehören;
Die FHIR_BASE_URL um die Mandanten-ID erweitern;
Die AUTH_SERVER_BASE_URL um die Mandanten-ID erweitern.

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

Mandanten explizit machen

Das explizite Definieren von Mandanten ist aus zwei wesentlichen Gründen entscheidend:

Sie werden unweigerlich wissen wollen, welche Mandanten in Ihrem System vorhanden sind;
Irgendwann werden Sie individuelle Anpassungen für diese vornehmen wollen.

Explizite Mandantenressourcen sind ein guter Ort, um sie zu verfolgen und spezifische benutzerdefinierte Konfigurationen einzutragen. 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 Grund, warum wir überhaupt auf Mandantenfähigkeit setzen. Ich empfehle, den Mandanten als explizite Eigenschaft jeder Ressource zu definieren. Das eröffnet einen großen Bereich, in dem Sie Daten speichern können, und ermöglicht es Ihnen auch, Migrationen durchzuführen und Ihre Infrastruktur weiterzuentwickeln, um wachsenden Leistungsanforderungen gerecht zu werden.

Mandantenzugehörigkeit ist eine Meta-Eigenschaft. Nehmen wir Aidbox als Beispiel und betrachten wir, wie wir sie unter dem meta-Feld in 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 betrifft, können wir mit einem einfachen Ansatz aus Infrastruktursicht beginnen. Wir können Daten in einer Datenbank und einer Tabelle pro Ressourcentyp speichern.

Die einzige wesentliche Einschränkung, die ich sehe, ist, dass Sie die Filterung nach Mandant auf Anwendungsebene implementieren müssen, was ein durchaus vertretbarer Aufwand ist, 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. Dafür gibt es zwei Möglichkeiten:

Sie können die Mandanten-ID in den Domainnamen einfügen, 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 erscheint.

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

Die Mandanten-ID im URL-Pfad zu haben ist ebenfalls in Ordnung. Es erfordert nicht, auf so viele Domainnamen zu verzichten, selbst wenn Sie keinen Zugriff auf diese 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.

Authentifizierung sollte dem Mandanten gehören

Nun haben wir eine dedizierte FHIR-API für jeden Kunden, und die Daten im Speicher gehören ebenfalls den Mandanten. Der letzte Schliff ist die Dedizierung des Auth-Servers. Warum das? Vielleicht fragen Sie sich, ob es möglich ist, einen einzigen Auth-Server zu haben. Ich bin der Meinung, dass dies nicht möglich ist, und hier ist der Grund.

Angenommen, ein Benutzer hat ein Konto in zwei verschiedenen Mandanten. Was ergibt sich 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 UX (Benutzererfahrung), die Sie anstreben? Ich glaube nicht. Dafür gibt es zwei Gründe:

Ihre Benutzer müssten bei jeder Interaktion mit einem Ihrer Mandanten ihr Konto auswählen, selbst wenn sie nur ein Konto haben (Sie können nie sicher sein, ob sie weitere Konten haben, und müssen jedes Mal nachfragen, wenn sie mit Ihrer FHIR-API interagieren möchten);
In dem Wissen, dass Sie verschiedene Mandanten haben, könnten Ihre Benutzer theoretisch mit externen Datenlecks interagieren. Unser Ziel ist eine vollständige Isolation aus Benutzersicht.

Dies hört jedoch nicht hier auf, denn auch der Auth-Server muss mandantenfähig sein. Dies kann erreicht werden, indem dieselbe Methode angewendet wird, 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. Entscheidend ist nur, dass Mandanten gleichzeitig bei all Ihren Auth-Servern angemeldet sein und mit Ihren FHIR-Servern als unabhängige Einheiten interagieren können.

Fazit

Es gibt vier einfache Schritte zur Erreichung von Mandantenfähigkeit:

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.

Wenn Sie diese vier einfachen Schritte anwenden, können Sie einen FHIR-Server ohne zusätzliche Infrastrukturkosten betreiben, da Sie lediglich eine Mandantenressource und einen virtuellen FHIR-Server erstellen müssen – der Auth-Server wird bereits für diesen bereitgestellt sein.

Wenn einige Ihrer Mandanten ihre Zuteilung überschreiten, können Sie problemlos eine höhere Isolationsstufe dedizieren. Sie müssen lediglich:

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

Aktualisierung: Erweitertes organisationsbasiertes hierarchisches Zugriffsmanagement

Wir haben das System kürzlich durch die Hinzufügung eines organisationsbasierten hierarchischen Zugriffsmanagements erweitert. Diese neue Funktion ermöglicht ein flexibleres und präziseres Datenzugriffsmanagement 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 autorisiert 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 nutzen. Sie bietet eine robuste Umgebung zum Testen und Entwickeln dieser Funktionen und stellt alle erforderlichen Werkzeuge ohne Funktionseinschränkungen bereit.

Autor: Vlad Ganshin, Software Engineer bei Health Samurai

Wenn Sie nach einer mandantenfähigen FHIR-API suchen, die Sie fit für 2024 und darüber hinaus macht, testen Sie noch heute das ONC-zertifizierte Aidbox FHIR-API-Modul.

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