How does Germany achieve the efficiency and completeness of approvals?

，

，，，

：、、app、

75，15——

（BfArM，Bundesinstitut für Arzneimittel und Medizinprodukte）

BfArM

DiGA is the abbreviation of German "Digitale Gesundheitsanwendungen", which means digital health application (DiGA will be used to refer to German digital therapy below)

Artery.

Dr.

Since DiGA and traditional software application approval cannot be completely equated, after a period of exploration, based on the spirit of Section 139e of "Fünftes Buch Sozialgesetzbuch" (Fünftes Buch Sozialgesetzbuch, SGB Ⅴ) Under the guidance of, BfArM designed a special fast-track process for DiGA (The Fast-Track Process for DiGA)

On May 27, 2020, the DiGA fast-track approval procedure was officially implemented, and it has been just one year so far

Dr.

Relatively speaking, doctors and patients are more cautious

“As for the patients, although they are excited about the management and treatment of diseases that DiGA can help, they also want to know what effect a DiGA can achieve and to what extent it can improve their health

How does German DiGA define digital therapy?

To put it simply, BfArM believes that DiGA is a Class I and Class IIa medical device that has passed the EU CE certification and is based on the EU Medical Device Regulation (MDR, hereinafter referred to as Medical Device Regulation) and EU Medical Device Directive (hereinafter referred to as MDD, Medical Device Directive) , And has the following attributes: DiGA's medical functions should be mainly realized by software digital functions; it can support the identification, monitoring, treatment or mitigation of diseases, or the identification, monitoring, treatment, mitigation and compensation of physical injuries or disability; it can be individually facing patients , Can also face patients and medical institutions at the same time

It is not difficult to see from the definition that there is a difference between CE certification and DiGA approval

"At the EU level, there is not yet a unified standard for digital therapy, but I think this is the direction of future development

Timeline of German DiGA Approval Policy

It is worth mentioning that BfArM was in the transitional period between MDD and MDR when it established the DiGA rapid approval process
.
On May 26, 2021, MDR was officially implemented
.
The definition or classification of medical devices may change in the future to meet the requirements of the new MDR
.

DiGA is a software application, but also a medical device

From the perspective of DiGA's definition, medical devices are the first priority
.
BfArM has set up detailed and practical guidelines for the convenience of the public and developers to quickly distinguish between ordinary medical and health applications and software applications as medical devices
.
According to whether the software application is definitely classified as a medical device, it can be divided into two situations
.
In addition, once a software application is recognized as a medical device, the basic regulatory requirements that need to be met during the manufacturing process are the same as traditional medical devices that integrate production and research, without exception
.

The first category is applications that can definitely be recognized as medical devices
.
According to the German "Medical Device Law" (hereinafter referred to as MPG, short for German Medizinproduktegesetz), software applications such as smart phone apps can be classified as medical devices if they must be used for humans and used for at least one of the four types of purposes.

.

The four types of situations are: software applications are used to diagnose, prevent, monitor, treat or alleviate diseases; used to diagnose, monitor, treat, reduce or compensate for physical and psychological injuries or physical defects; used to investigate anatomical or physiological processes, Replacement or modification; and used to control conception
.

In general, BfArM believes that any independent software based on data or information intervention can be classified as a certain level of medical equipment
.
However, this does not include software that is only used to provide knowledge or information.
For example, an electronic manual is clearly not a medical device
.

The second category is applications that may be identified as medical devices
.
The declared uses of these applications generally include the following words: alarm, analysis, calculation, detection, diagnosis, interpretation, conversion, measurement, control, monitoring, and amplification
.

Among them, software applications that can be identified as a certain level of medical devices mainly include the following categories: applications that provide decision-making assistance represented by treatment measures; applications that calculate the amount of drug injection (just copy a simple table for users to infer injection doses) This method is not listed); monitor patients and collect data, and the monitoring results have a significant impact on diagnosis or diagnosis and treatment
.

It should be emphasized that pure data storage, archiving, lossless compression, communication or simple information search applications cannot be classified as medical devices
.
For example, a certain kind of software dedicated to data archiving is obviously not a medical device
.

According to a simple classification of software usage, decision support software, software systems, telemedicine systems, HIS, and PACS belong to medical devices, while operating system software and general-purpose software do not belong to medical devices
.
As for whether a health software application is classified as a medical device, it is necessary to determine whether it is intended for medical purposes-if it is only used for fitness or nutrition goals, and the developer claims that it has no medical purpose, it is usually not a medical device
.

