Reflection Paper on regulatory frameworks for digital health technologies in Europe

DIGITALEUROPE has developed this reflection paper on how the entry criteria for software into the Regulation on medical devices should be determined. Industry understands the importance to prioritise the health and safety of patients when using such devices; effective scrutiny procedures and a clear regulatory framework are therefore openly welcome. However, while we see digital health as promising leapfrog technology to advance human health, we are concerned that the European Union may delay market access compared to other regions, thereby depriving EU patients of the benefits of digital health highlights stated in the European Commission’s own strategy that was published last year. 

Therefore, this paper aims to help shed light on the complexity of borderline cases, particularly in the area of digital health, where it is difficult to determine how software can be identified for what category. 

This paper looks at other international markets as a reference point that could provide guidance on how to approach the problem. Looking to the US and Canada we recognise positive aspects to ensure patients are not at risk while at the same time maintaining the benefits and innovation these devices provide to improve their health. 

DIGITALEUROPE asks you to consider these points and open a dialogue with our members to provide an exchange of views and expertise. 

Problem statement on regulations of software 

The Regulations on medical devices and in vitro diagnostic medical devices draws up a new regulatory framework, including software, in the European Union. We recognise the process in clarifying how software is intended to be classified by drawing up specific guidance. Whereas the question remains open when software would be subject to regulations. 

DIGITALEUROPE would like to point out the uncertainty when making a determination, if software fulfils the definitions laid out in EU 2017/745 (MDR) Article 2(1) and EU 2017/746 (IVDR) Article 2(2). Some of the raised concerns are: 

a) Software used in healthcare to facilitate communication, archival, storage and retrieval of health data. 

b) Software fulfilling the definition of an in vitro medical device. 

c) Software used by healthcare professionals to apply publicly available guidance for aiding users in managing patients. 

Considerations of international software regulations 

United States of America 

With the introduction of the 21st Century Cures Act (Cures Act), the U.S. continued clarifying the borderline towards regulated software. It was made clear, that the following software, even when being used in healthcare, would not qualify as devices, while providing measures to adopt to the technical state of the art: 

– Administrative-support software 

– Health lifestyle software 

– Electronic patient records 

– Software to transfer, store or display test lab data and other device data 

– Clinical decision support software that is not intended to acquire, process, or analyse a medical image or a signal from an IVD or a pattern or signal from a signal acquisition system 

– Software for population health management 

In more detail, the following considerations were provided: 

a) For administrative support of a health care facility, including the processing and maintenance of financial records, claims or billing information, appointment schedules, business analytics, information about patient populations, admissions, practice and inventory management, analysis of historical claims data to predict future utilisation or cost-effectiveness, determination of health benefit eligibility, population health management, and laboratory workflow; 

b) For maintaining or encouraging a healthy lifestyle and is unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition; 

c) To serve as electronic patient records, including patient-provided information, to the extent that such records are intended to transfer, store, convert formats, or display the equivalent of a paper medical chart, so long as:

i. such records were created, stored, transferred, or reviewed by health care professionals, or by individuals working under supervision of such professionals; 

ii. […] 

iii. such function is not intended to interpret or analyse patient records, including medical image data, for the purpose of the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition; 

d) For transferring, storing, converting formats, or displaying clinical laboratory test or other device data and results, findings by a health care professional with respect to such data and results, general information about such findings, and general background information about such laboratory test or other device, unless such function is intended to interpret or analyse clinical laboratory test or other device data, results, and findings; or unless the function is intended to acquire, process, or analyse a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system. 

With regards to clinical decision support software, the U.S. FDA has drawn up draft guidance1 to clarify when such software would be covered by the medical devices’ regulation, and when not. The following considerations need to be answered “yes” in order to decide exempt on its regulatory status: 

(1) Not intended to acquire, process, or analyse a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system 

(2) Intended for the purpose of displaying, analysing, or printing medical information about a patient or other medical information 

(3) Intended for the purpose of supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition 

(4) Intended for the purpose of enabling such health care professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such health care professional relies primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient 

Canada 

Canada issued draft Guidance on the qualification and classification of Software as a Medical Device (SaMD) on 2019/01/232. DIGITALEUROPE believes that the Canadian regulatory framework is highly comparable with the European and in consequence should be considered for clarification. 

