Integrating GesundheitsID into a DiGA: Requirements, OIDC Federation and the BfArM Proof
Since January 2024, it has been mandatory for DiGA manufacturers to enable their users to authenticate via the GesundheitsID (Health ID). What sounds like a manageable "just another login method" turns out to be one of the more complex integration projects on the way to the DiGA directory – because behind it is not just an OAuth flow, but the entire sectoral identity federation of the telematics infrastructure (TI 2.0).
This article explains what the GesundheitsID is, why it is mandatory, how the integration works technically, where the real hurdles lie, and how you provide the proof required by the BfArM.
Why the GesundheitsID is mandatory for DiGAs
The legal basis is § 291 Abs. 8 SGB V in conjunction with the DiGA Ordinance (DiGAV). According to this, DiGA manufacturers must adapt their application so that statutorily insured persons can authenticate themselves with a digital identity – the GesundheitsID.
The background: The GesundheitsID is the digital identity of the insured in the telematics infrastructure. It replaces weaker methods such as SMS-TAN or pure password logins and enables a cardless, app-based access at the highest security level. For DiGAs, it is also the prerequisite for legally writing data to the electronic patient record (ePA): The patient's health insurance number (KVNR) can be requested via the GesundheitsID, and without this, an ePA export is not possible.
In short: Without a GesundheitsID connection, there is no listing in the DiGA directory of the BfArM – and thus no reimbursement by the statutory health insurance funds.
How the GesundheitsID works technically
The GesundheitsID is based on OpenID Connect (OIDC), the established industry standard for authentication. So far, so familiar. The decisive difference to a classic "Login with Google" is the federation:
- The gematik operates the central federation master, which determines which participants of the federation are trustworthy.
- The health insurance funds (Krankenkassen) each operate their own sectoral Identity Providers (IDPs), where their insured authenticate themselves.
- Your DiGA is the Relying Party (the service provider), which requests a login and ultimately receives verified identity attributes.
This means: Your app does not talk to one IDP, but must be able to dynamically handle many IDPs of different health insurances – and cryptographically prove to the federation master that it is a legitimate participant.
The real hurdles of integration
This is where "we already know OIDC" quickly becomes a multi-week special project. The biggest stumbling blocks:
Entity Statement and JSON Web Key Set (JWKS)
Every participant in the federation must provide an Entity Statement – a signed document that describes their own interfaces, endpoints, and supported methods. In addition, a JSON Web Key Set (JWKS) is required with the public keys used to verify your signatures. Both must be correctly generated, hosted, signed, and kept up to date.
Advanced OIDC Mechanisms
Beyond the core OIDC specification, the federation uses mechanisms like PKCE (Protection of the Authorization Code), PAR (Pushed Authorization Requests), and OIDC Federation. Exactly this interplay makes the protocol significantly more demanding than a standard OAuth flow – and is the most common source of error in in-house developments.
Certificate and Key Management
Trust in the federation relies on cryptographic certificates and keys that must be regularly rotated and renewed. An expired certificate means in doubt: users can no longer log in.
Tests in the gematik Reference Environment (RU)
Before going live, the authentication flows must be tested and proven in the Reference Environment (RU) of the gematik. This requires access to the RU as well as an app version that runs against the RU GesundheitsID.
Moving Specifications
The gematik specifications are continuously evolving (keyword TI 2.0). Anyone who integrates themselves must permanently track these changes – maintenance effort that does not disappear after the go-live, but remains.
The path to the BfArM Proof
For admission to the DiGA directory, you must prove to the BfArM that the GesundheitsID authentication works. The test procedure was recently switched to a self-disclosure (Selbstauskunft) – the proof is thus placed more heavily in the responsibility of the manufacturer, making cleanly documented and reproducible tests all the more important.
For productive operation and writing to the ePA, the SMC-B DiGA also comes into play – the institution card that can be requested via the d-trust portal after listing in the DiGA directory.
Make or Buy: In-house Development vs. GesundheitsID as a Service
At this point, every product team faces the same decision: build everything yourself or integrate a specialized service?
An in-house development means setting up OIDC federation, entity statement generation, JWKS hosting, certificate management, and RU tests yourself – and then permanently maintaining them with every gematik spec change. This ties up developer capacity, which is usually better invested in the actual core features of the DiGA.
The alternative is GesundheitsID as a Service: A service encapsulates the complexity of the federation behind a simple OIDC interface. Exactly for this purpose azuma mimoto was built – the Entity Statements are generated automatically via the developer portal, the certificate management runs in the background, and spec updates of the gematik are tracked without you having to change a line of code. Instead of investing months in the federation, you integrate a standard OIDC flow.
If you want to test early, you can do so in simulation mode at no cost and without RU access, and later go into production via a configuration switch. The technical details can be found in the Integration Guide for mimoto.
Step by Step: How to integrate the GesundheitsID
As a rough guide – regardless of whether you build it yourself or use a service:
- Clarify use case – Is pure authentication sufficient, or should it also be written to the ePA (KVNR retrieval, SMC-B DiGA)?
- Integrate OIDC Flow – Authorization Code Flow with PKCE and PAR, secured according to BSI guidelines.
- Provide Entity Statement & JWKS – signed, correctly hosted, with a rotation strategy.
- Test in the Reference Environment – Validate and document flows against the RU GesundheitsID.
- Prepare BfArM Proof – Compile self-disclosure and test proofs.
- Go Live – Request SMC-B DiGA, switch to production mode, set up monitoring.
- Permanently track Spec Updates – or outsource to a service that takes over this.
Frequently Asked Questions
Is the GesundheitsID mandatory for every DiGA?
Yes. Since January 2024, DiGA manufacturers must enable the authentication of their users via the GesundheitsID. It is a prerequisite for listing in the DiGA directory and for writing to the ePA.
How long does a GesundheitsID integration take?
For an in-house development, several weeks to months are realistic because federation, certificate management, and RU tests must be set up. Using a specialized service with a standard OIDC interface, an integration is usually feasible in a few days.
What does the integration of the GesundheitsID cost?
The costs vary greatly between in-house development and SaaS. Managed solutions for DiGA startups start in the low three-digit range per month – significantly below the six-digit initial effort and the ongoing maintenance effort of an in-house development.
Do I also need the ePA connection for the GesundheitsID?
Not necessarily for pure authentication – but if your DiGA is to write data to the ePA, you need the KVNR retrieved via the GesundheitsID as well as an SMC-B DiGA.
Are you currently building a DiGA and don't want to build the GesundheitsID integration yourself? Get a free Developer Access and test the connection in simulation mode – or discuss your concrete use case with our team.