What's interesting is that some developers may try to circumvent supervision by simply marking "this is not a medical device" in the app store description
.
In this regard, according to MPG regulations, once software is used in any public materials such as labels and instructions for use that indicate or imply its intended use for medical purposes, it will still be regulated by BfArM as a medical device
.

As a software application, DiGA needs to strictly abide by relevant data security regulations
.
The European Union is one of the regions with the highest data security requirements in the world, and one of the regions where citizens value personal privacy the most
.
Therefore, DiGA needs to strictly abide by the corresponding data security laws and regulations
.
Once DiGA involves data processing outside of Germany, it must comply with the corresponding laws and regulations
.
Even after the formal approval of DiGA is completed, technical adjustments may be required in accordance with the update of the corresponding data and privacy security regulations
.
Otherwise, the existing approval may still be cancelled according to law
.

"Because of the new crown epidemic, more and more people are beginning to accept related DiGA applications
.
At this time, a very important issue will inevitably arise, that is, the issue of data security and privacy protection
.
I think this is not only a DiGA issue, but also Any related products or services in the future must be considered in order to enter the German market
.
" Ms.
Zuo Simin emphasized that data security and privacy protection have a high priority in Germany
.

DiGA must not cause potential serious harm to the human body

The reason why DiGA only includes software applications for Class I and Class IIa medical devices is based on risk considerations
.
In the European Union, in addition to in vitro diagnostics and active implantable medical devices, medical devices are classified into different risk categories based on the potential damage that their errors/faults may cause, ranging from category I (low risk) to IIa or IIb (medium risk) ), and then to Type III (high risk)
.

According to MDD regulations, it can be applied to several rules for determining whether software applications are medical devices (mainly including Rule 9, Rule 10, Rule 12, Rule 14 and Implementation Rule 2.
3).
Medical devices recognized as Class IIb may be In a certain way, it has a potential and irreversible important impact on human health
.

For example, Rule 10 stipulates that “used to provide energy absorbed by the human body (except for equipment used to illuminate the patient’s body in the visible spectrum), used for imaging the distribution of radiopharmaceuticals in the body, and used for direct diagnosis or monitoring of important human physiology "Process" and the active equipment used for diagnosis belongs to Class IIa medical equipment
.

However, once the physiological signs monitored by such active devices that directly diagnose or monitor important physiological processes of the human body are extremely important and may directly lead to life-threatening patients (such as ECG indicators, respiration and central nervous activity, etc.
), they will be classified as Class IIb medical devices
.
In addition, interventional radioactive active devices used to generate ionizing radiation and used for diagnosis and treatment, as well as devices used to control, monitor, or directly affect their performance (including software applications) belong to Class IIb
.

According to MDD rules, medical applications on smartphones and tablets will be classified as Class I medical devices
.
Of course, if it is used to diagnose or monitor important physical signs (such as ECG indicators), it may be classified as a Class IIa or IIb medical device according to the degree of risk
.
Once classified as a Class IIb medical device, it will not be recognized as DiGA and needs to meet higher regulatory requirements
.

In other words, BfArM clearly believes that DiGA must have a high level of safety and cannot pose potential risks to human health
.
Once the work is abnormal, the software application that will cause the user to fall into a potentially dangerous situation cannot be recognized as DiGA
.

At the same time, software that only functions for device data collection and transmission or device control cannot be recognized as DiGA; the application used by doctors to treat patients alone is not DiGA—DiGA must interact with patients, if only from sensors or mobile phones Waiting for the device to collect data and transmit it directly to the doctor does not meet this requirement
.

Is the software application that cooperates with other software, hardware or services DiGA?

Sometimes, DiGA will not appear as a single software application, but will be combined with other hardware, software or services
.
In some cases, these collocations can be identified as DiGA, and even approval is necessary; in some cases, it is not
.
Based on past experience, BfArM gave a detailed analysis of the corresponding possibilities
.

Combination with other software, hardware and services

DiGA has many forms, it can be a common app on a mobile phone, or a desktop application or a browser application on a computer
.
It can also be combined with hardware or software, as long as its main function is realized by digital technology applied by software
.
BfArM gives a very specific reference to whether the combined use of DiGA and hardware and software belongs to DiGA
.

A certified example of the combination of DiGA and hardware and software

