How to turn a health app into a marketable digital health application (DiGA)

Digital Health Germany: Why it is worth certifying your health app as medical product and digital health application in Germany

In the first of our series of articles on the opportunities and challenges for digital health applications in the digital health market in Germany, we look at how the regulations gives a competitive advantage for those who certify their health apps as medical products by May 2021.

Representatives of the health industry recognise the Covid-19 pandemic as a turning point for the digital transformation of the health system. The industry is planning substantial investments in the development of tomorrow's medicine. This raises the question of how to connect innovative medicine with a successful business model. In this respect, the Germany recently opened up access to the public health system for so-called Digital Health Applications (DiGAs). Developers of DiGAs, who certify their applications as medical devices could establish access to one of the largest health markets in the world, with a market volume of 400 billion euros. The „Digital Supply Act“ of 7 November 2019 and the “Digital Health Applications Ordinance” (DiGAV), which came into force on 21 April 2020 define the entry rules for apps on prescription for patients.

Following our report in early 2020 on the implementation and regulatory purpose of the Digital Supply Act, this article is the start of a four-part series. This series defines the legal path of health-app-developers, who wish to list their health app as a DiGA. Without a listing in the directory of Digital Health Application, market access to one of the largest health markets in the world remains closed.

For first movers, those app developers, who decide to certify their app as a medical device by May 2021, the European Commission has implemented an innovation bonus in the new EU Medical Device Regulation (EU-MDR). Developers of DIGAs can save a lot of money, time and nerves, if they quickly (by May 2021) decide to push their Health App to a DiGA.

Competitive advantage for first-movers

In the course of the Covid-19 pandemic, it has gone relatively unnoticed that the so-called "transitional provisions" of the new EU-MDR have been adapted simultaneously with the extension of the application and implementation period of the EU-MDR until 26 May 2021.

