Attention manufacturers of electronic aids, implants and DiGA!
From mid-2024, a new legal requirement will apply to improve interoperability between medical devices and digital health applications (DiGA) approved by the BfArM: §374a 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.
Short on time? The most important facts in brief
- From 2024, Section 374a SGB V is intended to ensure that data from the back ends of medical aids and implants can be transferred to a digital health application (DiGA) in an interoperable format. This applies to all products that are reimbursed by statutory health insurance companies.
- 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.
- In order to implement this interoperable data transfer, the DiGA Device Toolkit is currently being developed by the KBV.
- 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.).
An overview of §374a SGB V
(1) Devices or implants that are supplied to insured persons at the expense of statutory health insurance and that transmit data about the insured person electronically to the manufacturer or third parties via publicly accessible networks must, from July 1, 2024, enable the data processed by the device or implant to be transmitted in suitable interoperable formats to a digital health application included in the directory pursuant to Section 139e (1) and further processed there on the basis of the insured person’s consent, provided that the data can be processed by the digital health application for the intended use by the 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,
- recommended standards and profiles in the interoperability directory according to § 385,
- open internationally recognized standards or
- disclosed profiles via open, internationally recognized standards whose inclusion in the interoperability directory has been applied for in accordance with Section 385.
[…]
Why all of 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.
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: a Bluetooth connection, for example, is not meant here according to the DVPMG. In general, the regulation concerns“[…] aids and implants that transmit data electronically and are available to the manufacturer or third parties via the Internet […]”.
The requirements must be implemented by affected manufacturers by 07/01/2024 at the latest. There is an exception for aids and implants that are necessary for medical reasons and for which there is no alternative – because harm to patients should of course be prevented.
What is a digital health application?
A digital health application (DiGA), or “app on prescription”, is a mobile or web application that qualifies as a low-risk class medical device and has been approved by the BfArM. Examples of this could be 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
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)
A medical information object (MIO) is currently being planned to implement the interoperable interface between DiGA backends and aids/implants: The DiGA Device Toolkit.
This is a stipulation of the KBV, which is intended to ensure standardized interfaces, especially in the ePA and DiGA areas.
What aid/implant manufacturers need to 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 deal with the implementation of the interoperable interface at an early stage, as this will certainly take some time. Even if the DiGA Device Toolkit has not yet been finalized today ( 04/21/2022), the implementation can already be planned and the effects evaluated.
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.
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.
What DiGA manufacturers need to 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)
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.
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.