DiGA can also cooperate with additional services
.
In principle, additional services like consultants, training or commercial insurance can be provided by DiGA or integrated into the use of DiGA
.
It needs to be clear that such additional services will not be paid for by medical insurance
.
Based on the premise that DiGA can be paid through medical insurance, the description of the software application necessary for its approval to have a positive impact on medical care cannot include such additional services
.
In addition, developers need to list all application scenarios that use additional services in their communication with BfArM to avoid misunderstandings
.

Of course, the above situation does not apply to the services provided by medical insurance certified doctors
.
Services provided by medical insurance-certified doctors, including attending doctors, residents, dentists, or psychologists, and services related to the use of DiGA are paid for by medical insurance in the form of doctor services
.
Therefore, these services can be used as part of the information required for DiGA approval
.

If the service of a medical insurance certified doctor can be included in the DiGA use process through a text description, or it can also directly list the EBM code required for medical insurance payment (in most cases, each payment of German medical insurance has an independent EBM code)
.
It should be noted that these services must be provided by medical insurance certified doctors and submit the reimbursement certificate, otherwise the medical insurance payment will not be available
.

A certified example of the combination of DiGA and service

Regarding the relationship between Internet medical care and DiGA, BfArM believes that if the main functions are realized by software digital technology, Internet medical applications are part of DiGA, but a pure Internet medical platform cannot be recognized as DiGA
.
In terms of the scope of inclusion, DiGA>Internet medical
.
Of course, individual special circumstances can only be determined after communicating with BfArM
.

Scope recognition when DiGA is combined with other functions

Sometimes, DiGA will provide additional optional services or functions, such as the link between DiGA and social media; the cooperation with additional hardware and software; or the modules it contains have been approved separately as medical devices
.
At this time, how should we distinguish the approval boundaries of DiGA?

BfArM believes that the boundary is that these additional functions or services cannot have any impact on the expected medical functions submitted at the time of DiGA approval, nor can they jeopardize or change their positive impact on medical care
.
In addition, these functions should be independent of DiGA, even if the function is abnormal, it will not affect the operation of the DiGA body
.

A certified example of the combination of DiGA and additional functions

According to relevant regulations, BfArM currently does not approve additional features; of course, if these additional features need to be paid, they will be fully borne by the user at their own expense and cannot be paid for by medical insurance
.
Therefore, these additional functions must be individually marked and clearly stated that they are not DiGA-certified functions
.

Can software applications used for disease prevention be recognized as DiGA?

Whether the software application used for disease prevention is recognized as DiGA will depend on the specific circumstances
.
In the German medical system, disease prevention is divided into several levels
.
The most entry-level primary prevention is positioned in the general population and is used to prevent the onset of diseases
.
In short, primary prevention applies to healthy people
.
It can promote healthy life>
.

However, according to the current definition, DiGA is used to “support the identification, monitoring, treatment or mitigation of diseases, or the identification, monitoring, treatment, mitigation and compensation of physical injuries or disabilities”
.
It clearly stipulates that it does not include disease avoidance or prevention functions, and is not suitable for healthy people
.
Therefore, software applications that are only used for primary prevention obviously do not belong to DiGA
.

A certified example of the combination of DiGA and scales

The software application of the secondary prevention that mainly prevents the deterioration of the disease and the tertiary prevention of complications and comorbidities meets the "disease treatment" in the DiGA definition
.
However, the prerequisite for approval is that the disease has specific risk factors, and specific risk factors can be coded into specific disease codes through the disease coding system
.

Fast approval process for DiGA with German characteristics

Germany believes that as an emerging medical device, digital therapy will systematically develop the innovative potential of German medical and health digital applications
.
On December 19, 2019, the German Digital Healthcare Law (hereinafter referred to as DVG, Digitale-Versorgung-Gesetz) came into effect
.
This bill became the legal basis for the approval of digital therapy in Germany later, marking Germany's incorporation of a "prescription app" for patients into the healthcare system
.

In order to be more in line with the characteristics of DiGA itself, the German Federal Ministry of Health has stipulated the application process, DiGA requirements and DiGA catalog in the supplementary legal regulations "Digital Health Application Regulations" (referred to as DiGAV, Digitale-Gesundheitsanwendungen-Verordnung)
.
DiGA is considered to have to be viewed as part of digital healthcare
.
Therefore, the requirements of DiGAV must allow DiGA developers to parallel the evolving national e-health infrastructure in Germany
.

