Outline

Manufacturers of digital health applications (DiGA) will in the future have to comply with various obligations in the context of telematics infrastructure (TI). The present guide aims to assist DiGA manufacturers in implementing the TI use cases by providing all necessary information in a consolidated and clear manner. In particular, it is intended to:

• Describe the TI use cases and their implementation by DiGA manufacturers,
• inform about DiGA-relevant specification documents from the gematik,
• inform about existing possibilities for setting up access to the telematics infrastructure, and
• clarify existing possibilities/offers to test the TI use cases.

Following a comprehensive review of all the Telematics Infrastructure (TI) use cases in the context of Digital Health Applications (DiGA), this document will particularly emphasize two mandatory use cases. The first is the uploading of DiGA data into the Electronic Patient Record (ePA) by the DiGA manufacturer. The second focuses on the integration of digital identities (HealthID) provided by the health insurance companies for the insured individuals.

The TI Ecosystem in the Context of Digital Health Applications

Under the Digital Health Applications Regulation (DiGAV), manufacturers of DiGAs are mandated to transfer data from the DiGA into the Electronic Patient Record (ePA) at the user's behest. If the user gives authorization, treating healthcare providers can view the relevant DiGA data from their familiar primary system without needing to operate an additional, DiGA-specific interface. The data should ideally be entered into the ePA in the form of a DiGA-MIO, as specified by mio42 GmbH, although it can technically also be stored as a PDF. Given that the current protocol only allows data entry into the ePA from the DiGA backend via access to the closed network of the Telematics Infrastructure (TI) – essentially, via a connector used in conjunction with a unique SMC-B DiGA smart card  (smart card that uniquely identifies a participant of the TI) – DiGA manufacturers must equip themselves with the necessary components to implement this use case.

DiGA manufacturers are also obliged to enable registration to the DiGA via the digital identities of the insured people (HealthID) provided by the health insurance companies. The HealthID is intended to become a central access point to applications in the healthcare system, with so-called identity providers of the health insurances taking over the secure authentication of users for the application. DiGA manufacturers are required by the DiGA regulation to meet high security requirements in relation to user authentication and to prove this in the future by presenting a data security certificate. The identity providers of the health insurances meet the highest security requirements in relation to the identification and authentication of users and provide DiGA manufacturers with the health insurance number (KVNR) necessary for writing into the ePA in a secure manner. However, creating a HealthID is voluntary for insured people, so DiGA manufacturers must also implement their own authentication procedures (see chapter 3.4.4 "Identification and Authentication" of the DiPA guide (link)).

In addition, the gematik, in cooperation with the GKV-Spitzenverband and DiGA manufacturer associations, specifies the digital DiGA prescription. Currently, DiGA prescriptions must be submitted by the patient to their health insurance company to receive an activation code, which then must be entered into the DiGA. According to data from the GKV-Spitzenverband from 2022, almost 80% of prescriptions were redeemed in the period from September 2020 to September 30, 2022. The digital DiGA prescription aims to make the prescription and redemption process free of disruptions and quick. Currently, the regulation is still in conception and is therefore not part of this guide.

Considering that DiGA manufacturers must connect to the TI with the appropriate components for writing data into the ePA, the technical prerequisite for using a TI messenger, as well as the secure communication procedure KIM, is certainly met. However, the DiGAV currently does not mandate this, and therefore, these use cases are not part of this guide.

Writing a DiGA-MIO/PDF into the User's ePA

The DiGAV obliges DiGA manufacturers in §6 paragraph 1 to adapt their systems in such a way that the data processed by the digital health application can be transferred to the insured person's electronic patient record with the consent of the insured person. The ePA record systems provided by statutory health insurance providers and in the future also private health insurance companies are located in the closed network of the TI. To access this network, DiGA manufacturers need an institution card (SMC-B DiGA) that uniquely identifies the DiGA manufacturer to the telematics infrastructure and initially grants them writing rights in accordance with § 341 paragraph 2 no. 9 SGB V. This SMC-B must be connected to a connector via a card terminal, only then can the DiGA manufacturer write data into the user's ePA via defined interfaces of the connector. The challenge for DiGA manufacturers is to integrate the TI components into their IT infrastructure. This chapter is intended to support the implementation of the use case.

