FHIR ist sowohl ein Informationsnetzwerk, das Daten zwischen Systemen verknüpft, als auch ein Kommunikationsnetzwerk, das den Austausch von Daten zwischen Systemen ermöglicht.

FHIR steht für Fast Healthcare Interoperability Resources.

FHIR ist ein offener Standard (open Source) und somit für jeden zugänglich. Es ist leicht zu verwenden, da es kompatibel ist mit gängigen web Technologien, wie zum Beispiel XML, HTTPS und JSON. Auf Grund der großen Community, gibt es bereits viele bestehende Gesundheitsszenarien, die abgebildet werden und deren Anzahl stetig steigt. FHIR bietet eine Doppel Funktion für Ressourcen, welche Daten sowohl in menschenlesbarer, als auch in maschinenlesbare Form übermittelt und abbildet. So können elektronischen Daten sowohl in zwischenmenschlichen Szenarien als auch in automatische Computerverarbeitung verwendet werden.

Der FHIR-Standard stellt ein Format für eine Datenstruktur dar, welche es ermöglicht die Daten zwischen verschiedenen eHealth Anbietern und Endnutzern ohne Datenverlust auszutauschen. Dank fest definierten „Regeln“ in Form von FHIR-Ressourcen, weiß Partei A welche Daten Partei B braucht und in welcher Form diese zur Verfügung gestellt werden sollen.

Profile sind spezielle Konfigurationen des FHIR-Standards, die zur Anpassung und Erweiterung von FHIR-Ressourcen für bestimmte Anwendungsfälle oder Bedürfnisse verwendet werden. Ein FHIR-Profil definiert eine spezifische Nutzung oder Einschränkung von FHIR-Ressourcen, um sicherzustellen, dass die Daten, die zwischen verschiedenen Systemen ausgetauscht werden, einheitlich und interoperabel sind. Profile sind zentral für die Anpassung von FHIR an nationale, regionale oder institutionelle Anforderungen und werden oft verwendet, um sicherzustellen, dass unterschiedliche Systeme Daten auf konsistente und vorhersagbare Weise austauschen können.

FHIR definiert klar Standards für Schnittstellen, welche in Form einer RESTful – API angeboten werden. Diese Schnittstellen bieten für jeden „Ressourcentyp“ fest vorgegebene Interaktionen, die zur Verwaltung des Datenaustausches dienen.

Ein FHIR-Server dient als Kommunikationsnetzwerk zwischen verschiedenen Anwendungen und Systemen im Gesundheitswesen. Er ermöglicht eine schnelle und sichere Verarbeitung, Validierung und Verwaltung von größeren Mengen an gesundheitsbezogenen Daten gemäß der HL7© FHIR Spezifikation.

FIYAWARE ist im Kern ein FHIR© Server, der mit zugehöriger Business Logik, das Speichern von Daten in Fhir entweder temporär, direkt am Server oder über eine extern angebundene Datenbank langfristig ermöglicht. Weiters bietet FIYAWARE die Möglichkeit nicht FHIR-Daten nach FHIR zu transformieren und auch FHIR-Daten in ein bestehenden Datenschema umwandeln.

Die Black Tusk bietet Unterstützung bei der Integration in ein bestehendes System und Support, der gerne für alle Fragen zur Verfügung steht. Wir arbeiten nach einem Feature driven development, was den Kunden die Möglichkeit gibt, direkten Einfluss auf die Entwicklungs-Roadmap zu nehmen. Fiyaware bietet eine DSGVO conforme Löschfunktion und ist ISIK-Zertifiziert. Unser FHIR-Server kann jedes Profil speichern und fast 100% validieren. Diese Funktionalität und unsere Langjährige Erfahrung in der FHIR-Beratung heben uns klar von unseren Mitbewerbern ab.

FIYAWARE Server ist die Kernkomponente des FIYAWARE Suite, während HealthStorage eine spezifische Anwendung von FIYAWARE Suite ist, die den Anforderungen eines Medizinprodukts genügt und von HSE365.at angeboten wird. Die Suite umfasst weitere Module zur Interoperabilität im Gesundheitswesen (Datentransformation etc).

FIYAWARE kann von Black Tusk GmbH und HSE365AT durch direkte Kontaktaufnahme oder über den Microsoft Azure Marketplace (Link sobald verfügbar) erworben werden.

Preis auf Anfrage.

Die Auslieferung des Docker-Images erfolgt nach Vertragsabschluss. Für die Installation wird ein eigener Server benötigt. Anforderungen an den Server sind Use Case spezifisch und können mit Unterstützung der Black Tusk GmbH erarbeitet werden. (Mind. Anforderungen für die reine Speicherung wären 4GB Ram und 4vCores (Virtual Cores)). Alternativ ist ein Bezug auch über den Microsoft Azure Marketplace möglich. Die Abrechnung erfolgt hier stundenbasiert - es wird aber kein eigener Server benötigt.