BfArM provides guidelines for DiGA approval in accordance with the provisions of the "Fifth Part of the German Social Code: Statutory Health Insurance"
.
BfArM specially designed a rapid approval process for DiGA, and passed the German Federal Ministry of Health to regulate the details of this procedure
.
Once the corresponding software application is approved by BfArM, becomes a statutory DiGA and enters the DiGA catalog, the DiGA can be issued by medical insurance certified doctors for patients with indications and reimbursed by medical insurance
.

DiGA's general application process

From the time the developer submits the application for the software application, BfArM must evaluate the applied DiGA within three months
.
Through the review of the relevant product quality statements (such as data protection, interactivity and user experience), and the evaluation of the medically beneficial evidence of the corresponding application software application (the application's impact on the possibility of improving the user's health or dealing with their diseases), BfArM will determine whether its DiGA application is approved
.

Information contained in the DiGA catalog

The approved DiGA will be listed in a special DiGA catalog, and it will ensure that all participants in the German medical system can obtain useful information from it
.
This series of information not only includes information about the benefits of DiGA listed in the catalog and medical insurance payment related information, but also includes software data protection and compliance information for medical device regulations
.
This information can be divided into five categories
.

The main information contained in the DiGA catalog

The difference between DiGA formal approval and provisional approval

Developers need to decide whether to apply for formal approval or temporary approval when applying for DiGA
.
To a large extent, this depends on whether the applicant can provide medically beneficial and comparable clinical data of DiGA
.

If the clinical trials related to DiGA that are beneficial to medical care and comparable have been completed at the time of application, you can apply for formal approval
.
If the clinical trial data is approved, BfArM will complete the approval and list it in the catalog within 3 months from the date of application
.

If for some reasons (such as the application of medically beneficial clinical research is not recognized), the first application for formal approval fails, the applicant needs to apply again after 12 months from the date of rejection of the approval, and must submit new data
.
Applicants cannot immediately apply for provisional approval because the formal application is rejected and reverted
.

Of course, if the applicant withdraws the application before BfArM makes the final decision, he will not suffer this bad luck
.
Therefore, in the current approval status disclosed by BfArM, nearly half of the applicants have voluntarily withdrawn their applications
.
BfArM recommends that if the applicant is unable to determine whether the medically beneficial research that he is about to submit can meet the needs, he can consult in advance
.

If the applicant has not completed a comparable clinical trial, he can apply for provisional approval
.
The provisional approval requires the completion of comparable clinical trials during the probation period and the submission of corresponding evidence that DiGA is beneficial to medical treatment
.
The probation period is determined by BfArM, and the longest period shall not exceed 12 months
.
BfArM will decide whether to transfer the current provisional approval to a formal approval within 3 months after receiving the clinical data
.

If you fail to provide a comparable clinical trial report that is beneficial to medical treatment by DiGA within the prescribed time limit or the report fails to pass the review
.
BfArM will cancel the provisional approval of the software application and remove it from the catalog
.
Once removed from the catalog, the developer can only submit a new application 12 months from the date of removal, and must provide clinical data that is different from the previous one
.
Applications submitted based on duplicate clinical data will be rejected
.

Generally speaking, the medical insurance payment obtained by the provisional approval is lower than the formal approval
.
When applying for provisional approval, the applicant needs to negotiate with the medical insurance to determine the maximum payment in the first year once the formal approval is completed; at the same time, the applicant also needs to provide a lower price limit for the trial period
.
In addition, the developer can obtain the payment provided by the medical insurance according to the law during the DiGA temporary approval trial period, but the expenses required for the clinical research conducted in the same period need to be paid by the developer
.

It is worth mentioning that BfArM emphasizes that it only approves the software application itself, once approved, it can get medical insurance payment
.
As for whether the approved DiGA has different business models (such as a common free advertising model) version at the same time, it does not affect the approval
.

In individual cases, there is at most one opportunity to extend the trial period for provisional approval
.
The extension of the probation period is determined by BfArM and can be up to 12 months
.
Only when the clinical data of DiGA has been submitted in accordance with regulations and BfArM judged by the data is very likely to be beneficial to medical treatment, but the conclusion and report have not been completed at this time, it is possible to obtain the opportunity to extend the trial period
.
If applicants apply for an extension of the probation period, they must apply at least 3 months before the end of the original probation period to allow sufficient time for review
.