Implementation of the use case

For the implementation of the use case, two basic steps are necessary:

1. The user must authorize the DiGA in their ePA frontend for data transfer. For this step, no adjustments to the systems of the DiGA manufacturers are necessary.
2. The DiGA manufacturer cyclically or event-based inserts the supply-relevant DiGA data in the form of a MIO or PDF into the user's ePA. For this step, adjustments to the systems of the DiGA manufacturers are necessary.

Authorization of data transfer by the user

Before DiGA manufacturers can even place data in the user's ePA, it is absolutely necessary for the user to authorize the DiGA to write in their ePA. Without prior authorization from the user, no data upload is possible and the corresponding request will result in an error. The authorization can be granted by the user specifically for DiGA in the ePA frontend or ad hoc for DiGA in general at a card terminal in the service provider institution (document category "DiGA" in the ePA, see gemSpec_Dokumentenverwaltung Chap. 5.4 Zugriffsregeln).

The user can only authorize the DiGA when the gematik, as the issuer of the SMC-B DiGA (see chapter Implementation options for TI access), has entered the DiGA manufacturer in the gematik directory. This happens immediately after the SMC-B DiGA has been delivered to the DiGA manufacturer. Only then can the user find the corresponding DiGA in his ePA-Frontend and grant the corresponding authorization. When the user grants authorization, a DiGA-specific folder is created in the user's ePA record system, into which the supply-relevant DiGA data can subsequently be stored.

The described functionalities/mechanisms have already been implemented by the record system providers and health insurances, so no technical adjustments are necessary on the part of the DiGA manufacturers for this partial step.

Data Upload

Provided that the user has authorized the DiGA to write to his ePA and thus the DiGA-specific folder in the ePA record system has been created, the DiGA manufacturer can place and/or replace care-relevant DiGA data in the user's ePA. This requires 3 or 4 steps:

(1) Calling up the ePA-specialist-module in the connector

Connectors have so-called specialist modules for various products of the telematics infrastructure, which encapsulate specific functionalities of these TI products. The first step to upload a document in the ePA is therefore to call up the ePA specialist module in the connector. For this, the corresponding endpoint must be determined. (see  ePA-Implementierungsleitfaden für Primärsysteme (gemILF_PS_ePA) chapter 4.2 Dienstverzeichnisdienst).

(2) Find the user's file

It then needs to be determined which file provider the user's file is with. For this, a request with the health insurance number (KVNR) of the user must be made to the connector, which returns the file provider in the form of the so-called HomeCommunityID. The HomeCommunityID should - as long as the user wants to write data into the ePA - be stored together with the KVNR, which simultaneously represents the file ID, to save the (time-consuming) determination of the HomeCommunityID for a new data upload. (see Implementierungsleitfaden Primärsysteme ePA (gemILF_PS_ePA) chapter 5.1.1  Aktenanbieter ermitteln, reference request on GitHub: link)

(3) Post document

With the KVNR (= file-ID) and the HomeCommunityID as well as the authorization granted by the user, documents can now be uploaded into the ePA. To place a DiGA-MIO or a PDF document in the identified ePA of the user, a request according to IHE standard according to chapter 5.2.1 of the implementation guide primary systems ePA (gemILF_PS_ePA) must be made to the connector. General metadata requirements can be found in the ePA data model (gemSpec_DM_ePA) chapter 2.1.4 usage guidelines for IHE ITI XDS metadata. Here, the same general requirements for primary systems apply to DiGA. Metadata requirements to identify a DiGA-MIO can be found as a reference on GitHub (link). A reference request for the insertion of a U-Heft-MIO is also available on GitHub (link). In the near future, reference requests for the insertion of a DiGA-MIO/PDF will also be published on GitHub.

(4) Update/replace document

