Attention manufacturers of electronic aids, implants and DiGA!
Starting in mid-2027, a new legal requirement will take effect that is intended to improve interoperability between medical devices and digital health applications (DiGA) approved by the BfArM: Section 374a of SGB V
Specifically, this involves the implementation of an interoperable backend-to-backend interface. You can find out exactly what this means and what you need to know about it in this article.
Table of Contents
- 1. Short on time? The most important facts in brief
- 2. Overview of Section 374a SGB V
- 3. What medical device/implant manufacturers must do now
- 4. What DiGA manufacturers must do
- 5. Conclusion: Visions and limitations
1. Short on time? The most important facts in brief
- Starting in 2027, Section 374a of SGB V is intended to ensure that data from the backends of assistive devices and implants can be transferred to a digital health application (DiGA) in an interoperable format. This applies to all products covered by statutory health insurance.
- The law is intended to create greater openness between aids/implants and DiGA, which should give DiGA access to more data sources in the future.
- Since the revision of the DigiG, the Competence Center for Interoperability in Healthcare has been responsible for establishing the relevant technical specifications for this interoperable data transfer. The specification, originally developed by the KBV as the DiGA Device Toolkit, is currently on hold (as of 2026).
- The new law could exploit the previously unknown potential of DiGA and significantly influence the design of future applications. Access to various data from aids and implants from different manufacturers means that these can also be used for the benefit of users.
- Overall, however, there are still a few factors that are slowing down these visions – for example, the fact that only a few assistive devices/implants currently send data to a backend and the restriction to assistive devices and implants that are reimbursed by statutory health insurance companies. There are usually no refunds for many products (e.g. weight scales, fitness trackers, etc.).
2. Overview of Section 374a SGB V
(1) Medical devices or implants that are provided to insured persons at the expense of statutory health insurance and that electronically transmit data about the insured person to the manufacturer or third parties via publicly accessible networks must, as of July 1, 2027, allow the data processed by the medical device or implant, including data in aggregated form, can be transmitted — based on the insured person’s consent — in suitable interoperable formats to a digital health application listed in the directory pursuant to Section 139e(1) and further processed there, provided that the data is required by the digital health application for its intended use by the same insured person.
To this end, the manufacturers of assistive products and implants in accordance with sentence 1 must offer interoperable interfaces and open these for the digital health applications that are included in the list in accordance with Section 139e. Interference with the aid or implant by the digital health application is not permitted and must be technically ruled out.
The interoperable formats according to sentence 1 are in the following order:
- Specifications for the content of the electronic patient file in accordance with § 355,
- Standards and profiles that have been published on the platform pursuant to Section 385(1), second sentence, item 5, and have been made mandatory by the Federal Ministry of Health pursuant to Section 385(2), first sentence, item 1,
- open internationally recognized standards or
- disclosed profiles based on open, internationally recognized standards for which an application has been filed to include them on the platform pursuant to Section 385(1), second sentence, item 5.
[…]
2.1 Why all this?
The intended benefit of §374a SGB V is to increase the efficiency of DiGA through access to more data sources. The overall aim is to create greater openness on the market, as the law allows products from different manufacturers to be used in combination with a DiGA. The openness between DiGA and aids/implants is currently limited.
Although DiGA manufacturers must offer interoperable interfaces to external medical devices and disclose the standards and profiles used, there is no obligation on the part of the aid and implant manufacturers to use these interfaces.
In most cases, these interfaces also refer to offline connections such as Bluetooth. Interoperability between different backends in which data is stored is currently rare.
The aim of §374a SGB V can be explained very well using the example of diabetes:
Increasingly, apps are also being developed for diabetes aids that store and visualize the relevant data for those affected. As a result, many manufacturers are currently developing their own apps that are only compatible with their own devices.
So let’s imagine that a patient uses a glucose meter with a corresponding app as a digital diabetes diary. The patient also has an insulin pump from another manufacturer, which also transmits data to an app.
In this case, the patient is forced to use two different apps that cannot interact with each other in a meaningful way, as data import into the other app is not supported. However, both apps store the data in their own backend – so wouldn’t it make sense to merge this data? This is precisely where §374a SGB V is intended to achieve an improvement in future.
This could also mean that DiGA manufacturers can fall back on devices that are already available and do not have to offer their own products (compatible with the DiGA).
The manufacturer of the device is to be obliged to offer data transfer in DiGA, which means that data from devices from different manufacturers can be processed in a single app.
2.2 Who does the new law apply to?
It is relatively easy to find out whether the requirements of Section 374a SGB V apply to you as a manufacturer of medical aids or implants. As mentioned in the legal text, this is the case if the following criteria apply to you:
- The costs for your product are covered by statutory health insurance.
- Your product sends data about the user to you (the manufacturer) or third parties via publicly accessible networks (e.g. Internet)
Important: According to the DVPMG, this does not refer to a Bluetooth connection, for example. In general, the regulation applies to “[…] devices and implants that transmit data electronically and are accessible to the manufacturer or third parties via the Internet […]”.
The requirements must be implemented by the affected manufacturers no later than July 1, 2027. An exception applies to medical devices and implants that are necessary for medical reasons or without which the regular care of insured individuals could not otherwise be guaranteed — since, of course, harm to patients must be prevented.
2.3 What is a digital health application?
A digital health application (DiGA), or “prescription app,” is a mobile or web application that qualifies as a low-risk medical device and has been approved by the BfArM. Examples of this include diabetes diaries or digital psychotherapy courses.
For a more detailed definition of DiGA, read our article on this topic: Is your app a DiGA? Definition criteria of digital health applications
2.4 What does interoperability mean?
You can’t use an envelope to make a phone call or send a meaningful text in Spanish to your English-speaking girlfriend. Interoperability generally describes the ability of systems to work together.
To do this, it is of course necessary to agree on common communication channels and a language in advance. Roughly speaking, the aim of Section 374a SGB V is to ensure that all affected aids and implants speak the same language as the DiGA.
In future, the aim is to ensure that data from both backend A and backend B can be transferred to a DiGA and processed further. Read more about interoperability in our detailed article on the subject: Interoperability in medicine: explained using simple examples
At this point it is important to emphasize once again that we are talking about the interface between the backend of the aid/implant and the backend of the DiGA – i.e. when you transfer data about the user in any form via the Internet.
Data transmissions via cable or Bluetooth, for example, are not affected by §374a SGB V. To control a DiGA via such an interface, ISO/IEEE 11073 is your first port of call. DiGA manufacturers are also obliged to offer an open interface outside of the backend if they read in data from external devices. Read more about this here: Interoperability for digital health applications (DiGA)
The MIO DiGA Device Toolkit is intended to serve as an interface
To implement the interoperable interface between DiGA backends and assistive devices/implants, a medical information object (MIO) is currently being planned: The DiGA Device Toolkit. However, according to the version of Section 374a of SGB V as amended by the Digital Act in 2024, the legally binding technical specifications for data transmission are established by the Competence Center for Interoperability in Healthcare.
This is a requirement of the KBV, which is intended to ensure standardized interfaces, particularly in the ePA and DiGA areas. However, work on the DiGA Device Toolkit is currently on hold (as of 2026) because the technical specifications required under Section 374a(4) of SGB V have not yet been finalized.
3. What medical device/implant manufacturers must do now
What you can already do today is to evaluate whether you store your users’ data in a backend or transfer it to third parties.
If this is the case, you should begin working on the implementation of the interoperable interface at an early stage, as this will certainly take some time. Even though the DiGA Device Toolkit has not yet been finalized and is currently on hold (as of 2026), the implementation can already be planned and its implications evaluated. Furthermore, since the amendment to Section 374a of the German Social Code, Book V (SGB V), the Federal Institute for Drugs and Medical Devices (BfArM) has been establishing an electronic registry for the interoperable interfaces of medical devices and implants, to which manufacturers must report their interfaces.
Theoretically, not all data from the aid/implant must be transferable to the DiGA backend – because the law is limited here to the data required by DiGA “for the intended use”.
However, caution is advised here, as you have no influence over which data will be “used” by future DiGAs, which is why you are definitely on the safe side if you offer interoperable data transfer for all data.
Feel free to contact us if you need further expertise in this area or support with implementation.
3.1 What you do not have to do
If you are not currently saving or transferring data via a backend, this can remain the case in the future. In this case, you do not need to expand your system to enable interoperable data exchange with DiGA.
4. What DiGA manufacturers must do
Section 374a SGB V does not entail any further obligations for DiGA manufacturers. The regulation is negligible, especially for DiGAs that do not receive data from external devices.
However, new possibilities will open up in the future for all applications that require data from external devices for their intended use. The law could soon make this data more easily accessible.
The idea is that you no longer need to offer your own hardware devices for your application, as the app is compatible with comparable devices that are already available on the market from other manufacturers.
The interoperability requirements for DiGA can be found in this article: Interoperability for Digital Health Applications (DiGA)
5. Conclusion: Visions and limitations
The idea of processing as much health data as possible in one place and relating it to one another has been around for many years. The idea that diabetes apps will not only be able to access glucose readings in the future, but also data from body weight scales, fitness trackers, CGM sensors or insulin pumps, for example, is almost limitless.
This enables previously unknown improvements in healthcare, because the more data (sources) a DiGA has at its disposal, the more efficiently it can support its users.
For example, signs of deteriorating health can be recognized early and recommendations for action can be made in good time.
In theory at least. After all, a healthcare market in which all manufacturers work together and design their systems to be open to others is still (far) in the future.
The extent to which visions of this kind can be pursued remains to be seen, as Section 374a SGB V only has a comparatively narrow area of application. Many of the devices used by patients today are not, or only rarely, reimbursed by statutory health insurance companies and are therefore not affected by the law.
BVMed also criticizes the fact that manufacturers often do not know which devices were paid for by whom, as they lack information about the patients. In theory, the interoperable interface only has to be available as soon as a statutory health insurance fund has covered the costs. However, such proof is impractical. In addition, a slightly longer implementation period would have been desirable. This request has since been addressed by the Digital Act. The deadline has been extended to July 1, 2027.
Another limitation of Section 374a SGB V is that only a few devices currently transfer their data to a backend of the manufacturer or a third party – data transfers do not take place online, but via Bluetooth, for example.
Find out more about interoperability in medicine in general or the specific requirements for DiGA.
