FHIR© is both, an information network that links data between different systems and a communication network that enables the exchange of data among systems.

FHIR© stands for Fast Healthcare Interoperability Resources.

FHIR© is an open standard (open source) and therefore available to everyone. It is easy to use as it is compatible with common web technologies such as XML, HTTPS and JSON. Due to the large community, there are already numerous existing healthcare scenarios that are mapped and continually increasing in number. FHIR offers a dual function for resources, which transmits and maps data in both human-readable and machine-readable form. This means that electronic data can be used both in human-to-human scenarios and in automated computer processing.

The FHIR© standard is a format for providing a data structure that enables data to be exchanged between different eHealth providers and end users without data loss. Based on clearly defined “rules” using FHIR resources, party A knows which data party B needs and in what form it should be made available.

Profiles are special configurations of the FHIR© standard that are used to customize and extend FHIR resources for specific use cases or needs. A FHIR profile defines a specific use or limitation of FHIR resources to ensure that the data exchanged between different systems is consistent and interoperable. Profiles are central to the customization of FHIR to national, regional or institutional requirements.

FHIR clearly defines standards for interfaces, which are provided as a RESTful API. These interfaces offer predefined interactions for each “resource type”, which are used to manage the exchange of data.

A FHIR© server is used as a communication network between different applications and systems in the healthcare sector. It enables fast and secure processing, validation and management of large amounts of health-related data in accordance with the HL7© FHIR specification.

FIYAWARE is essentially a FHIR© server which, together with the associated business logic, enables data to be stored in FHIR either temporarily, directly on the server or on a long-term basis via an externally connected database. FIYAWARE also offers the option of transforming non-FHIR data into FHIR and converting FHIR data into an existing data schema.

Black Tusk offers support for integration into an existing system and provides support for all questions. We work on a feature driven development basis, which gives customers the opportunity to have a direct influence on the development roadmap. Fiyaware offers a GDPR compliant delete function and is ISIK certified. Our FHIR server can store and validate almost 100% of each profile. This functionality and our many years of experience in FHIR consulting clearly set us apart from our competitors.

FIYAWARE Server is the core component of FIYAWARE Suite, while HealthStorage is a specific application of FIYAWARE Suite that meets the requirements of a medical device and is offered by HSE365.at. The suite includes further modules for interoperability in the healthcare sector (data transformation, etc.).

FIYAWARE can be purchased from Black Tusk GmbH and HSE365AT by contacting them directly or via the Microsoft Azure Marketplace (link as soon as available).

Price on request.

The Docker image is delivered after the contract is concluded. A dedicated server is required for the installation. Requirements for the server are use case specific and can be worked out with the support of Black Tusk GmbH. (Minimum requirements for pure storage would be 4GB Ram and 4vCores (Virtual Cores)). Alternatively, procurement is also possible via the Microsoft Azure Marketplace. Billing is based on an hourly rate - but you do not need your own server.

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 a large number of profiles published by German authorities (Gematik and KBV). One aspect of compatibility with the ePA is integration with specialist services and components of the telematics infrastructure. These integrations are not yet supported.

FIYAWARE can be integrated into a practice management system (PMS) to improve data exchange and interoperability. Either as a central interoperability server in the overall architecture, as a communication server or as a so-called facade, based on an existing PMS. In this case, the PMS can communicate externally via the facade in the FHIR language and can maintain its data model and architecture at the same time. The only thing that needs to be implemented is a connector or translator. Black Tusk is happy to develop this on a project-specific basis. Due to the fact that every system is structured differently with its very own data model, this connector is always a custom-made product.

We can offer this on a project basis tailored entirely to the needs of the customer and, above all, to their use case. The interface is well documented and complies with the FHIR standard. However, a definition of the input and output is very important here (use case storage, retrieval, broker, etc.).

We support the FHIR standard versions R4, R4b and R5.

With Black Tusk FHIR Consulting: We analyze your existing data model and then transform or create your customized FHIR data model.

You can configure the fhir-engine to operate without authentication, with integrated JWT authentication or with Keycloak (default).

• This can be configured in the settings via the AUTH_PROVIDER environment variable [`none`, `internal`, `keycloak`].
• If you select 'internal', you can create users who can access the API via the admin panel.
• In both `internal` and `keycloak` you can obtain, verify and update JWT tokens via the `/auth/token` endpoint(s).
• However, a separate mechanism can also be implemented.

Our fhir-engine is database-independent, but works best with PostgresSQL. You can configure the database via the `DB_*` environment variables.

In order to perform a search according to the FHIR specification using an SQL database, fhir-engine normalizes the fhir resources in a flat tabular structure. It uses a second table as a many-to-many relationship table to perform arbitrarily complex chained and backwards chained searches. The search options can be easily extended by adding search parameter definitions in JSON format in accordance with the FHIR specification.

Bundles of type 'Transaction' and 'Batch' are supported.

• Bundles of type 'Transaction' are executed atomically, i.e. if one of the resources in the bundle cannot be processed, the entire bundle is rolled back.
• Bundles of type 'Batch' are executed independently of each other, i.e. if one of the resources in the bundle cannot be processed, the other resources in the bundle are still processed. With bundles of type 'Batch', however, the formal validity of the bundle as a whole is checked before one of the requests is processed.

The `fhir-engine` is powered by a custom library that wraps `fhir.resources` and `fhirpath.py`, while utilizing the official FHIR Path javascript implementation. This allows `fhir-engine` to load custom profiles and extensions and validate resources against them.