← Back to use cases

DiGA Technical Requirements Checklist for the Backend Layer

A practical English-language reference for the technical, security, and interoperability requirements the BfArM Fast-Track procedure places on the backend of a Digitale Gesundheitsanwendung (DiGA), with a checklist that maps each requirement onto an architectural decision a backend team has to make.

Executive Summary

The German Fast-Track procedure for Digitale Gesundheitsanwendungen (DiGAs) is one of the few national reimbursement pathways in the world that lets a digital health product reach prescribing clinicians and reimbursement within twelve months of a successful application. The procedure is run by the Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM) and is regulated through the Digitale-Gesundheitsanwendungen-Verordnung (DiGAV). Manufacturers submit evidence covering safety, functional fitness, quality, data protection, information security, interoperability, and (for permanent listing) positive care effects.

Most public material on the procedure is in German and addresses the manufacturer at the product level: safety, the clinical evaluation, the cost-effectiveness argument, the user-facing app. Backend-specific guidance is harder to find in English, even though the backend layer is where many of the technical and security requirements actually live.

This paper is a backend-layer companion to the Fast-Track procedure. It walks through the parts of the DiGAV Anlage that depend on the backend, organises the requirements into a checklist a backend team can work through, and explains the architectural decisions each requirement implies. The intended outcome is a backend deployment that lines up with what a BfArM assessor expects to see when they review the technical-and-security part of a DiGA submission, and that survives the annual review cycle without re-architecting on every renewal.

The paper is not legal advice and does not replace the BfArM’s own published guidance. Manufacturers should treat it as a starting reference for technical decisions and consult the BfArM, their data protection officer, and their notified body for the parts of the submission that depend on their specific product context.

1. Audience and Scope

This paper is intended for:

  • DiGA manufacturers preparing a Fast-Track submission, with a focus on the engineering and security leads responsible for the backend layer.
  • Product teams operating a listed DiGA whose backend is under continuous review and annual renewal.
  • Notified Body reviewers and BfArM assessors evaluating the backend layer of a DiGA submission, where this paper offers a vendor-neutral framing of the architectural decisions involved.
  • Compliance and data protection officers who need a technical reference they can hand to their engineering teams alongside the BfArM’s published guidance.

In scope

  • The technical-and-security requirements of the DiGAV Anlage that depend on the backend layer.
  • The interoperability requirements that the BfArM links to gematik specifications, in particular the ISiK profile family.
  • Common architectural decisions a backend team faces, with the trade-offs each implies.
  • The relationship between the DiGAV requirements and broader regulatory frameworks (GDPR, MDR, IEC 62304) where the overlap matters for the backend.
  • A checklist that consolidates the requirements into reviewable items.

Out of scope

  • Legal advice on whether a specific product qualifies as a DiGA.
  • The clinical evaluation, the positive-care-effects study design, and the cost-effectiveness argument.
  • The user-facing app’s UX, accessibility, and content review.
  • Marketing approval, prescribing workflows, and reimbursement billing flows beyond the backend’s role in supporting them.

2. The Fast-Track Procedure in Brief

A DiGA is a CE-marked medical device of risk class I or IIa whose principal function depends on a digital technology and whose intended purpose is to detect, monitor, treat, or alleviate diseases or to detect, treat, alleviate, or compensate for injuries or disabilities. In practice that translates to apps and web platforms used by patients (often together with their treating clinician) to manage a defined health condition.

The Fast-Track procedure runs in three steps. The manufacturer submits the product to BfArM with the documentation specified in the DiGAV. BfArM reviews the submission within three months. On a positive review, the DiGA enters the directory provisionally for up to twelve months and may be prescribed and reimbursed during that period. To remain in the directory, the manufacturer must demonstrate positive care effects through evaluation studies the BfArM has agreed to.

The BfArM has published a Fast-Track guidance document that describes the dossier in detail. Anlage 1 covers the requirements for the DiGA’s technical and security properties and is the primary backend-relevant document. Anlage 2 covers interoperability. The DiGAV itself defines the data protection requirements through its Anhang.

