We would like to briefly introduce the topic of interoperability in DiGA development with a small example:
“Μια DiGA πρέπει να πληροί ορισμένες απαιτήσεις διαλειτουργικότητας.”
Do you understand this sentence? Unless you speak Greek, probably not. You therefore need an English translation. That would be your interoperability requirement for this blog article. If we implement this requirement, the sentence reads as follows:
“A DiGA must meet certain interoperability requirements.”
Just like this blog article, a DiGA must also be compatible with adjacent systems and its data exchange must follow specific rules: structural, syntactic, semantic, and organizational interoperability. You can find out what these terms mean here. Read on to gain practical insight into the implementation of interoperability requirements for a DiGA.
Overview
- 1. Interfaces between DiGA and other systems
- 2. Integration of Electronic Patient Records (ePA)
- 3. Digital Identity/Health ID
- 4. Conclusion
1. Interfaces between DiGA and other systems
Depending on the intended use and functional scope of a DiGA, it can have interfaces to numerous other systems. For example, a DiGA could read in data from Google Fit or Apple Health, transfer data on a clinical picture to the electronic patient record (ePA), or inform a treating doctor about a patient’s treatment progress. Not every interface has to be designed to be interoperable (e.g. with other apps). There are only legal requirements at three interfaces. These are described in more detail in the following chapter.
Interoperability for DiGA
(Excerpt from the DiGA Guide – Version 3.6)
1.1 Which interfaces need to be designed to be interoperable?
When you consider the core task of a DiGA, which is to optimize the quality of care for patients, it quickly becomes clear where interoperability is particularly important. The DiGAV specifies exactly which interfaces must be designed to be interoperable. Annex 2 to the DiGAV is particularly important for the implementation of the requirements.
Required interfaces for DiGA
To ensure care is provided, doctors, psychotherapists, and the patients themselves are of paramount importance.
1. A data export in human-readable, printable format must therefore be made possible.
However, not only people, but also other healthcare systems, such as the ePA, must be able to use the data from the DiGA in a meaningful way.
2. Data export in an interoperable format must also be made possible. Data is transmitted in accordance with a definition for semantic and syntactic interoperability. The KBV’s MIO DiGA toolkit is particularly important in this context, as it enables data to be transferred to the electronic patient record (ePA).
DiGAs that rely on data from sensors and other measuring devices, for example, must also create an interoperable interface here to enable hardware manufacturers to connect to the DiGA.
3. Therefore, an interoperable interface to wearables and other medical devices that can be used by different manufacturers to provide data is also mandatory.
1.1.1 Data export in human-readable, printable format
Patients and their healthcare providers must be able to understand and reuse the care-related data of a DiGA. For this reason, the DiGAV also requires this interface to provide data in a human-readable, printable format. It is important to note that the data export can be initiated via DiGA itself, but does not have to be carried out by DiGA.
A button that initiates the download of an encrypted data packet, which can later be accessed via a server, is also regarded as a legitimate implementation. An example of a data export in human-readable, printable format would be the creation of a PDF file containing all blood glucose readings from the DiGA and other relevant data.
The draft bill for the second amendment to the DiGAV dated October 28, 2025 also provides for the transfer of this human-readable export to the electronic patient record in the future.
QuickBird Medical Tip: Provide the relevant data in a compact and comprehensible form. Consider which data is useful in a care scenario in which the DiGA is used. What data is important for patients and doctors, and how can it be presented in a comprehensible way?
Apart from the legal interoperability requirements at this interface, you can gain a significant competitive advantage here. If your DiGA can be easily integrated into the everyday work of doctors and psychotherapists and delivers tangible added value, it will also be prescribed more frequently. The more compatible your DiGA is with existing healthcare processes, the better.
1.1.2 Data export in interoperable format (ePA)
Not only people, but also other systems are part of the healthcare system and want to continue using the data from your DiGA. First and foremost among these is the electronic patient record (ePA), which must be able to obtain data from the DiGA in an interoperable format. In order to meet the requirements of interoperability in the healthcare sector, it makes sense to agree on uniform standards that are used for data exchange. These standards are defined by standardization organizations and specify the format and semantics of data streams. An adaptation of a standard for a specific country or field of application is called a profile.
For precisely this reason, there are concrete specifications as to which formats are permitted for data export. It is not enough for your DiGA to simply provide certain data, the format is also crucial. As a DiGA manufacturer, you now have to start looking for a suitable data format, but where should you start looking?
- First, search for a medical information object (MIO) defined by the KBV from the DiGA Toolkit for each data element. This should generally cover your use case reasonably well. There are also more generic MIO profiles such as “Observation_Free” for this purpose.
- However, if there really isn’t a reasonably suitable MIO, you still have two options:
-
- You can use another existing open, internationally recognized interface or semantic standard (e.g. HL7 FHIR).
- You can define your own profile using one or more existing open, internationally recognized interfaces or semantic standards. This profile must then be published in a recognized directory (e.g. FHIR Registry) for free use.
Medical Information Objects (MIO) – DiGA Toolkit
A MIO is a data format for medical information defined by the KBV. With the primary goal of ensuring optimal data exchange between all systems involved in medical care, new MIOs are developed from time to time for various types of information. The interface to the ePA in particular is one of the main reasons for the introduction of MIOs.
The fact that manufacturers use a published interoperability standard is a good thing. At least the form of data exchange is transparent. Of course, it is even better if the selected standard also matches the standard of the ePA or other systems. A direct connection is therefore possible.
One example of an MIO is the electronic vaccination record. Its structure is precisely defined and stipulates that new vaccination entries must comply with a clear format in order to be integrated into the vaccination record. The MIO defines which information must be included and in which format it must be available.
The DiGA Toolkit, which was developed to implement the interoperability requirements for DiGA, is particularly interesting for DiGA.
What data must be taken into account for interoperable data export?
Theoretically, countless different types of data can be exported from an app. However, for interoperable data export, only data based on the intended use by users must be taken into account (see Section 4 (2) sentence 1 no. 1 DiGAV). Data for intended use is data that is required for purposes directly related to achieving medical benefits or patient-relevant structural and procedural improvements.
Specifically, this potentially concerns the following data:
- Data entered by the users
- Data collected via devices and sensors
- Data on the user and the context of use (if available)
- Information on DiGA and metadata for data export
The following data does not have to be exportable as separate objects:
- Derivations on recorded data that serve exclusively to ensure the safe operation of the DiGA.
- Statistical procedures based on the data, which are only stored to prove the positive supply effect.
1.1.3 Interface to wearables and medical devices
This interface is not available on all DiGAs and is therefore not relevant for all manufacturers. However, if medical devices or other wearables are involved in the function of the DiGA, interoperable data exchange must also be ensured at this interface. The reason for this is quite simple: it must be left up to the patient to decide which device he or she wants to use. This requires hardware manufacturers to be clear about the data format in which they communicate with the DiGA. This is the only way to develop devices that can also interact with the DiGA.
Requirements for hardware manufacturers
DiGA manufacturers have the following options for implementing interoperability at this interface:
- Use of a disclosed, documented profile of the ISO/IEEE 11073 standard (Medical Device Communication)
- Search for a health device profile specified by the BluetoothSIG.
- Use of an open, internationally recognized standard (e.g., HL7 FHIR) or corresponding profiles
- Definition of a custom profile based on open standards. This must be published in a recognized directory (e.g., FHIR Registry) for free use. The INA – Interoperability Navigator from gematik serves as a national reference and guidance tool.
QuickBird Medical Note: In addition to an interoperable interface, your DiGA may also offer non-interoperable interfaces. This may be the case, for example, if you need to integrate a wearable that does not offer data transmission in a corresponding format. You may maintain the interface to this device, but you must also create an interoperable interface for other devices.
Does a DiGA also have to offer an interoperable interface to devices whose data is imported via Apple Health or Google Fit? No, in this case your DiGA does not have to offer an interoperable interface to the device itself.
Manufacturers of medical devices and implants will also be required to ensure interoperability in the future. Medical devices and implants that send patient data to a manufacturer’s backend or a third party must offer an interoperable interface for DiGA from July 1, 2027. This should make it possible for DiGA to access data from different sources. Read more about this here: Guide to Section 374a of the German Social Code, Book V (SGB V) – Interoperability for digital health applications, medical devices, and implants
1.2 At which interfaces is interoperable design optional?
DiGAs can, but do not have to, offer an interoperable interface to all neighboring systems. For example, a DiGA can obtain data from other apps, such as Apple Health, without having an interoperable interface. Even direct data exchange between DiGA and other medical apps does not necessarily require an interoperable interface. Please refer to the illustration in the chapter “Interfaces from DiGA to other systems”. There you can see which interfaces of your DiGA do not need to be designed to be interoperable.
2. Integration of Electronic Patient Records (ePA)
The connection of the DiGA to the electronic patient record is a central component of the interoperability requirements. The aim is to make care-related data from the DiGA structured, standardized, and usable for other healthcare systems.
DiGA must enable the export of data to the ePA in an interoperable format. Both manual data transfer by the insured and regular automated transfer must be provided for. Automated transfer must be deactivatable at any time so that users always have both options available.
The technical implementation is based on the Medical Information Objects (MIO) defined by the National Association of Statutory Health Insurance Physicians, in particular the DiGA Toolkit, which specifies the semantic and syntactic requirements for data exchange with the ePA.
Proof of successful ePA connection in the reference environment is provided as part of a confirmation process carried out by gematik and is a prerequisite for the formal completeness of an application for inclusion in the DiGA directory at the BfArM. The BfArM also tests the connection as part of its review of the content of the DiGA application.
We are happy to assist you with the technical connection of your DiGA to the ePA. You can find more information about this service here.
3. Digital Identity / Health ID
In order to write to and read from the ePA, a DiGA must also implement user authentication with a digital identity (health ID). Even though this requirement does not formally fall under the topic of “interoperability,” it nevertheless represents another necessary interface to other systems in the healthcare sector.
A DiGA can request the patient’s health insurance number via the Health ID. This is a prerequisite for exporting to the ePA. Therefore, data can only be transferred to the ePA if the patient has linked their DiGA account to the Health ID. In addition, the patient must explicitly grant access to the corresponding DiGA within their ePA app.
We are happy to assist you with implementing the Health ID interface. You can find more information about this service here.
4. Conclusion
At first glance, interoperability in DiGA development is an opaque undertaking. However, upon closer examination, three key points can be identified:
- A person must be able to understand the data of a DiGA (human readable)
- Other systems (in particular the ePA) must be able to understand data from a DiGA
- Manufacturers of sensors and measuring devices need to know the format in which data is exchanged with the DiGA.
When searching for suitable interoperable file formats, the first places to look as a manufacturer are the KBV’s MIOs and, above all, the DiGA Toolkit.
Do you need help with the ePA connection or health ID?
As a specialized service provider, we have already been involved in the implementation of over 15 different DiGA projects. We are happy to support you with the implementation of all interoperability requirements (e.g. connection to the ePA). You can find more information about our ePA & Health ID service here.
If you have any further questions, please feel free to contact us using our contact form: Go to contact form