The transitional provisions are intended to compensate for hardships caused, for example, by a tightening of the existing legal situation. The EU-MDR, which will come into force on May 26, 2021, will introduce additional burdens for developers of health apps. In jurisprudence, the fundamental reclassification of software from risk-class I to risk-class IIa is regarded as "one of the greatest mistakes made by the Union legislator in the reform of medical device law" (" (Gassner/Schreiegg, MPR 2019, 198, 200). Some authors have identified a "massive barrier to innovation" ((Prütting/Wolg, MedR 2020, 359, 363). And indeed, the reclassification means that a conformity procedure must be carried out via a so-called "Notified Body" – a kind of inspection service – for medical devices. The costs of an inspection by a Notified Body depends on the size of the company and starts at EUR 10,000 for a company with ten employees. This is just as painful for innovative, small start-ups as it is for large companies, whose number of employees is higher, because with an increasing number of employees the inspection effort and costs increase accordingly.

It is doubtful whether the EU will reverse this tightening of the regulation. After all, the first Amendment to the EU-MDR of April 23, 2020 reiterates that the EU-MDR is intended to ensure a high level of health protection for patients and users. In the European Commission's White Paper on Artificial Intelligence, the use of AI is regarded as a major risk, even though the specific field of application must always be taken into account.
In any case, reforms in pharmaceutical or medical product legislation have traditionally been accompanied by tighter rules.

Let us return to the transitional provision of the new EU-MDR, which was last amended on April, 23, 2020. According to the above, the transitional provision of Art. 120(3) EU-MDR conceals a genuine competitive advantage for early movers:

According to Art. 120 Abs. 3 EU-MDR

„a device which is a class I device pursuant to Directive 93/42/EEC, for which the declaration of conformity was drawn up prior to 26 May 2021 and for which the conformity assessment procedure pursuant to this Regulation requires the involvement of a notified body, or which has a certificate that was issued in accordance with Directive 90/385/EEC or Directive 93/42/EEC (…), may be placed on the market or put into service until 26 May 2024“.

Companies that (may) certify their health app as a risk-class I medical product by May 26, 2021 can do so independently with a „Declaration of Conformity“. In any case, a "TÜV approval" by a Notified Body is not required until May 26, 2024. This can safe investments in the inspections of medical devices by a Notified Body.

(Self-)certification of health apps as medical devices

Of course, not every health app is a medical device and not every health app that fulfils the requirements of a medical device is automatically a DiGA (see in short below and in more detail in Part 2 of the series of articles). However, it is the developer's subjective purpose of the health app, which is expressed in the app description and application notes that determines whether or not the application is a medical device. This is accompanied by the risk classification of a health app, which is carried out by each manufacturer himself.

 Health-app and medical device

The developer must demonstrate in an objectively comprehensible manner that their app can be used for

• diagnosis, prevention, monitoring, treatment or alleviation of disease;
• diagnosis, monitoring, treatment, alleviation of or compensation for an injury or handicap;
• investigation, replacement or modification of the anatomy or of a physiological process;

or

• control of conception.

Only of this can be demonstrated can a health app is also be considered a medical device. According to the interpretation of the Federal Institute for Drugs and medical devices, the mere storage and provision of non-individualised data is not sufficient. On the one hand, Fitness trackers are, therefore, not medical devices unless they are linked to an algorithm that analyses the user's state of health. On the other hand, apps for nutrition advice, for example, which use machine learning to provide optimised, individualised purchasing and eating recommendations based on the individual's state of health, could (easily) be classed as a medical device.

Medical device and DiGA

If manufacturers intend to list their applications as DiGAS, it should be borne in mind that apps with a purely preventive purpose cannot be listed as a DiGA (see in more detail in Part 2 of the series of articles). There is a certain tradition in the German health care system that preventive measures are only prescribed under strict conditions. The case of the nutritionist app is, therefore, a borderline case. If the app (also) serves to treat obesity, then the app is a medical device because it serves to treat a disease. Even if the app detects obesity, it is a medical device and – in this respect – would also be a DiGA because the detection of diseases is covered by the definitions of medical devices and DiGAs.

Risk-Classification

The medical device app has to match risk classifications I or IIa. "Stand-alone software" is considered as an „active medical device“, while diabetes apps that read and evaluate data from an implanted computer chip are based on the risk classification of the computer chip.

Depending on the risk to human health, "stand-alone software" is also classified in one of three classes of risk (Class I: low risk, Class IIa/IIb: medium-risk/ increased risk, Class III: high risk). Software that can diagnose skin cancer could possibly fall into the highest risk class (III), because misinformation can cause human death if the user relies on the recommendation of the software. The higher the risk class, the higher the requirements for certification and monitoring. Software that is specifically designed to allow direct diagnosis or to control vital processes falls into risk class IIa.

A “rule of thumb” can be formulated: Software used by doctors falls into category IIa if and to the extent that the doctor can make a direct diagnosis from the output of the App. It is therefore quite possible that developers will have to make several risk classifications: If a platform for physicians is offered that contains diagnostic software that obtains information from a DIGA developed for patients, the physician platform and patient app are subject to an individual classification.

In the vast majority of cases, however, the new EU-MDR, which will be in force from May 26, 2021 tightens up the risk classification, so that it is clear that nutrition-adviser-software used also falls into risk class IIa.

However, with the exception(s) just discussed as an example, software will generally be assigned to risk class I until May 2021. As a result, diabetes diary apps (such as “mySugr) will also belong to risk class I.

Self-certification and appointment of a safety officer

The (self-)certification of Class I software is carried out with the submission of an EG Declaration of Conformity. This declaration must contain certain information (Annex VII of Directive 93/42/EEC as the procedure for the "EG Declaration of Conformity") as well as the declaration that the product meets the requirements set out in the Regulation. In addition, a technical documentation must be drawn up (Art. 19 MPV).

The following (basic) information must be included in each declaration of conformity and must always be kept up to date:

• Name and address of the manufacturer or their authorised representative and the SRN (Single Registration Number).
• Declaration that the manufacturer alone is responsible for the declaration of conformity
• Basic UDI-DI.
• Product and trade name, product code, catalogue number and other references to enable identification and traceability of the product, the intended use and, where appropriate, an image.
• Risk application class.
• Self-Assurance that the product complies with MDR and other applicable EU legislation requiring a declaration of conformity.
• References to applied common specifications.
• If applicable, name and identification number of the Notified Body, description of the conformity assessment procedure.
• Place and date of issue, name and function of the signatory, indication of the person for whom and in whose name he/she signed and his/her signature.

Every developer of health apps domiciled in Germany must appoint a “Security Officer” (paragraph 30 of German Medical Device Directive). This person must have the necessary reliability and expertise, which can be proven by the successful completion of a university degree in the field of natural sciences (chemistry, pharmacy, biology, etc.) or medicine. A university degree in informatics is not sufficient.

Attachment of CE label “on the software”

Manufacturers can affix the CE label in health apps as follows:

• On the start- or „Splash-Screen“.
• In the „About“ or imprint sections.
• In accompanying materials, such as the instructions for use.

DiGAs are subject to additional specific labelling and information requirements, which are discussed in Part 2.

Duty of notification

Before a health app, which is certified as a Mmedical device, is offered for download or made publicly available, the competent authority must be notified. This is done digitally via the Medical Device Information System of the Federal Office for Drugs and Medical devices. A notification - unlike an approval - is not linked to special requirements.

Conclusion and outlook

It is worth investing in the (further) development of health apps for medical devices and DiGAs. Even without Covid-19, according to data from the "Rock-Health-Funding-Database", 2020 was on its way to becoming a record year in the history of investments in the health industry.

We recommend to taking advantage of the opportunity to develop health apps and certify them as medical devices by 26 May 2021. Those who do can benefit from the investment protection as a first mover for three years, opening up a simplified first step towards the directory of DiGAs.

Author:

Dr. Dominic Habel (Associate at Osborne Clarke)