Have you developed an app that is already a medical device – or are you planning to build a DiGA from scratch? Then the most challenging part begins now: the implementation.

Because a DiGA is not a classic software product. In addition to the actual application, you need a resilient backend architecture, secure authentication, clean data processes, interfaces to health insurance companies and – in the long term – a connection to the telematics infrastructure.

This guide shows you which technical components are relevant, how they are connected and what you should pay attention to in practice.

If a DiGA is prescribed by a doctor, statutory health insurance companies cover the costs and reimburse them directly to the manufacturer. In the case of private health insurance companies, reimbursement is based on individual contracts. However, the prerequisite for this is always that the DiGA must first be successfully tested and included in the official list of the BfArM.

The DiGA process is considered one of the most advanced reimbursement processes for digital health applications in Europe. For manufacturers, it opens up the opportunity to improve care and at the same time use a clearly defined commercial access route into the healthcare system.

The legal basis for DiGA can be found in § 33a SGB V. Further requirements are regulated in the DiGAV. The BfArM test criteria and the BfArM’s public information are also relevant.

The DiGA guidelines of the BfArM also provide important orientation.

The BfArM examines a DiGA and includes it in the list if the specified requirements are met.

In addition to the requirements for the application itself, manufacturers must also meet certain formal requirements. In particular, this includes a quality management system in accordance with ISO 13485. The manufacturer must also provide evidence of an information security management system with certification in accordance with ISO 27001 or ISO 27001 based on IT baseline protection. Since April 1, 2022, the BfArM has required a corresponding ISMS certificate from the manufacturer for DiGA; since January 1, 2025, a certificate based on TR-03161 has also been required to prove the data security of the application.

Information security is a central component of every DiGA. BSI TR-03161 defines requirements for the protection of sensitive healthcare data – for example in relation to authentication, encryption and secure data processing.

To be included in the DiGA directory, the manufacturer must prove that the relevant security requirements have been implemented by means of a certificate from the BSI. The aim of these requirements is to effectively protect patient data and ensure the trustworthy use of digital health applications.

The audit is carried out by recognized inspection bodies such as PwC, TÜV Informationstechnik or Secuvera.

Important for planning:

• Lead time for test centers: several months in our experience
• Inspection itself: structured process with inspection report and, if necessary, improvements

After a successful test, the result is sent to the BSI and the certificate is issued.

👉 Important for you: The security requirements not only affect individual functions, but the entire architecture – especially authentication, logging and data processing.

Before you go into individual components, one question is crucial:

👉 Welche Systeme musst Du von Anfang an mitdenken?

In practice, it shows:

• Backend & Auth are always necessary
• Billing is mandatory for operation
• Consent management is critical from a regulatory perspective
• TI/ePA/GID are dependent on the use case, but should be considered early on

👉 The biggest mistake: starting too late with backend, security and processes.

In practice, a DiGA consists of several specialized systems:

• Backend (data, logic, APIs)
• Authentication service
• Consent and protocol system
• Billing system
• optional: TI/ePA/GID integration
• Monitoring & security infrastructure

The following building blocks form the basis.

The statutory health insurance company provides an API definition for billing purposes.

The typical procedure:

1. Health insurance company creates activation code
2. User enters code in the DiGA
3. Validation via checkout API
4. Access is enabled
5. Billing data record is generated

The important thing is:

• Billing data must be stored separately
• Activation codes must not be mixed with user accounts
• The manufacturer defines the usage logic of the codes

👉 Practical consequence: You need a backend with cleanly separated data areas and a stable API connection to the health insurance companies. You can find more information on DiGA billing here.

Eine DiGA benötigt Benutzerkonten mit sicherer Authentifizierung. These include:

• pseudonyme Nutzung
• Two-factor authentication (the BSI lists which 2FA methods are possible and sufficiently secure here)
• Central authentication logic
• Complete logging of security-relevant events

No personal data may be disclosed before logging in – especially when registering or resetting a password.