Evidence that DiGA is beneficial to medical care is the decisive factor for approval

In the BfArM guidelines, the materials required for DiGA approval are clearly listed, including a list of software applications that meet the requirements of DiGA approval, descriptions of the security and applicability of software applications, data protection, information security, interactivity, and further quality Request
.

Meeting these needs is not difficult for the vast majority of applicants
.
Therefore, the key to determining whether a software application can be upgraded to DiGA through approval is whether the evidence submitted by the applied software application that it has a positive impact on medical care is convincing
.

How to define "Evidence that DiGA is beneficial to medical care"?

"The fifth part of the German Social Code: Statutory Health Insurance" has a corresponding definition of "Evidence that DiGA is beneficial to medical care"
.
DVG and DiGAV further clarify the definition: evidence that is beneficial to medical care can be reflected in medical benefits, and can also be reflected in the structure and process improvement of patient-related medical services
.
The software application needs to prove that DiGA has at least one medically beneficial evidence
.

The benefits of medicine are mainly reflected in the improvement of the user's health status, shortening the time of illness, extending the life span, and improving the quality of life
.
The materials must be based on the patient’s perspective, with particular emphasis on the reduction of patient morbidity and mortality, or the improvement of the quality of life
.

The improvement of the structure and process of patient-related medical services is the basis of payment for the German medical insurance system
.
These improvements mainly include the following parts: part of disease diagnosis, monitoring, treatment or alleviation, diagnosis, treatment, alleviation or compensation of physical and psychological injuries or physical defects; used to support patients to form healthy living habits, or to integrate medical institutions and patients Medical procedures; as well as specific implementation guidance and standards that include the coordination of treatment procedures to ensure treatment effects; reduce the difficulty of accessing relevant medical services; reduce the inconvenience of patients in daily life due to diseases or reduce the workload of patients and their families in treating diseases
.

In principle, DiGA should be able to improve its position in medical care by obtaining information, directly participating or assisting in decision-making, and reducing the consumption of resources by treatment through the means provided by DiGA
.

In DiGA approval, the aforementioned two aspects of evidence must be provided
.
In addition, applicants can also submit potential medical benefits that cover two areas-under certain conditions, it may have a positive impact on future medical insurance payments
.
This is not a mandatory requirement, it is entirely up to the applicant to decide, but once they choose to provide, the relevant application materials still need to comply with relevant regulations
.

Use ICD-10 to define the patient population for DiGA

BfArM requires that DiGA applications must clearly define the applicable patient groups, and its medically beneficial data must be obtained from at least one defined applicable patient group
.
Certified doctors can only issue DiGA prescriptions for these patient groups and receive payment from medical insurance
.

BfArM requires ICD-10 codes to define and distinguish applicable patient groups
.
Therefore, once approved, DiGA can directly seamlessly connect with various information systems (such as DRG, outpatient payment, etc.
) that use ICD codes, and make specific distinctions between applicable patient groups
.
For example, in this way, it is clear at a glance whether a certain DiGA is suitable for all patients with type 2 diabetes or those with specific complications of type 2 diabetes
.

From here, we can also see that the importance of German medical care to the information system does cover all aspects and has good operability, which is quite worthy of our country's reference
.

Comparable clinical evidence

In order to prove that the applied software application is beneficial to medical treatment, the developer must issue the results of a controlled experiment to prove that using the applied software application will produce better results than not using the application
.
The experiment should use the applied software application as part of the patient group treatment; the control group uses a variety of control methods (such as no treatment, no application software during treatment, or other approved DiGA used in treatment) as a comparison
.

According to specific needs, research can be either clinical research or epidemiological research
.
In addition, as long as it is suitable for the selected field and is a quantitative comparative study, the use of research methods designed for other scientific fields (such as medical research, social research, or behavioral research) also meets the requirements
.
Among them, real-world research data is allowed
.

These studies must meet the requirements of DiGA approval in many aspects
.
First, the research carried out must be carried out in Germany
.
Of course, in individual cases, if comparative evidence for applicable medical scenarios can be provided, data obtained outside of Germany can also be recognized
.

Second, controlled studies must be registered with compliant public research institutions
.
Compliance means that the registrar must be the main registrar or partner organization of the WHO International Clinical Trial Registration Platform, or the data provider of the platform
.
In Germany, this institution generally refers to the German Clinical Research Registration Organization (DRKS) under BfArM
.
Completed clinical data can also be submitted here
.