Most of what follows refers to Anlage 1 and the interoperability material because that is where the backend lives. The data protection material is largely a GDPR-Article-9 framing applied to a German healthcare context; the backend has to support the manufacturer’s choices there but does not by itself determine them.

3. The Anlage 1 Backend Checklist

The technical-and-security part of the BfArM dossier is structured as a self-declaration with attached evidence. The manufacturer answers a series of questions about the product’s technical properties, identity and access management, audit, encryption, hosting, and so on. Each answer has to be supported by evidence the assessor can review. The following sections walk through the categories where the backend is the relevant component.

3.1 Identity and authentication

  • Authentication mechanism for end users. The backend has to support the authentication flow the user-facing app uses. Modern DiGAs typically use OAuth 2.0 / OIDC against a managed identity provider; the backend validates the access tokens and resolves the authenticated user to a stable identifier. Form-based password authentication remains acceptable in legacy contexts but is harder to defend against the security questions BfArM asks.
  • Multi-factor authentication. For users with elevated privileges (clinicians, support staff with patient-data access, administrators) MFA is expected. The backend does not implement MFA itself but must interoperate with an identity provider that does.
  • Identity-to-FHIR-resource mapping. The backend should resolve each authenticated subject to a stable identifier inside the data model. For a FHIR-backed DiGA that means mapping to a Patient, Practitioner, RelatedPerson, or Device resource. The mapping is what makes audit and access control attributable in clinical terms rather than in opaque user IDs.
  • Service account management. Inbound integrations (the gematik telematics infrastructure, payer systems, study data exports) authenticate as service accounts. Each service account should have a documented scope, a documented owner, and a documented rotation policy.

3.2 Authorisation

  • Default-deny posture. The backend should enforce a default-deny rule chain: a request that does not match an explicit grant is denied. This is the architectural foundation for the data minimisation argument.
  • Role-based rules tied to clinical relationships. Patients see their own data. Clinicians see patients within their care relationship. Sponsors see anonymised aggregates. Each role is expressed as a rule against the backend’s access model.
  • Search narrowing. Server-side filtering at the database layer prevents data leakage through search parameters. A patient role’s search should never return another patient’s data, even if the search parameters could theoretically match.
  • Field-level redaction. Property-level filters strip sensitive fields from authorised responses where the role permits the resource but not all of its fields. This is the mechanism that supports analytics, sponsor, and research access without copying data into a separate store.
  • Side-channel protection. Search parameters, sort parameters, and reference traversals can leak information about resources the role is not permitted to see. The backend should support a per-role mechanism for blocking such parameters.

3.3 Audit

  • Identity-attributable audit on every access. Each authorised request should emit an audit record with the resolved identity, the operation, the resource, and the rule that authorised it. The audit covers REST, GraphQL, bulk operations, and any other API surface uniformly.
  • Append-only audit storage. Audit records should be appended to a log that the operating environment treats as append-only, with retention configured to support BfArM and patient-side access requests.
  • Retention period. GDPR Article 30 and BSI guidance both touch on retention. A typical baseline is two years for security audit; longer periods may apply where the backend serves as a source for medical-device traceability under MDR.

3.4 Encryption

  • Transport encryption. TLS 1.2 or higher for all client traffic. TLS termination should not happen in places the operator does not control (no opaque CDN-managed termination of in-flight PHI).
  • At-rest encryption. Database-level encryption is the standard control; the backend’s role is to operate on storage that supports it. Application-level field encryption is a deployment decision driven by threat-model specifics rather than a baseline expectation.
  • Key management. Keys should be managed by a service the operator controls, with rotation procedures documented in the dossier.

3.5 Hosting and data residency

  • Data residency. EU residency is the default expectation for DiGAs. Hosting outside the EU triggers the standard GDPR Chapter V analysis, which is a heavy lift relative to operating inside the EU.
  • Hosting provider categories. ISO 27001-certified providers in EU regions are the baseline. Cloud-based hosting is acceptable; self-hosting in a customer-controlled environment is also acceptable. The backend should run consistently across both.
  • Operator separation. When the backend operator is a different legal entity from the DiGA manufacturer, a Data Processing Agreement under GDPR Article 28 is required. The DPA should specify the technical and organisational measures, the subcontractor flow-down, and the procedure for data subject rights requests routed through the operator.