It has been Health Canada’s longstanding position that the following types of software do not meet the definition of a medical device and are therefore not subject to the Regulations: 

– Software intended for administrative support of a healthcare facility, 

– Software that enables clinical communication and workflow including patient registration, scheduling visits, voice calling, video calling, 

– Software intended for maintaining or encouraging a healthy lifestyle, such as general wellness apps, and 

– Software intended to serve as electronic patient records. 

In efforts to align regulatory processes for SaMD with other international jurisdictions, Health Canada has determined that various types of clinical decision support/patient decision support software may not meet the device definition – and therefore would not be subject to the Regulations – when it meets all of the four criteria outlined in the PDF file (download button above).

Proposals 

Software used in healthcare to facilitate communication, archival, storage and retrieval of health data 

Software which is intended to communicate, store, archive, and provides mechanism to retrieve selected or all data, including search functions for identifying the dataset to be retrieved should not fall under the indicated regulations. Rationale: the state of the art in technology does not justify requiring the CE mark on such software. 

In addition, software should not be considered fulfilling a medical intended purpose if it is intended to display data. 

With these exemptions drawn up, it should be evident that modification of such data for the purposes mentioned should also be exempt from the regulation. Rationale: The technical TCP/IP network protocol is based on fragmentation of an item into transmission unit and re-assembled at the recipients point. Fragmentation can, in this case, be considered as modification of data for purposes of transportation. 

Software fulfilling the definition of an in vitro medical device 

Software should be considered as in vitro medical device, in cases it is driving or influencing the use of an in vitro medical device. With this, the implementing rule 3.3 (MDR) and 1.4 (IVDR) would be applied not only to classification, but also to qualification of software. 

In addition, the intended purpose of a software should be the decisive factor in order to make a decision, which regulation is to be applied. This would require specific guidance asking for a precise formulation of the intended purpose in the technical documentation of the medical software. 

DIGITALEUROPE suggests taking the definitions of the medical device and in vitro medical device into account and building guidance around these principles. 

Software used by healthcare professionals to apply publicly available guidance for aiding users in managing patients 

DIGITALEUROPE believes the advancement of the technical state of the art should also be reflected in guidance answering which types of software should be regulated. We believe the mentioned exemption that are being established in Canada, and that are already established in the United States of America should also be taken into account in the European regulatory framework. 

Aligning to the political goals of the European Commission 

Our industry acknowledges the potential risks from technology and as a consequence industry heavily invests in the engineering process in addition to investing in the research phase in order to minimise identified risks. Regulation also plays a role to protect patients and provide important oversight. We firmly believe we can define these regulations to protect patients and deliver the benefits these technologies can also bring. We would like to share that our views correspond directly with the European Commission’s political goals. 

These include: 

General EC statements on benefits of mHealth: 

– Recognised as early in Green Paper on mHealth in 2014: mHealth can contribute to “the empowerment of patients as they could manage their health more actively”. As a source of data, “mHealth allows the collection of considerable medical, physiological, lifestyle, daily activity and environmental data” which could “serve as a basis for evidence-driven care practice and research activities, while facilitating patients’ access to their health information anywhere and at any time”. 

– 2018 Digital Health Strategy: By using digital solutions, such as wearables and mHealth apps, citizens can actively engage in health promotion and self-management of chronic conditions. This in turn can help control the rising demand for health and care. The strategy finds that the development of such pieces requires:

• commitment and knowledge of how to ensure such an investment leads to successful and cost-effective implementation of digitally-enabled, person-centred care solutions; 
• market conditions that can facilitate economies of scale for the suppliers of technology and services. 

– SWD accompanying the eHealth strategy recognizes that: “From a commercial point of view, another key challenge recognised is the difficulty of operators to identify the legal framework which is applicable to their product, as the borderline area between digital health solutions which are medical devices and those which are not is a complex one, involving in many cases very technical analysis and considerations.” 

CONCLUSION 

DIGITALEUROPE also acknowledges the benefits of bringing important technologies that can ultimately improve healthcare in the EU. We are looking to have a dialogue with government experts on what can be done to increase the market access for innovative small to medium sized technology developers to bring potential advancements for patient treatments. This could also include realising the potential of wearables in promoting low-risk app-based solutions. 

We encourage policymakers to reach out to those individuals developing these technologies.