Warum eine FHIR-API-Fassade verwenden?
Es gibt viele Gründe, warum Ihre Softwarelösung mit anderen Systemen kommunizieren sollte. Zwischen der Interaktion mit anderen Anwendungen und der Erweiterung Ihrer Lösung um neue Module muss Ihre Lösung Daten austauschen und Operationen auf externe Anfragen hin ausführen. Eine verbreitete Methode dafür ist das Bereitstellen einer API (Application Programming Interface). Wenn Ihre Anwendung zudem reibungslos mit allen anderen Systemen kommunizieren soll, ohne teure Vermittler einschalten zu müssen, sollten Sie auf die Standard-API setzen – die FHIR-API. Erfahrene Entwickler neuer Healthcare-Technologien denken von Anfang an über die API nach. Viele von ihnen setzen auf einen FHIR-first-Entwicklungsprozess, bei dem das Backend einer neuen Lösung auf einem FHIR-Server aufgebaut wird. Dieser verwendet intern das FHIR-Datenmodell und unterstützt von Haus aus eine vollständige FHIR-API. Was aber, wenn Sie Ihre Lösung vor einiger Zeit entwickelt haben und diese keine API-Schicht besitzt? Sie müssen Ihre Anwendung in die Lage versetzen, mit anderen Systemen zu kommunizieren – und genau dafür nutzen Sie eine API-Fassade: eine Schnittstelle, die Ihrer Lösung hinzugefügt wird und anderen Anwendungen Zugriff auf die Operationen und Daten Ihrer Lösung ermöglicht.
So erstellen Sie eine FHIR-Fassade
Speicherlose FHIR-Fassade
Ein Ansatz zur Implementierung einer FHIR-Fassade besteht darin, FHIR-REST-Aufrufe in Abfragen an die zugrunde liegende Datenbank oder die Dienste des Originalsystems zu übersetzen. Dabei müssen Sie Ihr internes Informationsmodell auf FHIR abbilden – das heißt, Sie ermitteln, welche FHIR-Ressourcen und -Attribute die Datenstrukturen in Ihrem System repräsentieren. Eine solche Fassade leitet alle Aufrufe an die ursprüngliche Datenbank weiter.
Die Implementierung ist für eine reine Lese-API unkompliziert, kann jedoch komplex werden, wenn Sie Ihren Benutzern auch das Zurückschreiben von Daten in das Originalsystem ermöglichen möchten. Einfache Anwendungsfälle lassen sich mit Mapping-Tools lösen, während komplexere Implementierungen umfangreiche individuelle Entwicklungsarbeit erfordern.
FHIR-Fassade mit einem zwischengeschalteten FHIR-Server
Der andere Ansatz besteht darin, einen generischen FHIR-Server zum Speichern der Daten zu verwenden, die Sie über die API bereitstellen möchten. Sie nehmen dasselbe Mapping Ihres internen Informationsmodells auf FHIR vor, synchronisieren dann jedoch die Daten in Ihrer Datenbank mit den Daten im FHIR-Server, der die weitere Verarbeitung übernimmt.
Der FHIR-Server verarbeitet alle API-Befehle, ohne diese an die zugrunde liegende Datenbank des Originalsystems weiterzuleiten. Alle Änderungen in der ursprünglichen Datenbank werden zeitnah an den FHIR-Server übermittelt, sodass das Originalsystem und der FHIR-Server synchron bleiben.
Vor- und Nachteile
Beide Ansätze sind für unterschiedliche Anwendungsfälle geeignet und haben jeweils ihre eigenen Vor- und Nachteile. Die speicherlose FHIR-Fassade eignet sich gut für einfache Anwendungsfälle, bei denen Sie einige wenige individuelle API-Endpunkte implementieren müssen. Es gibt keine Datenduplizierung, und der Ressourcenverbrauch ist minimal.
Wenn Ihre FHIR-Fassade jedoch Unternehmensanwendungen hosten und populationsweite Anwendungsfälle unterstützen soll, kann das „Caching" von Daten in einem zwischengeschalteten FHIR-Server vorteilhaft und mitunter sogar notwendig sein. Wenn ein FHIR-Server alle API-Aufrufe verarbeitet, behalten Sie die Kontrolle über die Leistung jedes einzelnen Aufrufs. Selbst wenn ein FHIR-Server Daten aus mehreren Systemen virtualisiert, lässt sich eine hervorragende Leistung im großen Maßstab erzielen. Dieselben API-Aufrufe mit einer speicherlosen API-Fassade können hingegen sehr langsam sein.
Starten Sie mit dem Aidbox FHIR-Server für Datenspeicherung, Integrationen, Healthcare-Analysen und mehr, oder beauftragen Sie unser Team zur Unterstützung Ihrer Softwareentwicklung.
Es ist wichtig, die Komplexität der FHIR-Suche zu erwähnen. Mit dem zwischengeschalteten FHIR-Server ist sie deutlich schneller, da Sie die Suche durch Indizes unterstützen können – was beim speicherlosen Ansatz nicht möglich ist.
Selbst wenn Ihr FHIR-Server viele Anfragen von externen Anwendungen erhält, wird das zugrunde liegende System dadurch nicht belastet. Die Daten werden nur einmal aus dem Originalsystem abgerufen; der FHIR-Server bedient alle API-Aufrufe. Bei einer speicherlosen Fassade hingegen gehen alle Anfragen an die zugrunde liegende Datenbank des Originalsystems, was die Leistung des Originalsystems und seiner Benutzer beeinträchtigen kann.
Der Einsatz eines vollwertigen FHIR-Servers bietet Ihnen gegenüber der speicherlosen FHIR-Fassade einen weiteren Vorteil. Er ermöglicht es Ihnen, ein ganz neues Ökosystem moderner FHIR-first-Anwendungen darauf aufzubauen, sodass Sie eines Tages von Ihrem veralteten proprietären Backend zu einer neuen, FHIR-basierten Zukunft übergehen können. Auch wenn dies mehr Computerressourcen erfordert, werden diese Ressourcen nicht verschwendet – sie eröffnen Ihnen ein nächstes Niveau an Flexibilität.
Fazit
Welchen Weg Sie bei Ihrer API-Implementierung einschlagen, liegt bei Ihnen. Health Samurai unterstützt beide Ansätze mit seinen Lösungen und Dienstleistungen. Schreiben Sie uns oder rufen Sie uns an.
Siehe auch: Warum Sie einen unabhängigen FHIR-Server benötigen.
