The undetected trap? The black box of the new DiGA requirements
At medXteam, the focus is on clinical data. In this context, as CRO we not only carry out clinical trials with medical devices in accordance with MDR and ISO 14155, but also offer all other options and forms of data collection. This time the topic of the DiGA is again in this context. Data is also collected here. But this time the focus is on the question: What potential challenges lie behind the DiGA requirements for manufacturers?
Abbreviations
BSI Federal Office for Information Security
DiGA Digital Health Application
ePA Electronic patient record
KBV National Association of Statutory Health Insurance Physicians
MDR Medical Device Regulation; EU Regulation 2017/745
QMS quality management system
Underlying regulations
EU Regulation 2017/745 (MDR)
Medical Device Implementation Act (MPDG)
ISO 14155
ISO 27001
DiGA Guide V3.4
Digital Supply and Care Modernization Act (DVPMG)
EU Regulation 2016/679 (GDPR)
Technical Guideline TR -03161
1 Introduction
DiGAs (Digital Health Applications) have become increasingly important as digital applications in healthcare in recent years. They can help improve medical care and facilitate access to healthcare services. They provide patients with the ability to monitor their health and manage disease while providing doctors with valuable data to make better decisions.
However, in addition to the opportunities for patients and medical staff, the regulatory context of DiGAs also presents challenges for the manufacturers of these products. Numerous requirements have already been defined, which must be implemented by manufacturers within certain deadlines and documented with appropriate evidence. Due to these requirements, which we will examine in more detail in this article, manufacturers are faced with, among other things, the key question of classifying their medical software product. While most DiGAs are currently classified as Class I products, a higher classification may result from the implementation of the new requirements. This is not just a fundamentally regulatory issue, the certification of the quality management system (QMS), the resulting cost and time issues as well as the argument to investors also form important pillars of this consideration.
If we take into account the debate in our last blog post about why doctors are primarily reluctant to prescribe DiGAs, the question arises as to how the immense challenges will relate to the potential benefits of digital applications in the future.
2. Regulatory requirements for DiGA manufacturers
As a DiGA manufacturer, it is currently necessary to implement some requirements as part of product development and internal company processes. The following chapter highlights both the current requirements and those to be implemented in the future, which are largely based on the DiGA guidelines.
2.1 Applicable Requirements
All manufacturers currently need an information security management system. Both establishment/implementation and certification are required as proof. There are two options: according to ISO 27001 or “ISO 27001 based on IT-Grundschutz (BSI standard 200-2: IT-Grundschutz methodology)”.
The Digital Supply and Care Modernization Act (DVPMG) also states that a penetration test must be carried out for all components, regardless of the protection requirements of the DiGA. Penetration tests are one of the “basic requirements that apply to all digital health applications” in Appendix 1. The BSI implementation concept for penetration tests and the current OWASP top 10 security risks must be used as the basis for the test concept. Upon request, the BfArM must be presented with proof that the relevant tests have been carried out.
2.2 What’s new and when?
The secure authentication of insured persons via digital identity must be implemented January 1, 2024 Originally, this requirement was supposed to have been implemented by January 1, 2023. However, the health insurance companies have until January 1st, 2024 to create the digital identity:
"Social Code (SGB) Fifth Book (V) - Statutory health insurance - (Article 1 of the law of December 20, 1988, BGBl. I p. 2477)
§ 291 Electronic health card:
(8) From January 1, 2024 at the latest In addition to the electronic health card, health insurance companies can, upon request, provide the insured with a secure, barrier-free digital identity for the healthcare system that meets the requirements of paragraph 2 numbers 1 and 2 and enables the health insurance companies to provide data in accordance with Section 291a paragraphs 2 and 3."
From January 1st, 2024, a regular, automated export of the data collected by the DiGA into the electronic patient file (ePA) must be guaranteed. The National Association of Statutory Health Insurance Physicians (KBV) defines the corresponding requirements for semantic and syntactic interoperability.
Proof in the form of a certificate in accordance with Article 42 GDPR (Regulation (EU) 2016/679) of compliance with data protection requirements must be available August 1st, 2024
"Social Code (SGB) Fifth Book (V) - Statutory Health Insurance - (Article 1 of the law of December 20, 1988, Federal Law Gazette I p. 2477)
§ 139e Directory for digital health applications; Authorization to issue regulations:
(11) The Federal Institute for Medicines and Medical Devices, in agreement with the Federal Commissioner for Data Protection and Freedom of Information and in consultation with the Federal Office for Information Security, shall, for the first time by March 31, 2022 and then generally annually, specify the testing criteria for the requirements to be demonstrated by digital health applications Data protection in accordance with paragraph 2 sentence 2 number 2. From August 1, 2024, proof of compliance with the data protection requirements by the manufacturer must be provided by submitting a certificate in accordance with Article 42 of Regulation (EU) 2016/ 679 to lead."
The technical guideline TR-03161 includes the requirements for applications in the healthcare sector defined by the Federal Office for Information Security (BSI) and is part of the data security requirements of a DiGA according to Section 139e Paragraph 10 SGB V. From January 1st, 2025 there is a corresponding one Certificate to be presented.
"Social Code (SGB) Fifth Book (V) - Statutory Health Insurance - (Article 1 of the law of December 20, 1988, BGBl. I p. 2477)
§ 139e Directory for digital health applications; Authorization to issue regulations:
(10) The Federal Office for Security in of Information Technology, in agreement with the Federal Institute for Drugs and Medical Devices and in consultation with the Federal Commissioner for Data Protection and Freedom of Information, lays down the data security requirements to be demonstrated by digital health applications in accordance with paragraph for the first time by January 1, 2024 and then generally annually 2 sentence 2 number 2. From June 1, 2024, the Federal Office for Information Security will offer procedures for checking compliance with the requirements according to sentence 1 as well as procedures for confirming compliance with the requirements according to sentence 1 through appropriate certificates Fulfillment of the data security requirements by the manufacturer must be carried out by presenting a certificate in accordance with sentence 2 from January 1, 2025 at the latest."
3. Other requirements
In principle, all regulatory requirements that generally apply to all medical devices also apply to digital health applications. Technical documentation must also be created for a digital health application, which is used to demonstrate compliance with the basic security and performance requirements of the MDR. Every manufacturer of a medical device needs a QMS based on ISO 13485 based on the applicable regulations. Since the MDR came into force, this also applies to manufacturers of Class I products.
But the spectrum of requirements in the digital environment continues to grow. For example, there is now the additional issue of whether a form of 14-day right of return should be introduced for patients after the initial prescription of the DiGA.
4. Consequences of these new requirements
What consequences might these additional requirements bring? It should be said that the deadlines currently lie in the future, which is why the actual handling of possible consequences for manufacturers is still a hypothetical space. Realistic experience will only be available in the coming months. Nevertheless, one aspect in particular appears particularly sensitive when considering the requirements: classification . The classification of software is generally based on the classification rules from Appendix VIII of the MDR. However, there are also valid guidance documents that can be used for support. Rule 11 states that “ software intended to provide information used to make decisions for diagnostic or therapeutic purposes belongs to Class IIa ”.
Now imagine the following hypothetical scenario: You as a manufacturer have successfully implemented all required export functionalities and interoperability requirements. It is now possible to carry out a regular and automated export of the data collected with your DiGA into the individual's ePA, as well as to export certain information from the DiGA as a patient. Your DiGA concept includes, among other things, the provision of material for exercises that patients should do at home. Now let's assume that Ms. Müller is prescribed her DiGA and then uses it diligently. The data collected is sent to Ms. Müller's ePA, so her treating doctor has access to this data. In addition, Ms. Müller exports the generic content provided by you as the manufacturer, which also contains data on Ms. Müller's individual application. At Ms. Müller's next doctor's visit, the use of the DiGA is discussed (both Ms. Müller's export and the data in the ePA are available), whereupon her treating doctor suggests that she no longer do exercise No. 5 in her explicit case of illness to carry out. So, according to Rule 11, in theory we ended up in a scenario in which the DiGA provided information that led the doctor to make treatment recommendations to Ms. Müller. The result of the scenario: a Class I product became a Class IIa product through the implementation of the requirements.
The possible consequences of such a classification are considered in detail in the following chapters.
4.1 Certification
We have already explained that since the MDR came into force, every manufacturer of a medical device must have a QMS. However, it is only for manufacturers with a Class IIa product or more that this QMS must also be certified. For Class I manufacturers, setting up and living such a process structure is sufficient. If the requirements result in a higher classification, your QMS must be certified so that you as a manufacturer continue to comply with the applicable regulations. Given the deadlines for the MDR transition, this aspect is probably one of the most time-critical factors and requires immediate consideration of possible classification consequences for your product .
4.2 Cost question/investors
The current requirements already entail high costs for manufacturers. It is not only important to complete a successful audit of the implementation of the information security management system (ISMS), the path from data collection to successful DiGA listing is also a long and costly one. Due to the additional requirements to be implemented, manufacturers now face an additional cost block, which from an economic point of view often depends on the willingness of their investors.
4.3 Technical documentation
The technical documentation is the basis of every medical product as proof of compliance with the basic safety and performance requirements of the MDR. Essential components of this technical documentation include, among other things, risk management and the usability file with the corresponding tests for the use of the product. In the case of software, the software file also forms a large component of the documentation. This includes both the definition of the requirements and the actual implementation in the form of the architecture as well as other relevant process documentation to verify and validate the successful development. The level of detail of this technical documentation, particularly with regard to the software file, depends, among other things, on the classification of the software product. If this results in a higher classification, the technical documentation must also be revised accordingly, which entails costs and may temporarily tie up resources in the company. In addition, this must then also be certified by a notified body; the manufacturer can no longer issue the EU declaration of conformity itself.
5. Relation to the last blog post
Our last blog post took a closer look at doctors' reluctance to prescribe DiGAs. Despite the numerous advantages of DiGAs, many doctors are hesitant to prescribe them. One reason for this is that they are not sure whether DiGAs are actually effective. There are also concerns about the security of DiGAs as well as data security. Another factor is the lack of time and resources to support patients in the use of DiGAs. Additionally, many physicians are concerned about the additional burden of prescribing and monitoring DiGAs. And last but not least, there is the concern as to whether the health insurance companies will really cover the costs or whether a corresponding prescription can lead to recourse.
The previously described requirements for DiGAs largely relate to the security and, above all, the data security of the applications placed on the market, which would address at least one aspect of reluctance to prescribe. However, the implementation of the requirements also results in a major entrepreneurial risk for the manufacturers. If you look at the additional costs for the implementation of all these aspects and also take into account the fact that the prescription of the successfully listed DiGA might only progress slowly, the break-even point slips further and further into the distance and the economic viability of the development Such DiGAs must be seriously questioned.
6. Conclusion/Conclusion
DiGAs have the potential to improve medical care and make it easier for patients to access digital health applications. However, the enormous opportunities offered by these products are offset by immense challenges, especially for manufacturers.
As a significant consequence of the implementation of the highlighted requirements, we were able to identify the question of the resulting classification of the DiGA. This affects both manufacturers who are still in the initial development of their product and those who have already achieved a provisional or final listing for their DiGA. The possible resulting higher classification has far-reaching consequences - this affects both the certification of the quality management system and the technical documentation as well as all business aspects (e.g. costs, time, investors). Manufacturers should therefore first address this question of the correct future classification of their medical device in order to be able to initiate further steps.
The question posed at the beginning of how the immense challenges will relate to the potential benefits of digital applications in the future cannot be answered conclusively. The requirements must only be implemented by the defined deadlines, so that the resulting consequences for manufacturers will only become clear in the coming months. However, looking at the multitude of requirements clearly shows that the strong regulation of this particular type of medical software product should be urgently questioned. Ultimately, it is important to provide the patient with added value and to support and accompany them in everyday life in dealing with their illnesses.
7. How we can help you
We would be happy to support you in successfully listing your DiGA by means of an early evaluation of the product classification based on your planned features.
At medXteam we clarify whether and if so which clinical trial needs to be carried out under what conditions and according to what requirements during the pre-study phase: In 3 steps we determine the correct and cost-effective strategy in relation to the clinical trial required in your case Data collection.
If a clinical trial is to be carried out, basic safety and performance requirements must first be met. The data from the clinical trial then feed into the clinical evaluation, which in turn forms the basis for post-market clinical follow-up (PMCF) activities (including a PMCF study).
In addition, all medical device manufacturers require a quality management system (QMS), including when developing Class I products.
We support you throughout your entire project with your medical device, starting with a free initial consultation, help with the introduction of a QM system, study planning and implementation through to technical documentation - always with primary reference to the clinical data on the product: from the beginning to the end End.
Do you already have some initial questions?
You can get a free initial consultation here: free initial consultation