A previously posted ePA document can be replaced by adding the existing DocumentID (DocumentEntry.entryUUID) to the request required under (3). This must be persisted by the DiGA manufacturer, as currently no read access is possible (see A_23131 in gemILF_PS_ePA chapter 6.4.4 Daten digitaler Gesundheitsanwendungen).

If no DocumentID is provided, a new document is stored in the DiGA folder of the user's ePA and the responsibility to open the relevant or most recent document lies in the primary system.

Implementation options for TI-access

As described earlier, it is necessary for the ePA use case that DiGA manufacturers equip themselves with TI access components. Specifically, the following components need to work together for TI access:

• SMC-B DiGA: Physical institution card, which identifies the DiGA manufacturer against the TI and authorizes this to write into the ePA
• Card terminal: Carrier of the SMC-B
• Connector: Physical component that encapsulates access and ePA functionalities in interaction with card terminal and SMC-B

Addressing Connector Interfaces

Currently, there are two ways to implement a TI access in the market. Firstly, a manufacturer can operate a single-box connector in an environment for which they are responsible, which communicates with an SMC-B in a card terminal. The other, and usually more comfortable option for DiGA manufacturers due to their IT infrastructure, is to realize the TI connection via a TI-as-a-Service provider.

TI-as-a-Service providers host connectors and secure operations for the DiGA manufacturer. They address the necessary connector interfaces for the TI use cases via a secure VPN connection. In this model, manufacturers usually pay a one-time connection fee and a monthly flat rate. The integration of the SMC-B in this model should be individually coordinated with the TI-as-a-Service provider, depending on the individual IT infrastructure of the DiGA manufacturer.

From autumn 2023, there will be a new type of access in the form of a TI gateway, which allows DiGA manufacturers to forego the integration of their own physical connector, similar to the TI-as-a-Service offer (link).

SMC-B Issuance

According to § 351 para. 3 SGB V, the gematik is the card issuer for SMC-B DiGA. DiGA manufacturers can apply for SMC-Bs via the application portal of d-trust, the card provider of gematik (link). The BfArM will confirm to the gematik that the applicant is entitled to receive an SMC-B. An application for the SMC-B DiGA is only possible after successful listing in the DiGA directory. 

Testing Opportunities/Offers

DiGA manufacturers currently have the opportunity to test data upload to an ePA in the so-called TI reference environment (RU). There are basically 2 different ways to access the RU:

1. Hiring an "enabler" who provides you with all the necessary components and services, as well as further (individual) services for accessing the RU "from a single source"
2. Procurement of all the necessary components and services for accessing the RU (connector, card terminal with SMC-KT, test cards, VPN access to the RU)

It is recommended for DiGA manufacturers to obtain RU access via an "enabler" as a service, as the procurement and integration of the TI access components is much more complex to implement due to the IT infrastructure of the DiGA manufacturers.

RU-as-a-Service (Enabler)

For the ePA tests in the RU, a test insurance card (eGK) and a test institution card (SMC-B) are needed, among other components. Both test cards can be obtained via an enabler. The enabler can also have a file account set up for the insurance card and have permission granted for the institution card. Further information on RU-as-a-Service providers can be found here.

Connectathons

The gematik regularly offers so-called Connectathons, in which DiGA manufacturers can test end-to-end use cases with file system manufacturers and health insurance companies in the reference environment. Further information and registration opportunities can be found here.

DiGA MIO Toolkit

The mio42 GmbH has specified a DiGA MIO Toolkit. All relevant information on this can be found here.

Registration at DiGA with the HealthID

From January 2024, DiGAs must offer a registration via the digital identities (HealthID) provided by the health insurance companies. This is stipulated in Annex 1 to the DiGAV in the data security category as item 15a. From mid-2023, a so-called federation of sectoral Identity Providers (IDP) will be gradually established according to the OpenID Connect standard. The sectoral IDPs manage the entire life cycle of the insured individuals' identities and, after successful authentication of the insured individual, provide identity confirmations to applications like a DiGA. Therefore, DiGA manufacturers can delegate user authentication to the IDP federation. After the authentication, they receive a DiGA- and user-specific pseudonym or, exclusively for writing care-relevant DiGA data into the user's ePA, the KVNR.