3.6 Interoperability

  • FHIR R4 storage. ISiK and most other German healthcare profiles are built on FHIR R4. Storing data as standard FHIR R4 from day one is the architectural decision that pays back across every integration the DiGA has to support.
  • Profile validation. Conformance to specific ISiK modules is a profile-validation question rather than a schema-migration question if the underlying store is FHIR R4.
  • gematik telematics infrastructure. Where the DiGA integrates with TI services (the secure messaging platform KIM, the electronic patient record ePA, the e-prescription system), the integration is typically handled by a connector component. The backend exposes the FHIR surface that connector reads from and writes to.
  • Cross-sector exchange. Hospital systems and ambulatory practices increasingly need ISiK-conformant exchange. A DiGA that holds patient-generated outcomes can contribute that data through the same FHIR surface.

3.7 Operational lifecycle

  • Versioned releases with documented changes. Each backend release should ship with documented changes and an impact assessment. Annual renewal of the DiGA listing draws on this evidence.
  • Security advisory channel. A documented channel for security advisories that affect production deployments is a baseline expectation.
  • Backup and recovery. Backup procedures, recovery time objectives, and the test cadence for both should be documented in the dossier.
  • Incident response plan. A documented plan that covers detection, containment, notification (including the GDPR breach notification timelines), and post-incident review.

4. The Interoperability Anlage and ISiK

The interoperability annex is shorter than Anlage 1 but no less important. The BfArM has aligned the interoperability expectations with the gematik’s ISiK profile family for hospital-information-system exchange. Even DiGAs that do not exchange directly with hospital systems benefit from aligning the backend’s data model with ISiK because it lowers the integration cost when an exchange becomes relevant.

4.1 What ISiK actually is

ISiK (Informationstechnische Systeme im Krankenhaus) is a set of FHIR R4 profiles published by the gematik. The profiles constrain base FHIR resources to the structure German hospital information systems and their integration partners exchange. ISiK is rolled out in stages; each stage adds clinical domains and participants.

For the backend the practical implication is profile-validation. Resources stored as standard FHIR R4 can be validated against the relevant ISiK profile when they are projected for an ISiK-conformant integration, without changing the underlying schema. Adding a new ISiK module is a profile-validation configuration plus a route on the integration layer.

4.2 KBV profiles

KBV (Kassenärztliche Bundesvereinigung) profiles cover ambulatory care exchange. Where a DiGA integrates with a clinician’s practice management system, KBV profiles are typically the relevant target. The same FHIR R4 store supports them.

4.3 The connector pattern

Direct integration with gematik telematics infrastructure runs through a TI connector. The connector handles the TI-specific transport, authentication, and routing. The backend exposes the FHIR surface the connector reads from and writes to. Keeping the TI-specific complexity in the connector and the data model agnostic of any one integration is the architectural pattern that scales across the multiple integrations a DiGA accumulates over time.

5. The Data Protection Anhang

The DiGAV Anhang covers data protection. It is largely a Germany-specific application of GDPR Article 9 (special-category data) plus BSI cybersecurity expectations. The backend supports the manufacturer’s data-protection choices but does not by itself decide them. Three areas matter most for the backend.

5.1 Lawful basis per access

Each access to patient data should be tied to a documented lawful basis. The backend supports this by recording the resolved identity and the role on each access. The basis itself is documented in the manufacturer’s privacy notice and DPIA.

5.2 Data subject rights

Patients have rights of access, rectification, erasure, portability, and objection. The backend supports these by exposing the relevant FHIR operations through the patient’s role: a patient-compartment search for access; a write for rectification; a delete (subject to retention exceptions) for erasure; a Bulk Data export for portability.

The hardest of these in practice is erasure. A medical-device-relevant retention exception applies in most cases, which means erasure is rarely a hard delete; it is more often a soft delete with the relevant resources marked as inactive and excluded from operational queries. The exact policy is the manufacturer’s call; the backend supports both shapes.

