FIYAWARE is essentially a FHIR© server, with associated business logic, enabling data storage in FHIR either temporarily on the server or long‑term via an externally connected database. It also provides the capability to transform non‑FHIR data into FHIR and convert FHIR data into an existing data schema.
Black Tusk offers support for integration into existing systems and provides customer support for all inquiries. We follow feature‑driven development, which allows customers to directly influence the development roadmap. FIYAWARE provides GDPR‑compliant deletion functionality and is ISiK certified. Our FHIR server can store any profile and validate almost 100%. This functionality and our long‑standing experience in FHIR consulting clearly set us apart from competitors.
FIYAWARE Server is the core component of the FIYAWARE Suite, whereas HealthStorage is a specific application of the Suite that meets medical device requirements and is offered by HSE365.at. The Suite includes additional modules for interoperability in healthcare (data transformation, etc.).
FIYAWARE can be obtained from Black Tusk GmbH or HSE365AT via direct contact or through the Microsoft Azure Marketplace (link forthcoming).
Price upon request.
The Docker image is delivered after contract signing. Installation requires a dedicated server. Server requirements depend on the use case and can be determined with support from Black Tusk GmbH. (Minimum for pure storage: 4 GB RAM and 4 virtual cores). Alternatively, it can be accessed via the Microsoft Azure Marketplace. Billing is hourly, and no separate server is required.
Yes, FIYAWARE Server can be compatible with the German Electronic Patient Record (ePA), as the ePA is based on the FHIR standard. FIYAWARE Server also supports numerous profiles published by German authorities (Gematik and KBV). Integration with TI components and specialized services, however, is not yet supported.
FIYAWARE can be integrated into a practice management system (PVS) to improve data exchange and interoperability. It can function as a central interoperability server, communication server, or as a façade on top of an existing PVS. This allows the PVS to communicate externally via FHIR while retaining its internal data model and architecture. A connector or translator needs to be implemented, which Black Tusk can develop project‑specifically. Since each system is unique with its own data model, this connector is always custom‑made.
We offer this on a project basis, tailored to the customer's needs and especially to their use case. The API is well documented and conforms to the FHIR standard. A clear definition of input and output (e.g. storage, retrieval, broker) is essential.
We support FHIR standard versions R4, R4b, and R5.
Mit Black Tusk FHIR Consulting: Wir analysieren ihr bestehendes Datenmodell und transformieren oder erstellen daraufhin ihr maßgeschneidertes FHIR-Datenmodel.
You can configure fhir-engine to operate without authentication, with built‑in JWT authentication, or with Keycloak (standard).
Our fhir-engine is database‑agnostic, but works best with PostgreSQL. The database can be configured via the `DB_*` environment variables.
To perform searches according to the FHIR specification using an SQL database, fhir‑engine normalizes FHIR resources into a flat table structure. It uses a second many‑to‑many relationship table to support arbitrarily complex chained and reverse chained searches. Search capabilities can be easily extended by adding search parameter definitions in JSON format according to the FHIR specification.
Bundles of type 'transaction' and 'batch' are supported.
The fhir‑engine operates via its own library that wraps `fhir.resources` and `fhirpath.py` and simultaneously uses the official FHIRPath JavaScript implementation. This allows fhir‑engine to load custom profiles and extensions and validate resources against them.