DiGA

DiGA-Compliant FHIR Backend (Germany)

German healthcare interoperability runs on FHIR profiles. ISiK (hospital systems) and KBV (ambulatory care) are both built on FHIR R4. Fire Arrow stores standard FHIR R4 with profile validation, and the authentication, authorization, and audit obligations the DiGAV places on the backend are part of the default deployment.

Book a DiGA backend review Read deployment docs

What you can build

FHIR-native, so ISiK and KBV are configuration, not migration
ISiK and KBV are FHIR R4 profile families. Fire Arrow stores standard FHIR R4 with profile validation, so conformance to a specific ISiK or KBV module is a profile configuration, not a schema change.
DiGAV access controls in the default deployment
OAuth/OIDC identity, deny-by-default authorization, identity-attributable audit across REST, GraphQL, and bulk surfaces. The BfArM technical-and-security questions in Anlage 1 map to documented behavior rather than custom code.
DSGVO scoping fit for the DiGA model
Per-request audit attribution, Consent resources stored as standard FHIR, and primitives that support data subject requests ($everything for export, resource deletion). EU residency by deployment region. The lawful-basis determination and the data subject request workflow remain the manufacturer's responsibility.

What you get out of the box

Capability With Fire Arrow Building it yourself

Anlage 1 technical-and-security requirements Identity-attributable audit, deny-by-default authorization, EU residency, and TLS by default. Behavior and configuration are documented in the product reference, ready to be cited in the manufacturer's submission. Custom backend whose technical-and-security evidence has to be assembled from scratch for every Fast-Track submission and every annual update.

ISiK and KBV profile support FHIR R4 store with profile validation. ISiK and KBV conformance is a profile configuration, and projecting internal resources into the receiver's profile happens in the same store. Custom mapping layer between an internal data model and the ISiK/KBV profiles, maintained as both families evolve.

DSGVO request-level audit and patient data scoping Identity, role, scope, and access boundary recorded per request as identity-attributable audit. Consent resources stored as standard FHIR. Patient compartments and identity-filtered rules limit access to the patient data each caller is entitled to. EU residency by deployment. Custom audit and consent recording assembled per release, with EU residency proven across every component of the stack.

BSI TR-03161 backend-layer technical controls Supports the technical controls in scope at the backend layer for BSI TR-03161 (the security testing standard the BfArM applies to DiGA): authentication, authorization, transport encryption, encryption at rest at the database layer, and identity-attributable audit. Application-side and organisational controls remain the manufacturer's responsibility. Same controls, but distributed across in-house code and infrastructure.

Service-account access for telematics infrastructure OIDC and Microsoft Entra ID for service accounts, resolved to a Practitioner or Device identity and bound by the same authorization rule chain as users. API tokens are available where OIDC is not feasible, with rotation and revocation in the admin API. Custom token management built around an authentication framework not designed for clinical service accounts.

Operational fitness for permanent listing Versioned releases, change-control notes, and a security advisory channel that the manufacturer can reference in the annual renewal. Custom evidence assembled in-house for every annual renewal cycle.

Who this is for

DiGA manufacturers preparing the BfArM Fast-Track submission and product teams maintaining a listed DiGA whose backend is under continuous review.

Clinical applicability

A DiGA app for chronic pain management captures patient self-assessments and clinician annotations as FHIR resources. The Fast-Track submission documents how the backend protects patient data, how DSGVO obligations are met, and how the backend exchanges data with hospital and ambulatory systems through ISiK and KBV profiles.

What the BfArM checks at the backend layer

The Fast-Track procedure runs through Anlage 1 (technical and security requirements), Anlage 2 (interoperability), and the DiGAV Anhang for the data-protection self-declaration. The technical-and-security section is where most submissions slow down, because the assessor expects concrete answers about authentication, authorization, audit, encryption, and incident response.

Fire Arrow's defaults answer those questions the same way every time. Identity is OAuth/OIDC tied to a FHIR identity. Authorization is rule-based and deny-by-default. Audit covers REST, GraphQL, and bulk surfaces uniformly. Encryption-at-rest sits at the database layer the operator chose. Incident response runs through the operator's existing procedures.

ISiK and KBV are FHIR R4. Fire Arrow is FHIR-native.

ISiK (Informationstechnische Systeme im Krankenhaus) is the FHIR profile family the gematik defines for hospital information systems and the systems that exchange data with them. KBV publishes the equivalent profile family for ambulatory care. Both are FHIR R4: they constrain and extend the standard resources, they do not replace them.

Fire Arrow stores standard FHIR R4 with profile validation. ISiK or KBV conformance is a profile-validation configuration on the relevant resources, not a schema migration. A DiGA that integrates with hospital systems via ISiK and with ambulatory systems via KBV writes its data once and validates it against whichever profile the receiver requires.

From provisional listing to permanent directory

A DiGA enters the directory provisionally for up to 12 months and then has to demonstrate positive care effects to move into the permanent directory. The backend's job through this transition is to operate predictably, handle a growing patient volume, and retain audit and outcome data in a form the manufacturer can use for the evaluation studies.

Patient-reported outcomes, clinician annotations, and device data all live as FHIR resources, queryable through the same access-control rules. The evaluation team can read the data they need without bypassing the access boundary or standing up a parallel data warehouse.

Related docs

FAQ

Is Fire Arrow listed in the DiGA directory?

Fire Arrow is a backend component used inside DiGAs, not a DiGA itself. The directory listing applies to the manufacturer's product. Fire Arrow's behavior, configuration, and product documentation are the source of the backend-layer evidence the manufacturer assembles for Anlage 1.

Does Fire Arrow support ISiK and KBV profiles?

Yes. ISiK and KBV are FHIR R4 profile families: they constrain and extend the standard resources rather than replacing them. Fire Arrow stores standard FHIR R4 with profile validation, so conformance to a specific ISiK or KBV module is a profile configuration on the relevant resources, not a separate edition.

Where does the data live?

In the database the operator chooses, in the region the operator chooses. EU-only deployments are the default in DiGA contexts. Evoleen-hosted deployments run in EU regions; self-hosted deployments run wherever the manufacturer's environment runs.

What about TI integration through the gematik infrastructure?

TI integration runs through the gematik-defined connectors on the manufacturer's side. Fire Arrow exposes the FHIR R4 surface those connectors expect and supports the identity and audit obligations the gematik specifies.

Does Fire Arrow ship a ready-made BfArM dossier?

No. The dossier is the manufacturer's submission and is specific to the DiGA. Fire Arrow contributes the backend-layer inputs: versioned releases, change-control notes, security advisories, product documentation, and the deployment configuration. We can support customers in mapping those inputs into their Anlage 1 and annual renewal materials, but the dossier itself is not a packaged deliverable of the product license.

How does Fire Arrow help with annual reviews?

Versioned releases, change-control notes, and security advisories are published as the product evolves, so the manufacturer can reference them in the annual renewal. Operational evidence (audit logs, deployment configuration) stays with the manufacturer.