5.3 BSI cybersecurity baseline

The Bundesamt für Sicherheit in der Informationstechnik (BSI) publishes guidance on cybersecurity baselines for healthcare applications. The expectations for a DiGA backend overlap heavily with what an ISO 27001-aligned ISMS already covers: identity and access management, audit, encryption, incident response, and supplier management. The dossier should describe the baseline the deployment operates against.

6. Common Architectural Decisions

Working through the checklist surfaces a small number of architectural decisions that determine how much of the dossier writes itself versus how much has to be reconstructed for each annual review.

6.1 FHIR-native vs custom schema

Storing patient data as standard FHIR R4 from the start is the most consequential decision. The interoperability annex assumes FHIR; the data subject rights are easier to fulfill against FHIR; the integration cost for any future partner drops materially when the data is already FHIR-shaped.

A custom schema can work but turns interoperability into ongoing translation work and turns rights fulfillment into custom export pipelines.

6.2 Centralised authorisation vs scattered checks

Centralising authorisation in a dedicated rule chain, evaluated at the data layer, makes the access boundary auditable. Scattered checks in application code make the boundary hard to defend in front of an assessor and hard to keep consistent across REST, GraphQL, and bulk surfaces.

The architectural pattern most aligned with the BfArM’s expectations is a deny-by-default rule chain that all access surfaces flow through.

6.3 Audit as a property of the system vs a per-endpoint concern

When audit is implemented per endpoint, completeness becomes an argument rather than a property. When audit is emitted by the data-access layer for every authorised request, completeness is a property of the system the operator can demonstrate.

Audit emitted at the data-access layer survives review cleanly and supports patient-side access-log requests through a single search.

6.4 EU residency as a default vs a configuration

Building the deployment around EU residency from the start removes a category of dossier work and a category of data-processing argument. Treating EU residency as a configuration that can be flipped later usually means flipping it under deadline pressure once a deal or a regulator surfaces the requirement.

6.5 Backend-supplier discipline

For the parts of the backend the manufacturer does not write themselves (FHIR server, identity provider, hosting), a supplier that publishes versioned releases, security advisories, change history, and product documentation is the difference between a smooth annual review and a manual reconstruction. The manufacturer pulls those artifacts into their own QMS and dossier rather than reconstructing them.

7. The Permanent-Directory Transition

A DiGA enters the directory provisionally for up to twelve months. To stay listed it has to demonstrate positive care effects through evaluation studies the BfArM has agreed to. The technical-and-security side of the dossier remains under continuous obligation throughout this period.

For the backend the practical concern is two-fold. The backend has to keep operating predictably under growing patient volumes and changing usage patterns. And the backend has to provide the evaluation team with the data they need without breaking the access boundary that gates clinical use.

7.1 Operational stability

The growth pattern for a successfully-listed DiGA is rarely flat. Marketing and clinician outreach typically push patient volumes up after listing, and the backend has to handle that growth without re-architecture. The architectural decisions taken before submission (FHIR-native storage, centralised authorisation, identity-attributable audit) all pay back here because they scale through configuration rather than through new code.

7.2 Evaluation data access

The evaluation team needs access to the patient data the study is built around. A research role with property filters that strip identifiers and search-parameter blocklists that prevent reverse-engineering covers this case. Same database, same audit, different access scope. The evaluation team’s reads are part of the same audit log that covers clinician and patient access.

A common anti-pattern is to copy data into a separate research warehouse with its own access model. This works but doubles the surface area, complicates the auditability story, and has to be defended separately in the dossier.

7.3 Annual renewal

The annual renewal draws on the operational evidence the deployment has accumulated. Audit completeness, change-control discipline, security-advisory handling, and the backend supplier’s published release record all feed the renewal package. A backend whose supplier publishes those artifacts on an ongoing cadence (rather than producing them in response to the renewal) makes the renewal a paperwork exercise rather than a project.

8. Where Manufacturers Most Often Get Stuck

Across submissions and annual reviews a small number of issues account for most of the time-sinks the manufacturer experiences.

8.1 Audit completeness across access surfaces