Third, research should comply with relevant internationally recognized standards so that it can be used for display and research purposes in the future
.
Applicants need to submit at least one retrospective comparative study, such as a case-control study, retrospective cohort study or intra-individual comparative study
.
At any time, the applicant can submit a prospective comparative study, that is, a study with a fundamentally higher level of evidence
.

Third, the research data needs to be published publicly and comply with the publishing specifications of related papers
.
The corresponding data submission also needs to be submitted in accordance with the requirements of BfArM
.
For example, BfArM requires that the negative data in clinical research needs to be disclosed; and the corresponding clinical research data needs to be handed over to BfArM before it has not been publicly released and is recognized by the clinical research registry
.

Information required for provisional approval

Compared with formal approval, provisional approval does not require the submission of medically beneficial research data, but applicants still need to reasonably explain that DiGA can achieve at least one potential medically beneficial impact for a specific patient group
.
Applicants can submit system literature and evaluation, or system evaluation data provided by software applications
.
BfArM will use this as a basis to determine whether it can support the provisional approval
.

Applicants are also required to submit an evaluation plan based on generally accepted scientific standards, in which data evaluation results need to be appropriately considered
.
Among them, there should be at least one document provided by a third-party independent scientific research institution explaining the medically beneficial evidence required for the formal approval of the designed scheme
.
Of course, the third-party independent scientific research institution must have no conflict of interest with the applicant, but can receive corresponding remuneration according to market standards
.

As mentioned earlier, DiGA, which has passed the provisional approval, can apply at most once to extend the trial period up to 12 months to meet the needs of clinical research
.
Of course, this situation can only happen when BfArM judges that it is very likely to be beneficial to medical treatment based on existing data
.

When applying for an extension of the probation period, the applicant must also provide justified reasons to explain why the medically beneficial evidence could not be provided in the first phase of the experiment.
At the same time, if required, it may also provide a valid reason to explain why the extension of the probation period can produce actual missing Evidence
.

In the most fortunate case, the provisionally approved DiGA may get a total of 24 months of trial period
.
However, since many DiGAs have effects by subtly changing the user's living habits, some people still think that it may be difficult to prove that it is beneficial to medical care in just two years
.
In this regard, BfArM pointed out in the guide that, in principle, research can be started before applying for DiGA to effectively solve this problem
.

Write at the end

At present, Germany has taken the lead in providing detailed approval guidelines for digital therapy, as well as special rapid approval
.
Dr.
Suyuan Chen and Ms.
Zuo Simin believe that, compared with the approval of digital therapy in other countries or regions, the rapid approval process of DiGA in Germany is comprehensive, fast and professional
.

The first is comprehensiveness.
Although most countries or regions have some laws and regulations related to medical and health applications, no one can provide such a detailed approval process from legislation to rules, and even covering various exceptions
.
From this point of view, the comprehensiveness and completeness of the German DiGA approval process is second to none
.

The second is a fast approval process
.
The German DiGA approval fully takes into account the rapid update of software applications, and the approval can be completed within 3 months after the application (if all the information is complete)
.
This is a big plus for many small and medium-sized enterprises, which can greatly reduce time and money costs
.

Again, it is professionalism
.
The German DiGA approval especially considers the medical attributes of digital therapy.
It regards medically beneficial evidence as the most critical supporting material, and puts forward more stringent conditions from research design to final submission to ensure that the approved DiGA can indeed treat patients.
Your health is helpful
.

"Compared with Spain and the United Kingdom, they did not separate medical APPs from medical devices for approval, and even the United States did not have a corresponding special process
.
I think this is a very innovative move in Germany
.
" Dr.
Chen Suyuan believes that this is the German DiGA One of the biggest features of approval
.

Finally, payment is convenient
.
Once approved, DiGA can quickly enter the market based on the completeness of its pre-preparation support work (even providing indication ICD codes), and certified doctors can write prescriptions for patients with indications and pay by medical insurance
.

Digital therapy has always been concerned and controversial since its inception.
The root of the controversy comes from whether it is beneficial to medical treatment
.
The public's misgivings that have arisen have also raised the real question of who will pay
.
The approval of digital therapy in Germany represents a solution, that is, by defining it as a special medical device, conducting targeted and strict approval, and including the medical insurance payment after approval, so as to dispel public concerns
.
This kind of thinking may be worth learning from our country
.