👉 Practical consequence: A central auth service (e.g. based on OAuth 2.0 / OpenID Connect) is essential.

The manufacturer must be able to prove at any time which user consents have been obtained. Changes to personal data must be logged. Users should be able to view this log in the DiGA and revoke consent directly in the application.

• Changes to the GTC or privacy policy must be announced at least 14 days in advance and require renewed consent.
• Users must be informed 14 days before the expiry of the DiGA Regulation so that they can prepare for the deletion and export of their data.

Practical consequence: You need a service for storing and managing consent, audit-proof logging and a reminder or notification function.

For export to the electronic patient file, data is transferred as MIO in XML format (FHIR-based).

To connect to the telematics infrastructure, access to corresponding components is required, such as a connector, card terminal and a DiGA-specific SMC-B card. Communication takes place via defined interfaces, which are connected via a so-called primary system.

Clear framework conditions apply to exports:

• Write access to the ePA only
• Regular exports
• Document ID required for updates
• Access only after approval by the user
• KVNr required (via GID)

👉 Practical consequence: You need MIO conversion, TI connection and a valid test setup.

Health insurance companies provide their policyholders with a secure digital identity as an alternative to the health card: the GesundheitsID (GID). DiGA must enable registration via this identity.

The technical implementation is specified by Gematik. User identification and authentication are based on OAuth 2.0 and OpenID Connect. The underlying identity management takes place via OpenID Federation and is referred to as TI Federation in the context of the telematics infrastructure.

Each health insurance company operates its own identity provider to authenticate its policyholders. Applications that wish to use this authentication must act as a so-called specialist service that acts as a relying party in the sense of OpenID Connect.

The health insurance number (KVNR) may only be obtained via the health ID and is earmarked for a specific purpose, for example for export to the electronic patient file. The claims required for this must already be stored when registering the specialist service.

For implementation, this means that a separate web service must be operated as a specialist service within the TI federation. The GID login will be integrated into the DiGA and interlinked with the existing authentication system.

👉 Practical consequence: You need your own specialist service and must integrate the GID login properly into your existing authentication.

DiGA must check at startup whether security-critical updates are available. If this is the case, the application may no longer process any sensitive data until the update is installed. This requires a mechanism that recognizes updates and restricts the use of the application if necessary.

After expiry of the prescription period, user data may remain stored for a maximum of three months in a so-called grace period in order to enable a possible follow-up prescription.

Storage beyond this period requires the express consent of the user. If this is not the case, the data must be deleted when the prescription expires. Users must also be able to decide whether to continue using the existing account or create a new account for a subsequent prescription. In the case of a new account, the existing account must be deleted.

In addition, the DiGA must provide functions for blocking accounts, for example in the event of the loss of an end device, as well as processes for restoring or issuing new access data. It must be ensured that only legitimate users are granted access.

The backend of a DiGA requires a central logging and monitoring system. All relevant system components must record events and make them centrally analyzable. Suspicious activities should be detected automatically and corresponding alarms triggered.

Access to these systems must be secured by role and rights management.

A robust backup and recovery concept is also required. In particular, scenarios such as a ransomware attack must be taken into account. Backups containing personal data must be stored in encrypted form.

The handling of cryptographic procedures is based on the specifications of BSI-TR-02102-1 and BSI-TR-02102-2. In addition, the DiGA should use certificate pinning to increase the security of communication connections.

Cybersecurity is not an isolated aspect, but must be integrated into the architecture, operation and technical protection measures throughout.

The implementation of a DiGA is complex – from TI connection and backend architecture to security and certification requirements.

BAYOOMED supports you with many years of DiGA experience, its own TI services and tried-and-tested solutions for central components such as ePA integration, GID login and billing. We also rely on tried-and-tested processes and a strong partner network when preparing for examinations and working with inspection bodies.

👉 If you want to implement your DiGA efficiently and safely, talk to us.