The most common gap is incomplete audit coverage across access surfaces. REST is audited; GraphQL is audited differently; bulk operations are audited inconsistently. The fix is to push audit emission down to the data-access layer so the surface is irrelevant; the alternative is to argue for completeness across each surface, which is a harder argument to win.

8.2 Search-parameter side channels

Property-level redaction without search-parameter blocking creates a side channel. A reviewer who looks for it will find it. The fix is to combine property filters with explicit search-parameter blocklists per role; the alternative is to defend why the side channel doesn’t matter, which is an argument the assessor is unlikely to accept.

8.3 Erasure under retention exceptions

Erasure requests in a regulated context almost always run into retention exceptions. Document the exceptions in advance (which resources are retained for medical-device traceability, billing, or legal hold) and handle erasure as a soft delete with the documented exceptions. Arguing retention case-by-case in response to each request is the failure mode that does not scale.

8.4 Identity-to-FHIR mapping in the backend

Some backends authenticate the user but never bind the user to a FHIR identity. The audit log then records opaque user IDs that have no clinical meaning. The fix is to bind authentication to a FHIR identity (Patient, Practitioner, RelatedPerson, Device) at the boundary; the alternative is to translate IDs after the fact, which loses the connection in practice.

8.5 Supplier evidence under the manufacturer’s QMS

When the backend is supplied by a vendor under their own QMS, the manufacturer needs the supplier’s published release artifacts (versioned releases, change history, security advisories, product documentation) to plug into their own QMS. When the supplier ships only marketing material and not supplier evidence, the manufacturer has to reconstruct the record from public documents. The fix is to require those artifacts as part of the supplier selection process; the alternative is to do without and pay the reconstruction cost on every renewal.

9. A Consolidated Checklist

The following list consolidates the points above into a checklist a backend team can work through during preparation for a submission or for an annual review.

Identity and authentication

  • OAuth 2.0 / OIDC for end-user authentication, with token validation in the backend.
  • MFA requirement for elevated-privilege roles enforced through the identity provider.
  • Identity-to-FHIR-resource mapping for every authenticated subject.
  • Service account inventory with documented scope, owner, and rotation policy.

Authorisation

  • Default-deny rule chain at the data layer.
  • Roles for patient, clinician, support, integration partner, and study/research access.
  • Search narrowing applied at the database layer.
  • Property-level redaction for roles that see resources but not all fields.
  • Search-parameter blocklists per role to prevent side channels.

Audit

  • Identity-attributable audit on every authorised request.
  • Audit covers REST, GraphQL, and bulk uniformly.
  • Append-only audit storage with documented retention.

Encryption

  • TLS 1.2+ for all client traffic.
  • Database-level at-rest encryption.
  • Key management procedures documented in the dossier.

Hosting

  • EU-region deployment by default.
  • ISO 27001-certified hosting provider where applicable.
  • DPA in place where the backend operator and the DiGA manufacturer differ.

Interoperability

  • FHIR R4 storage with profile validation.
  • ISiK conformance as a profile configuration where required.
  • TI connector pattern documented for relevant integrations.

Operational lifecycle

  • Versioned backend releases with documented changes.
  • Security advisory channel for production deployments.
  • Documented backup, recovery, and incident response procedures.

Permanent-directory readiness

  • Research role with property filters and search-parameter blocklists for the evaluation team.
  • Operational evidence collected as ongoing artifacts.
  • Annual renewal package draws on existing artifacts rather than reconstruction.

10. Closing

The Fast-Track procedure is a clear path with well-published expectations, but the backend layer of the dossier rewards architectural decisions taken early. FHIR-native storage, centralised authorisation, identity-attributable audit, EU residency, and a backend supplier whose release artifacts feed the manufacturer’s QMS each remove a category of work from the submission and from every subsequent annual review.

The procedure does not require an exotic technology stack. It requires a backend that documents what it does, that enforces what it claims, and that remains stable as the product grows. The checklist above translates those requirements into reviewable items.

Manufacturers who build with this checklist in mind tend to spend the submission window on the clinical evaluation rather than on the technical-and-security dossier, which is where the time pays back.

References