Have you developed an app that is already a medical device or are you planning to develop a DiGA from scratch? Then you will be faced with a variety of technical challenges that go far beyond pure app development. From the complex backend architecture for health insurance billing to secure authentication systems and integration into the telematics infrastructure – the technical requirements for a certified DiGA are extensive and demanding.

This guide systematically shows you which technical components you need for a successful DiGA implementation and which regulatory requirements need to be observed.

Statutory health insurance companies pay the DiGA manufacturer for every DiGA prescribed. Individual contracts must be negotiated with private health insurance companies. Approved DiGAs are then entered in the public register of the BfArM.

DiGAs are defined in SGB V § 33a. Requirements for DiGAs are defined in the DiGAV. Additional requirements of the BfArM can be found in the BfArM DiGA test criteria. BfArM tests and approves DiGAs.

Further BSI requirements in accordance with BSI TR-03161 – DiGAs require certification in accordance with BSI guidelines.

GKV provides a definition of the API, which has been implemented by all health insurance funds.

The DiGA activation and billing process works as follows: The activation code is created by health insurance companies and is written on the prescription. The patient downloads the DiGA from the store and enters the code in the DiGA. The DiGA has the code checked via the health insurance company API and grants access for use. The API then returns the billing data record.

It is important to know that billing data records come via the same API and must be stored in a separate database. The DiGA manufacturer is responsible for how often the same code may be used. A code must be stored separately from the user account and deleted once the DiGA has been activated. A hash of the code may be saved. The mapping directory of health insurance endpoints must be updated regularly on a quarterly basis.

Result: You need a backend system with databases with connections to the app and the APIs.

The DiGA must have a user account with authentication. The account must be usable under a pseudonym and there must be two-factor authentication.

Authentication is only implemented via verifiable, central components. Logging is mandatory for events such as identification, authentication and authorization. Log access must be secured by authorization management. The logs must be evaluated automatically in order to detect or proactively prevent security-relevant events. A login method must have an appropriate level of trust in accordance with BSI TR-03107-1. Other login methods can have a lower level of trust with the user’s consent.

It is important to know that DiGA must not disclose any personal data before a login. This must be taken into account especially in the case of forgotten passwords or registration processes.

Result: An auth service is needed, preferably according to OAuth 2.0 and OpenID Connect Standard.

The manufacturer must be able to prove user consent at all times and log changes to personal data. Users can view the log via DiGA and revoke consent directly in the DiGA.

Changes to the GTC or privacy policy must be announced to the user at least 14 days in advance and always require renewed user consent. Users must also be informed 14 days before the expiry of the DiGA Regulation that their data will then be deleted and that they can make an export.

Result: A reminder function or notifications are needed in the app. A service is needed to store user consents in the backend and provide logs.

Data export is only accepted in the form of an MIO (Medical Information Object). The data must be in XML format. MIOs are based on the FHIR standard. KBV provides FHIR resource definition of the MIOs.

The ePA can only be accessed via the telematics infrastructure (TI). Gematik GmbH is responsible for ePA and TI specifications.

Access to the TI is only possible with special hardware: connector, card terminal and DiGA-specific SMC-B card. Each DiGA is issued its own SMC-B, which must be permanently inserted into a card terminal. The connector offers SOAP interfaces and software that addresses the connector is called a primary system (PS) and must fulfill the corresponding Gematik requirements.

The DiGA must offer users automatic, regular ePA exports. A DiGA only has write access to the ePA. To update documents, the document ID must be saved. The user must first grant the DiGA access to their ePA via the front end of the insured person (FdV), e.g. the ePA app of their health insurance fund. In order to write to the ePA, the health insurance number (KVNr) is required, which DiGAs can only obtain via the GID login.

Result: An implementation is needed to convert health data into MIOs. It needs access to TI hardware, buy or rent as a service. It needs an implementation for the connector interfaces, the primary system. It needs a test setup with test users and their FdV app to test export to the ePA.

Health insurance companies must offer all insured persons a secure digital identity, known as a health ID (GID), as an alternative to a health card. DiGAs must enable registration with the GID.

The implementation of the GID is managed by Gematik. User identification and authentication is based on OAuth2.0 + OpenID Connect. Identity management is based on the OpenID Federation Standard and is called TI Federation. Each health insurance company provides an Identity Provider Service (IDP) for the authentication of insured persons. Every application that wants to authenticate insured persons must provide a so-called specialist service, which according to OIDC is called a Relying Party (RP).

It is important to know that DiGAs may only obtain the KVNr via the GID and only use it for the ePA export. This is requested by the specialist service/RP when registering with the IDP, as a so-called claim. Claims must already be entered in the RP registration form.

Result: A web service is needed that acts as a specialist service in the context of the TI Federation and as a relying party in the context of the OpenID Federation. The GID login must be implemented in the DiGA app. The existing auth service for the DiGA user login must continue to function and most likely be adapted for the GID login.

We have practical experience with TR-03161-compliant applications and have already developed a DiGA project entirely according to these standards. This expertise enables us to support you with in-depth know-how and identify typical challenges in advance.

In order to ensure the conformity of your DiGA, we provide support after an introduction to TR-03161 (if necessary) in the area of requirements management, in the creation of a gap analysis, in project planning and in the implementation and closure of existing gaps to TR-03161.