Ja, FIYAWARE Server kann mit der deutschen elektronischen Patientenakte (ePA) kompatibel sein, da die ePA auf dem FHIR-Standard basiert. FIYAWARE Server unterstützt zudem eine Vielzahl an Profilen, die von deutsche Behörden (Gematik und KBV) publiziert wurden. Ein Aspekt zur Kompatibilität mit der ePA ist die Integration mit Fachdiensten und Komponenten der Telematikinfrastruktur. Diese Integrationen werden derzeit noch nicht unterstützt.

FIYAWARE kann in ein Praxisverwaltungssystem (PVS) integriert werden, um den Datenaustausch und die Interoperabilität zu verbessern. Entweder als zentraler Interoperabilitätsserver in der Gesamtarchitektur, als Kommunikationsserver oder auch als sogenannte Facade, basierend auf einem bestehenden PVS. Hierbei kann das PVS über die Facade nach außen in der FHIR Sprache kommunizieren und kann gleichzeitig ihr Datenmodell und die Architektur erhalten. Es ist lediglich erforderlich einen Connector oder Übersetzer zu implementieren. Dieser wird von Black Tusk gerne projektspezifisch entwickelt. Aufgrund der Tatsache, dass jedes System anders aufgebaut ist mit einem ganz eigenen Datenmodell ist dieser Connector immer eine Sonderanfertigung.

Das bieten wir auf Projektbasis an, ganz auf die Bedürfnisse des Kunden und vor allem auf dessen Use Case zugeschnitten. Die Schnittstelle ist gut dokumentiert und entspricht dem FHIR-Standard. Allerdings ist hier eine Definition des Inputs und Outputs sehr wichtig (Use Case Speicherung, Retrieval, Broker, etc.).

Wir unterstützen die FHIR-Standardversionen R4, R4b und R5.

Mit Black Tusk FHIR Consulting: Wir analysieren ihr bestehendes Datenmodell und transformieren oder erstellen daraufhin ihr maßgeschneidertes FHIR-Datenmodel.

Sie können fhir-engine so konfigurieren, dass sie auch ohne Authentifizierung, mit integrierter JWT-Authentifizierung oder mit Keycloak (Standard) arbeitet.

• Dies ist in den Einstellungen über die Umgebungsvariable AUTH_PROVIDER konfigurierbar [`none`, `internal`, `keycloak`].
• Wenn Sie `internal` wählen, können Sie über das Adminpanel Benutzer anlegen, die auf die API zugreifen können.
• Sowohl in `internal` als auch in `keycloak` können Sie JWT-Token über den/die Endpunkt(e) `/auth/token` beziehen, verifizieren und aktualisieren.
• Es kann aber auch ein eigener Mechanismus implementiert werden.

Unsere fhir-engine ist datenbankunabhängig gebaut, funktioniert aber am besten mit PostgresSQL. Sie können die Datenbank über die `DB_*` Umgebungsvariablen konfigurieren.

Um eine Suche gemäß der FHIR-Spezifikation unter Verwendung einer SQL-Datenbank durchführen zu können, normalisiert fhir-engine die fhir-Ressourcen in einer flachen Tabellenstruktur. Sie verwendet eine zweite Tabelle als Many-to-Many-Beziehungstabelle, um beliebig komplexe verkettete und rückwärts verkettete Suchen durchzuführen. Die Suchmöglichkeiten können einfach durch Hinzufügen von Suchparameter-Definitionen im JSON-Format gemäß der FHIR-Spezifikation erweitert werden.

Es werden Bundles vom Typ 'Transaction' und 'Batch' unterstützt.

• Bundles vom Typ 'Transaction' werden atomar ausgeführt, d.h. wenn eine der Ressourcen im Bundle nicht verarbeitet werden kann, wird das gesamte Bundle zurückgerollt.
• Bundles vom Typ 'Batch' werden unabhängig voneinander ausgeführt, d.h. wenn eine der Ressourcen im Bundle nicht verarbeitet werden kann, werden die anderen Ressourcen im Bundle trotzdem verarbeitet. Bei Bundles des Typs 'Batch' wird jedoch die formale Gültigkeit des Bündels als Ganzes geprüft, bevor eine der Anforderungen verarbeitet wird.

Die `fhir-engine` wird durch eine eigene Bibliothek betrieben, die `fhir.resources` und `fhirpath.py` umhüllt, und gleichzeitig die offizielle FHIR Path-Javascript-Implementierung nutzt. Dies ermöglicht es `fhir-engine`, benutzerdefinierte Profile und Erweiterungen zu laden und Ressourcen gegen sie zu validieren.