User management and authorization is not a feature of the IDP federation and remains the responsibility of the DiGA manufacturer.

Further information on the IDP federation can be found in the IDP Knowledge Database of the gematik (Link).

Implementation of the Use Case

DiGA are "Fachanwnedungen" (Relying Parties) in the sense of the IDP-Federation. All relevant information for "Fachanwendungen" in the IDP-Federation is bundled in the IDP knowledge base: Fachanwendungen der TI-Föderation

To integrate the HealthID/TI-Federation, the following specific steps are necessary:

1. Implementation of the HealthID in the test/reference environment:

First, the Health ID/TI-Federation must be integrated into the test/reference environment. TI-Federation professional services can use reference implementations and environments provided by the gematik for interoperability testing of their application. Information on this can be found in the IDP knowledge database: Fachdienste Test-Umgebungen.

As shown on the linked page, for some integration tests, it is necessary to register the Authorization Server of the DiGA in the TI-Federation. Only then will the professional service be recognized as a participant in the federation by all sectoral IDPs in the federation. Details on registration in the test/reference environment can also be found in the IDP knowledge database: Registrierung eines Fachdienstes in der TI-Föderation (für die Testumgebung (TU) und/oder Referenzumgebung (RU))  

As also described on Fachdienste Test-Umgebungen, the reference implementation of the gematik sectoral IDP is located in a restricted access network of the gematik. For this reason, the outbound IP of the DiGA manufacturer must be on the gematik's allowlist, or alternatively, the DiGA manufacturer must use an X-Auth header in their requests. This will be communicated by the gematik upon request at diga@gematik.de.

If an ID token issued by a sectoral IDP can be successfully decrypted, then the authentication process in the test environment has also been successfully completed. The final tests should not be performed against the gematik sectoral IDP with its GSIA app, but against a sectoral IDP approved by the gematik and its authenticator app in the test environment. Since the sectoral IDPs of the health insurance companies are still in the approval process, not all sectoral IDPs of the companies are registered in the test environment yet. It is also not currently possible to gain access to the authenticator apps of the IDP-providers. Further information will follow.

2. Confirmation as DiGA in the TI-Federation by the gematik 

Once DiGA manufacturers have successfully tested the HealthID and retrieved an ID token, they must be confirmed by the gematik as DiGA in the TI-Federation. According to §327 SGB V, confirmation by the gematik is required when components or products of the TI are used by additional applications. The goal is to ensure that the manufacturers meet the requirements specified by the gematik and maintain them for the duration of the confirmation. 

The requirements a DiGA manufacturer must meet are summarized in an application profile (Anwendungssteckbrief). This is currently awaiting approval by the shareholders' circle of the gematik and will be published soon with all further information on the application and the fees incurred for the confirmation. The manufacturers will have to provide evidence of the met requirements through self-declarations during the confirmation process. The gematik itself will not test implementations of DiGA manufacturers. Information on this will be added here in this guide as soon as it is available.

3. Proof of successful integration of the HealthID to the BfArM

In coordination with the BfArM the confirmation issued by the gematik in step 2 is to serve as proof of the implementation of the Health ID to the BfArM. The BfArM will define a transition period in 2024 during which the evidence should be submitted to the BfArM. The gematik is in close contact with the BfArM to allow DiGA manufacturers enough time for implementation. Further information on this will be published by the BfArM shortly.

4. Registration of the DiGA in the productive TI-Federation after successful listing in the DiGA directory

After DiGA manufacturers have demonstrated successful integration of the Health ID to the BfArM through the confirmation issued by the gematik, they will be listed in the DiGA directory - provided all other requirements of the BfArM are met. After successful listing, the DiGA manufacturer can be registered in the (productive) TI-Federation. Since the sectoral IDPs of the health insurance companies will only be rolled out from January, registration of DiGA in the TI-Federation will also only be possible from January. This approach is coordinated with the BfArM. Further information on the registration application will follow soon.