The undetected trap? The black box of the new DiGA requirements
At medXteam, clinical data is our core focus. As a CRO, we not only conduct clinical trials with medical devices in accordance with the MDR and ISO 14155, but also offer all other options and forms of data collection. This time, the focus is again on the topic of Digital Health Applications (DiGA). Data is collected here as well. But this time, the central question is: What potential challenges do the DiGA requirements pose 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 Devices Implementation Act (MPDG)
ISO 14155
ISO 27001
DiGA Guideline V3.4
Digital Healthcare 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, the regulatory context of digital health applications (DiGAs) presents not only opportunities for patients and medical staff, but also challenges for the manufacturers of these products. Numerous requirements have already been defined, which manufacturers must implement and document by specific deadlines. These requirements, which we will examine in more detail in this article, confront manufacturers with the fundamental question of classifying their medical software products. While most DiGAs are currently classified as Class I products, the implementation of the new requirements may result in a higher classification. This is not only a fundamental regulatory issue; the certification of the quality management system (QMS), the resulting cost and time considerations, and the need to present the case to investors are also important aspects of this analysis.
Considering the debate in our last blog post about why doctors are primarily hesitant 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
Even now, as a DiGA manufacturer, you are required to implement certain requirements within product development and internal company processes. The following chapter examines both the currently applicable and future requirements, which are largely based on the DiGA guidelines.
2.1 Applicable requirements
All manufacturers are currently required to have an information security management system. Both its establishment/implementation and certification as proof of compliance are mandatory. There are two options: according to ISO 27001 or "ISO 27001 based on IT baseline protection (BSI Standard 200-2: IT baseline protection methodology)".
The Digital Healthcare and Care Modernization Act (DVPMG) also stipulates that, regardless of the security requirements of the digital health application (DiGA), a penetration test must be performed on all components. Penetration tests are among the "basic requirements that apply to all digital health applications" listed in Annex 1. The BSI's penetration testing implementation concept and the current OWASP Top 10 security risks must be used as the basis for the test design. Proof of the execution of the corresponding tests must be provided to the BfArM upon request.
2.2 What new features will be added and when?
Secure authentication of insured persons via digital identity must be implemented by January 1, 2024 . Originally, this requirement was to be implemented by January 1, 2023. However, health insurance companies have been given until January 1, 2024, to create the digital identity.
"Social Code (SGB) Book Five (V) - Statutory Health Insurance - (Article 1 of the Law of 20 December 1988, Federal Law Gazette I p. 2477)
Section 291 Electronic Health Card:
(8) No later than 1 January 2024, the health insurance funds shall, upon request, provide the insured persons with a secure digital identity for the healthcare system in addition to the electronic health card, which meets the requirements of paragraph 2 numbers 1 and 2 and enables the provision of data pursuant to Section 291a paragraphs 2 and 3 by the health insurance funds."
From January 1, 2024 , regular, automated export of data collected by digital health applications (DiGA) to the electronic patient record (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 according to Article 42 GDPR (Regulation (EU) 2016/679) of compliance with data protection requirements must be available 01.08.2024
"Social Code (SGB) Book Five (V) - Statutory Health Insurance - (Article 1 of the Act of 20 December 1988, Federal Law Gazette I p. 2477)
Section 139e List of digital health applications; Authorization to issue regulations:
(11) The Federal Institute for Drugs 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 establish, for the first time by 31 March 2022 and thereafter generally annually, the test criteria for the data protection requirements to be demonstrated by digital health applications pursuant to paragraph 2 sentence 2 number 2. From 1 August 2024, the manufacturer must provide proof of compliance with the data protection requirements by submitting a certificate issued on the basis of the test criteria pursuant to sentence 1 in accordance with Article 42 of Regulation (EU) 2016/679."
The technical guideline TR-03161 encompasses the requirements for healthcare applications defined by the Federal Office for Information Security (BSI) and is part of the data security requirements for a DiGA (Digital Health Application) according to Section 139e Paragraph 10 of the German Social Code, Book V (SGB V). A corresponding certificate must be submitted January 1, 2025
"Social Code (SGB) Book Five (V) - Statutory Health Insurance - (Article 1 of the Act of 20 December 1988, Federal Law Gazette I p. 2477)
Section 139e List of Digital Health Applications; Authorization to Issue Regulations:
(10) The Federal Office for Information Security, 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, shall establish, for the first time by 1 January 2024 and thereafter generally annually, the data security requirements to be demonstrated by digital health applications pursuant to paragraph 2 sentence 2 number 2. From 1 June 2024, the Federal Office for Information Security shall offer procedures for verifying compliance with the requirements pursuant to sentence 1 as well as procedures for confirming compliance with the requirements pursuant to sentence 1 by means of corresponding certificates. Proof of compliance with the data security requirements by the manufacturer must be provided by submitting a certificate pursuant to sentence 2 no later than 1 January 2025." lead."
3. Further requirements
In principle, all regulatory requirements that generally apply to all medical devices also apply to digital health applications. This means that technical documentation must be prepared for a digital health application to demonstrate compliance with the essential safety and performance requirements of the MDR. Every manufacturer of a medical device requires a quality management system (QMS) based on ISO 13485, in accordance with applicable regulations. Since the MDR came into force, this also applies to manufacturers of Class I devices.
However, the range of requirements in the digital environment continues to grow. For example, the additional question now arises whether a form of 14-day right of return should be introduced for patients after the initial prescription of the DiGA (Digital Health Application).
4. Consequences of these new requirements
What consequences might these additional requirements entail? It should be noted that the deadlines are currently still in the future, meaning that the actual handling of potential consequences for manufacturers remains hypothetical. Realistic experience will only be gathered in the coming months. Nevertheless, one aspect of the requirements appears particularly critical: classification . The classification of software is fundamentally based on the classification rules in Annex VIII of the MDR. However, there are also valid guidance documents that can be used for support. Rule 11 stipulates that " software intended to provide information used in making decisions for diagnostic or therapeutic purposes is classified as Class IIa ."
Now imagine the following hypothetical scenario: As the manufacturer, you have successfully implemented all required export functionalities and interoperability requirements. It is now possible to perform a regular and automated export of the data collected with your DiGA (Digital Health Application) to the individual's electronic patient record (ePA), as well as to export certain information from the DiGA as a patient. Your DiGA concept includes, among other things, providing materials for exercises that patients are to perform at home. Let's assume that Ms. Müller is prescribed your DiGA and then uses it diligently. The data collected is transferred to Ms. Müller's ePA, and her treating physician thus has access to this data. In addition, Ms. Müller exports the generic content provided by you as the manufacturer, which also contains data relating to her individual use of the DiGA. At Ms. Müller's next doctor's appointment, the use of the DiGA is discussed (both Ms. Müller's export and the data in her ePA are available), whereupon her treating physician advises her to discontinue exercise number 5 in her specific case. Thus, according to Rule 11, we have theoretically arrived at a scenario in which the DiGA (Digital Health Application) provided information that prompted the physician to make therapy recommendations to Ms. Müller. The result of this scenario: through the implementation of the requirements, a Class I product became a Class IIa product.
The following chapters will examine in detail the possible consequences of such a classification.
4.1 Certification
We have already explained that since the MDR came into force, every manufacturer of a medical device must have a Quality Management System (QMS). However, only manufacturers of Class IIa products and above are required to have their QMS certified. For Class I manufacturers, simply establishing and maintaining such a process structure is sufficient. Should a higher classification result from the requirements, your QMS must be certified to ensure you, as the manufacturer, continue to comply with the applicable regulations. Especially given the deadlines for the MDR transition, this aspect is arguably the most time-critical factor and requires immediate attention to the potential classification consequences for your product .
4.2 Cost issue/Investors
The existing requirements already entail high costs for manufacturers. Not only must they successfully complete an audit of the implementation of their Information Security Management System (ISMS), but the data collection process leading to successful listing of their digital health applications (DiGA) is also lengthy and expensive. The additional requirements now present manufacturers with a further cost burden, the economic viability of which often depends on the willingness of their investors to invest.
4.3 Technical Documentation
Technical documentation serves as proof of compliance with the MDR's fundamental safety and performance requirements for every medical device. Key components of this technical documentation include risk management and the usability file with the corresponding tests for the product's application. In the case of software, the software file also forms a significant part of the documentation. This encompasses both the definition of requirements and their actual implementation in the form of the architecture, as well as other relevant process documentation for verifying and validating successful development. The level of detail in this technical documentation, particularly regarding the software file, depends, among other things, on the classification of the software product. Should a higher classification result, the technical documentation must also be revised accordingly, which incurs costs and may temporarily tie up company resources. Furthermore, it must then also be certified by a Notified Body; the manufacturer can no longer issue the EU Declaration of Conformity themselves.
5. Relationship to the last blog post
In our last blog post, we took a closer look at doctors' reluctance to prescribe digital health applications (DiGAs). Despite the numerous advantages of DiGAs, many doctors are hesitant to prescribe them. One reason for this is their uncertainty about their effectiveness. There are also concerns about the safety and data security of DiGAs. Another factor is the lack of time and resources to support patients in using DiGAs. Furthermore, many doctors are worried about the additional workload associated with prescribing and monitoring DiGAs. And finally, there is the concern about whether reimbursement by health insurance companies is truly guaranteed or whether a prescription could lead to a claim for reimbursement.
The previously described requirements for digital health applications (DiGAs) largely relate to the safety and, above all, the data security of the applications placed on the market, thus addressing at least one aspect of the reluctance to prescribe them. However, implementing these requirements also results in a significant business risk for manufacturers. Considering the additional costs of implementing all these aspects, and also taking into account the possibility that prescriptions for successfully listed DiGAs might only progress slowly, the break-even point recedes further and further into the distance, and the economic viability of developing such DiGAs must be seriously questioned.
6. Conclusion
Digital health applications (DiGAs) have the potential to improve medical care and facilitate patient access to them. However, the enormous opportunities these products offer are countered by immense challenges, especially for manufacturers.
As a key consequence of implementing the identified requirements, we were able to determine the resulting classification of the DiGA (Digital Health Application). This affects both manufacturers still in the initial development phase of their product and those who have already achieved preliminary or final listing of their DiGA. A potentially resulting higher classification has far-reaching consequences – this includes the certification of the quality management system and the technical documentation, as well as all business aspects (e.g., costs, time, investors). Therefore, manufacturers should first address this question of the correct future classification of their medical device in order to initiate further steps.
The initial question of how the immense challenges will relate to the potential benefits of digital applications in the future cannot be definitively answered. The requirements must be implemented by the defined deadlines, meaning the resulting consequences for manufacturers will only become clear in the coming months. However, considering the multitude of requirements clearly demonstrates that the stringent regulation of this particular type of medical software product urgently needs to be re-evaluated. Ultimately, the goal is to provide added value to patients and support and guide them in managing their illnesses in their daily lives.
7. How we can help you
We would be happy to support you in achieving a successful listing of 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).
Furthermore, all manufacturers of medical devices require a quality management system (QMS), even 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