Maintenance Notice

Due to necessary scheduled maintenance, the JMIR Publications website will be unavailable from Wednesday, July 01, 2020 at 8:00 PM to 10:00 PM EST. We apologize in advance for any inconvenience this may cause you.

Who will be affected?

Advertisement

Citing this Article

Right click to copy or hit: ctrl+c (cmd+c on mac)

Published on 26.06.20 in Vol 8, No 6 (2020): June

This paper is in the following e-collection/theme issue:

    Viewpoint

    Medical Device Apps: An Introduction to Regulatory Affairs for Developers

    Department of Pharmaceutical Biosciences, Uppsala University, Uppsala, Sweden

    *all authors contributed equally

    Corresponding Author:

    Ulrika SH Simonsson, MSc, PhD

    Department of Pharmaceutical Biosciences

    Uppsala University

    Box 591

    Uppsala, 75124

    Sweden

    Phone: 46 18 471 4000

    Email: Ulrika.Simonsson@farmbio.uu.se


    ABSTRACT

    The Poly Implant Prothèse (PIP) scandal in France prompted a revision of the regulations regarding the marketing of medical devices. The new Medical Device Regulation (MDR [EU]) 2017/745 was developed and entered into force on May 25, 2017. After a transition period of 3 years, the regulations must be implemented in all EU and European Economic Area member states. The implementation of this regulation bears many changes for medical device development and marketing, including medical device software and mobile apps. Medical device development and marketing is a complex process by which manufacturers must keep many regulatory requirements and obligations in mind. The objective of this paper is to provide an introduction and overview of regulatory affairs for manufacturers that are new to the field of medical device software and apps with a specific focus on the new MDR, accompanying harmonized standards, and guidance documents from the European Commission. This work provides a concise overview of the qualification and classification of medical device software and apps, conformity assessment routes, technical documentation, clinical evaluation, the involvement of notified bodies, and the unique device identifier. Compared to the previous Medical Device Directive (MDD) 93/42/EEC, the MDR provides greater detail about the requirements for software qualification and classification. In particular, rule 11 sets specific rules for the classification of medical device software and will be described in this paper. In comparison to the previous MDD, the MDR is more stringent, especially regarding the classification of health apps and software. The implementation of the MDR in May 2020 and its interpretation by the authorities will demonstrate how app and software manufacturers as well as patients will be affected by the regulation.

    JMIR Mhealth Uhealth 2020;8(6):e17567

    doi:10.2196/17567

    KEYWORDS



    Introduction

    Due to safety issues in the field of medical devices, and especially after the Poly Implant Prothése (PIP) scandal in France, the Medical Device Directive (MDD) 93/42/EEC [1] was revised and replaced with the new Medical Device Regulation (MDR [EU]) 2017/745 [2,3]. The MDR entered into force on May 25, 2017 and must be implemented within the European Union (EU) and European Economic Area (EEA) states after 3 years, by May 26, 2020 [2]. Since the MDR is a regulation, it is immediately enforceable as law in all member states after its implementation date. This contrasts with the previous MDD, which was a directive that member states transpose into national law within a set timeframe [4].

    Unlike the US Food & Drug Administration, which regulates foods, medicines, and medical devices, the European Medicines Agency (EMA) regulates only drugs. There is no regulatory body like the EMA for the review and approval of medical devices. Manufacturers themselves declare conformity of their devices with the European legislations and regulations and affix a CE (Communauté europeénne) mark (Article 10 and 20 MDR). Products that bear a CE mark can then be marketed within the EU/EEA (Articles 2 and 10 MDR). Affixing the CE mark to a product is only legal after a conformity assessment has been performed (Article 20 MDR). Depending on the class of the device, a notified body must be involved in this process (Introduction [60] and Articles 52-53 MDR). For certain highly critical or novel products, an additional examination by so called “expert panels” is mandatory (Introduction [56] and Article 106 MDR).

    Independent of the risk class, technical documentation (TD) must be compiled to allow an assessment of whether the general safety and performance requirements set by the MDR are met (Annex II MDR). With the exception of class l devices, the notified bodies then inspect the manufacturer’s Quality Management System (QMS) and technical documentation and subsequently issue the required Annex certificates (Annex XII MDR). These are prerequisites for declaring conformity and affixing the CE mark (Article 10[6] MDR). For guidance on how to perform the steps required for CE marking, including risk management, technical documentation, and QMS, and to prove regulatory compliance, manufacturers are advised to work according to harmonized standards and common specifications (Articles 8-9 and Annex II [4c] MDR). When the MDR came into force in 2017, there was no associated harmonized standard or common specification. According to the European Commission, these will be implemented soon [5].

    When developers of software or mobile apps claim that their product has a medical purpose, it becomes a medical device and must bear a CE mark (Article 2[1] MDR). This paper describes the process of placing mobile apps and software on the market as medical devices (Figure 1) and serves as an introduction to regulatory affairs for app and software developers.

    Figure 1. Important stages of medical device development.
    View this figure

    Elements of the Medical Device Regulation

    The primary elements of the new Medical Device Regulation (MDR [EU]) 2017/745 and the accompanying harmonized standards and guidance documents provided by the European Commission are described below.

    Qualification of Mobile Apps and Software: What Constitutes a Medical Device?

    Medical Device Software

    Mobile apps and software that are independent of any device and are not intended to be used as an accessory to a medical device are referred to as Medical Device Software (MDSW) or standalone software [6] and must be qualified and classified in their own right (Annex VIII [3.3] MDR).

    Intended Purpose

    The first, essential question an app or software developer must answer is whether the product is a medical device or not. Software qualifies as a medical device if the developer’s stated purpose of the software meets the definition of a medical device in Article 2[1] of the MDR (Textbox 1).


    Textbox 1. Medical device definition [Article 2(1) MDR].
    View this box

    The decision of whether a software product qualifies as a medical device is made by the developer or, using the terminology of the MDR, the manufacturer (Article 2[30] MDR). If the manufacturer states that the system can be used for a medical purpose, it must be CE marked (Articles 10 and 20 MDR). Whether a product qualifies as a medical device is determined by the intended use, as stated by the manufacturer and the mechanism of action of the product, not the design or user [6]. Furthermore, the description of the intended purpose must include a statement of benefit for the patient, otherwise it cannot be marketed as a medical device (Articles 61-62, Annexes XIV and XV MDR).

    Key Characteristics for Qualification as a Medical Device

    If a mobile app or software performs an action on data beyond storage, archiving, communication, or simple search; the performed action is for medical purposes; and the performed action is for the benefit of an individual patient, it most likely qualifies as a medical device and is subject to the MDR [6]. For further guidance on qualification of standalone software, see “MEDDEV 2.1/6 Guidelines on the qualification and classification of standalone software” [7].

    Classification of Standalone Software Including Apps

    The MDR defines four risk classes: I, IIa, IIb, and III (Table 1). For classification of software, rule 11 has been included in the regulation (Textbox 2) (Annex VIII MDR).

    Table 1. Summary of differences between risk classes.
    View this table

    Textbox 2. Rule 11, Annex VIII MDR.
    View this box

    This rule implies that many apps might have to be classified as class IIa, IIb, or III in the future, while under the former Medical Device Directive (MDD) 93/42/EEC most standalone software including apps were classified as class l or not designated as medical devices at all [1]. Interpreting rule 11 on its own indicates that, for example, software used to calculate dosages of drugs with high toxicity, suggesting a diagnosis, or aiding with therapy or radiation planning will fall within class III, since a mistake might cause death. If it is highly unlikely that death could be caused by an error, it could fall within class IIb, which is defined as a device for which “…a mistake can cause serious deterioration of a person’s state of health...” (Annex VIII MDR). Medical device software may only fall under class IIa if a mistake cannot be anticipated to cause serious deterioration of a person’s state of health. Medical device software may fall under class I only if it is not intended to provide information used to make decisions for diagnostic or therapeutic purposes. For class I devices, no notified body is involved in the declaration of conformity.

    These classification criteria are very stringent and prompted formation of the Medical Device Coordination Group (MDCG), an official working group serving to advise the European Commission regarding medical devices [8]. The group recently released a guidance document that further elaborates rule 11 [6]. The guidance provides examples on how to classify software, and the authors seem to interpret rule 11 less strictly than an original reading of the MDR would suggest. The document suggests for instance that software “intended to rank therapeutic suggestions for a health care professional based on patient history, imaging test results, and patient characteristics…, should be classified as class IIa...”. If one merely reads rule 11, one could conclude that these types of software would fall within class III, since an error might cause death. This guidance is not legally binding [6] but notified bodies might consider it when making their decision.

    Conformity Assessment Routes

    Fulfilling the “General safety and performance requirements” described in Annex I of the MDR is the most crucial step on the long road to marketing a medical device. To prove compliance with these requirements, manufacturers must follow one of the conformity assessment procedures described in the MDR appendices. Typically, manufacturers apply harmonized standards, and in the future also common specifications, to prove compliance with these requirements (Articles 8-9 and Annex II [4C] MDR). Examples of general safety and performance requirements include risk management, software lifecycle processes, software verification and validation, and usability (Annex I MDR). A complete list of requirements can be found in Annex I of the MDR.

    Conformity assessment is a process demonstrating whether the “general safety and performance requirements” of the MDR (Annex I MDR) have been fulfilled. Once the conformity of the medical device with the requirements has been proven, the manufacturer may declare the conformity, CE mark and market the product within the EU/EEA (Articles 19-20 MDR). Depending on the risk class, the MDR describes three different paths of conformity assessment in accordance with Annexes IX, X and XI (Article 56 MDR). Besides the four main risk classes (I, IIa, IIb, III), the MDR defines three sub-classes for risk class I, which are devices with measuring function (Im), sterile devices (Is) and reusable surgical instruments (Ir). For classes Im, Is, Ir, IIa, IIb and III, a notified body must be involved in the process of conformity assessment. This is not required for all remaining devices falling within class l (Articles 52-53 MDR). For risk class III, an additional expert panel will scrutinize the clinical evaluation and assess whether the clinical data is sufficient to provide confidence in the safety and performance of the device (Annex IX MDR). For medical device software, the development process cannot be ignored since it is difficult to find errors by simply testing the finished product, which would be the case in the Annex XI (Part B) conformity assessment. In contrast, the procedure described in Annex IX includes an assessment of the QMS and the technical documentation by a notified body. The product of a successful assessment is an Annex IX certificate and an EU QMS certificate for the manufacturer, who can then declare conformity of the medical device with the requirements set by the MDR (Articles 19 and 56 MDR).

    Technical Documentation

    According to the “general obligations of manufacturers” (Article 10[4] MDR), technical documentation must be compiled and kept up to date to enable assessment of compliance with the safety and performance requirements set by the MDR. Annex II of the MDR lists in detail what is required in the documentation, including documentation of a fully implemented risk management system, benefit-risk analysis, clinical evaluation report, software life cycle file, usability file, and many other requirements.

    Clinical Evaluation

    The supporting documentation for the CE declaration must include a clinical evaluation. This is an evaluation of side effects and the acceptability of the benefit-risk ratio based on clinical data (Article 61 MDR). Conducting a proper clinical evaluation will demonstrate (1) which clinical data are necessary; (2) which clinical data can be adequately supplemented by methods other than clinical investigations, such as published literature, prior clinical investigations, clinical experience, or by using suitable clinical data from equivalent devices; and (3) which clinical data remain to be delivered by clinical investigations (Article 61 MDR). Clinical investigations within the MDR are what many people would refer to as “clinical trials” and are defined as “systematic investigation involving one or more human subjects, undertaken to assess the safety or performance of a device” (Article 2[45] MDR). It is one of the methods to obtain clinical data supporting treatment efficacy and to confirm clinical benefit (Article 62 MDR). If sufficient clinical data to perform a clinical evaluation can be retrieved from the literature or other sources, the manufacturer can proceed without a clinical investigation. The clinical evaluation must be updated frequently with data from post-market surveillance. New data, as well as considerations for new or changed intended purposes, require an updated clinical evaluation and may indicate the necessity for additional clinical investigations (Article 61 MDR).

    The clinical evaluation must be planned, conducted, and documented. The clinical evaluation, its results, and the clinical evidence derived from it must be documented in a clinical evaluation report and included as part of the technical documentation (Annexes II and XIV MDR[9]). Furthermore, a clinical evaluation plan must be elaborated and documented in the technical documentation (Annexes II and XIV MDR).

    Regulatory Requirements for the Clinical Evaluation

    App developers are advised to follow the regulations and guidelines listed in Textbox 3.


    Textbox 3. Regulations and guidelines related to the clinical evaluation.
    View this box
    When Must a Clinical Investigation Be Undertaken?

    A clinical investigation is always mandatory for class III devices, regardless of the amount of information that can be retrieved from other sources (Article 61[4] MDR).

    Depending on clinical claims, the outcome of risk management, and the results of the clinical evaluation, clinical investigations may also have to be performed for nonimplantable medical devices classified as I, IIa, and IIb. In addition, a clinical investigation must be conducted if there was no sufficient pre-existing clinical investigation data or scientific literature on which to base a clinical evaluation (Article 61 MDR).

    Clinical investigations are only to be performed when the information necessary on device performance, safety, and clinical benefit cannot be obtained in any way other than by testing the device on humans (Articles 61,62 MDR).

    Notified Bodies

    Notified bodies must be involved in the conformity assessment procedures for device classes Is, Im, Ir, IIa, Ib and III (Articles 52,53 MDR). A notified body is an organization designated by national authorities to assess the conformity of certain products with the appendices of the MDR, harmonized standards, and common specifications before being placed on the market. Manufacturers can freely choose between notified bodies that have an expertise in the relevant product area [9]. An official list of notified bodies can be found on the European Commission’s website [10].

    What are Common Specifications?

    The MDR introduces the concept of “Common Specifications” (CS), which are similar to the already existing harmonized standards (Figure 2). In cases where there are no applicable harmonized standards, insufficient harmonized standards, or where there is a need to address public health concerns, common specifications must be followed in order to demonstrate device compliance with the requirements set by the MDR (Article 9 MDR). One should be aware of this concept since according to Article 9 those CS must be followed. Even when there are no CS available, it is important to stay up to date on developments.

    Figure 2. Common specifications and harmonized standards.
    View this figure

    Software Life Cycle

    Software development must follow the principles of a software life cycle (Annex l [17.2] MDR). A software life cycle consists of software development and validation/verification, software maintenance, problem resolution, risk management, and configuration management [11]. Compliance with International Standards Organization (ISO) standard IEC 62304 (Medical device software - Software life cycle processes) meets the requirements of the MDR [11].

    Unique Device Identifier

    The Unique Device Identifier (UDI) system was first introduced by the US Food and Drug Administration (FDA) [12] and will also apply to the EU market once the MDR is in force (Article 27 and Annex VI MDR). The UDI-number is linked to the European database of medical devices (EUDAMED), contains all relevant information about a medical device, and is used to identify every device (Articles 27 and 33 MDR). This system has been developed to help track each device, react quickly in case of a serious incident, and prevent marketing of illegal devices (Introduction [41] MDR). This should improve vigilance and consequently patient safety [13]. The UDI code must be affixed as a 2D/Data matrix code, inter alia, ID/linear barcode or radio-frequency identification (RFID), and in a human readable interpretation (HRI) format. The manufacturer must place the UDI on every single product. In case of medical device software and apps, the UDI must be stated within the software, such as in the “about” file or the start-up screen. A medical device for clinical investigation must not have a UDI (Annex VI MDR). According to Article 27 of the MDR, the manufacturer shall keep an updated list of all UDIs as part of the technical documentation. The UDI will be assigned by organizations established for this purpose (Article 27 MDR). Further information can be found in Articles 27-28 and Annex VI (Part C) of the MDR. A guidance document on how to create the UDI database and which data format should be used has been provided by the EU UDI Work Group [14].

    Basic-UDI-DI

    The Basic UDI-DI is the primary identifier of a device model in EUDAMED and must be referenced in relevant certificates and the EU declaration of conformity. This number will not be affixed to the product. Similar products with the same purpose, such as those that only differ in user interface language, will carry the same Basic-UDI-DI (Part C of Annex VI MDR).

    UDI-DI

    The UDI-DI is the identifier specific to a device and manufacturer. Software with different user interface languages must carry different UDI-DIs. This part of the UDI is fixed (Part C of Annex VI MDR).

    UDI-PI

    The UDI-PI is the product identifier used to mark a production series of a device (eg, batch, serial number, software identification) and is affixed to every single product. Each software version has its own UDI-PI. This part of the UDI is variable (Part C of Annex VI MDR). For software, not every single installation/download will have its own UDI-PI, but each version of the software does require it.

    When is a New UDI-DI Needed?

    A new UDI-DI is needed in the cases presented in Textbox 4.


    Textbox 4. Situations in which a new UDI-DI is needed for apps or medical device software (Part C of Annex VI MDR).
    View this box
    When is a new UDI-PI needed?

    A new UDI-PI is necessary after minor software revisions such as bug fixes, usability enhancements (those that are not for safety purposes), security patches, or operating efficiency (Part C of Annex VI MDR).


    Conclusion

    While the implementation of the new, more stringent MDR might lead to the development of more high-quality apps and improved patient safety, it might also limit the development and release of new apps and software on the market. The classification of a device as class IIa or higher requires evaluation by a notified body, which can be very costly and therefore a barrier to entry for app developers. Whether the new MDR and especially rule 11 is a blessing or a curse for app developers will depend on authorities’ interpretation of the guidelines and can only be evaluated after implementation in May 2020.

    Authors' Contributions

    LK and USHS conducted the analysis and interpretation of the regulatory framework for medical device development and wrote and revised the manuscript.

    Conflicts of Interest

    None declared.

    References

    1. OJ L 169, 12.7. 1993. Council Directive 93/42/EEC of 14 June 1993 concerning medical devices   URL: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:31993L0042 [accessed 2019-12-01] [WebCite Cache]
    2. OJ L 117. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, amending Directive 2001/83/EC, Regulation (EC) No 178/2002 and Regulation (EC) No 1223/2009 and repealing Council Directives 90/385/EEC and 93/42/EEC. 2017 May 05.   URL: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32017R0745 [accessed 2019-11-15]
    3. Rott P. Certification of Medical Devices: Lessons from the PIP Scandal. In: Rott P, editor. Certification – Trust, Accountability, Liability. Studies in European Economic Law and Regulation. Cham: Springer; 2019:978-973.
    4. Miller V, Gadd E. Briefing paper. The European Union: a guide to terminology, procedures and sources.: House of commons library; 2016.   URL: https://researchbriefings.parliament.uk/ResearchBriefing/Summary/SN03689 [accessed 2019-11-24]
    5. CAMD Implementation Taskforce. Medical Devices Regulation/In-vitro Diagnostics Regulation (MDR/IVDR) Roadmap.: Competent Authorities for Medical Devices (CAMD); 2018.   URL: https://www.camd-europe.eu/wp-content/uploads/2018/05/NEWS_171107_MDR-IVDR_RoadMap_v1.3-1.pdf [accessed 2019-12-02]
    6. Medical Device Coordination Group (MDCG). Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR. 2019 Nov.   URL: https://www.droit-technologie.org/wp-content/uploads/2019/11/Guidelines-MDSW.pdf [accessed 2019-12-01]
    7. European Commission. MEDDEV 2.1/6 - Guidelines on the qualification and classification of standalone software used in healthcare within the regulatory framework of medical devices. 2016 Jul.   URL: https://ec.europa.eu/docsroom/documents/17921/attachments/1/translations [accessed 2019-11-20]
    8. European Commission. Register of Commission expert groups and other similar entities. 2018.   URL: https://ec.europa.eu/transparency/regexpert/index.cfm?do=groupDetail.groupDetail&groupID=3565 [accessed 2019-11-20]
    9. European C. Internal Market, Industry, Entrepreneurship and SMEs. 2016. Notified bodies   URL: https://ec.europa.eu/growth/single-market/goods/building-blocks/notified-bodies_en [accessed 2019-12-01]
    10. European Commission. Internal Market, Industry, Entrepreneurship and SMEs. Notified bodies NANDO   URL: https://ec.europa.eu/growth/tools-databases/nando/index.cfm?fuseaction=country.main [accessed 2019-12-02]
    11. ISO. IEC 62304:2006 Medical device software — Software life cycle processes. 2006.   URL: https://www.iso.org/standard/38421.html [accessed 2019-11-25]
    12. FDA. Unique Device Identification System (UDI System). 2019.   URL: http:/​/www.​fda.gov/​medical-devices/​device-advice-comprehensive-regulatory-assistance/​unique-device-identification-system-udi-system [accessed 2019-11-20]
    13. European U. Unique Device Identification (UDI) System under the EU Medical Device Regulations 2017/745 and 2017/746. 2019.   URL: https://ec.europa.eu/docsroom/documents/36664 [accessed 2019-12-01]
    14. EU UDI Work Group. UDI Database, Definitions/Descriptions and formats of the UDI core elements. 2018 Jan.   URL: https://ec.europa.eu/docsroom/documents/28669 [accessed 2019-12-03]


    Abbreviations

    CE: Communauté europeénne
    CS: Common Specifications
    EEA: European Economic Area
    EMA: European Medicines Agency
    EU: European Union
    EUDAMED: European Database on Medical Devices
    FDA: US Food and Drug Administration
    HRI: Human Readable Interpretation
    ISO: International Organization for Standardization
    MDCG: Medical Device Coordination Group
    MDD: Medical Device Directive 93/42/EEC
    MDR: Medical Device Regulation (EU) 2017/745
    MDSW: Medical Device Software
    PIP: Poly Implant Prothése
    QMS: Quality Management System
    RFID: radio-frequency identification
    TD: technical documentation
    UDI: Unique Device Identifier
    UDI-DI: Unique Device Identifier – Device Identifier
    UDI-PI: Unique Device Identifier – Product Identifier


    Edited by CL Parra-Calderón; submitted 20.12.19; peer-reviewed by FJ Sánchez-Laguna, E van der Velde; comments to author 22.02.20; revised version received 28.02.20; accepted 28.03.20; published 26.06.20

    ©Lina Keutzer, Ulrika SH Simonsson. Originally published in JMIR mHealth and uHealth (http://mhealth.jmir.org), 26.06.2020.

    This is an open-access article distributed under the terms of the Creative Commons Attribution License (https://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work, first published in JMIR mHealth and uHealth, is properly cited. The complete bibliographic information, a link to the original publication on http://mhealth.jmir.org/, as well as this copyright and license information must be included.