Nowadays, medical device standalone software plays a key role in the delivery of healthcare services within healthcare institutions. For instance, it may be used to monitor or control the performance of hardware medical devices remotely, for patient management activities, or in support for treatment planning.
Standalone software is a medical device when it is used for medicinal purposes and meets the definition of a medical device. Depending on the specific intended purpose, it may qualify as a medical device according to the Medical Device Regulation (MDR) or as an in-vitro diagnostic medical device according to the In Vitro Diagnostics Regulation (IVDR).
However, note that not all standalone software used in the healthcare sector are medical devices and need to get CE mark approval. For example, apps that record lifestyle habits usually don’t need to comply with the CE marking legislation. Only medical device standalone software covered by the MDR or IVDR can get CE marking before it’s being released for sale on the European market.
An efficient digital approach to CE marking medical devices based on expert guidance via web workshops and templates.
The article provides a general overview of the medical device regulatory process for manufacturers, as well as additional guidance specifically relevant to standalone software.
I. Overview of the CE certification process for medical device standalone software
All medical devices, hardware or software, placed on the European market must bear a CE mark. A manufacturer may affix the CE marking to their product after they demonstrate the product’s compliance with the essential product health and safety requirements of the relevant regulations. Medical device standalone software can be placed on the EU market by both European and non-European operators.
The following sections give an overview of the steps involved in the CE marking certification of medical devices:
- Qualify the product as a medical device or an accessory according to the MDR or IVDR
- Determine the correct risk class according to the MDR or IVDR
- Select of a relevant conformity assessment procedure
- Determine and fulfil applicable essential requirements
- Obtain certification:
- For class I: self-declare conformity
- For class II and III: submit required documentation to the Notified body to obtain certification
- Register the product in the EUDAMED
- Place the product on the market
- Post-market surveillance
II. Qualification of the standalone software
Medical device standalone software is any product that meets the definition of a medical device, in-vitro diagnostics medical device or active implantable medical device without being a part of a hardware medical device.
A manufacturer must demonstrate and define the intended purpose of their product in the product’s documentation (e.g. instructions for use and labelling). When determining the intended purpose, manufacturers must specify all the functions of the medical device standalone software. For example, if a user can perform many different calculations using the software, each calculation must be stated in the product’s documentation. Moreover, if a standalone software consists of several modules but not all have a medical purpose, the manufacturer may CE mark only the modules that meet the definition of a medical device. However, the manufacturer must take into consideration all the modules when qualifying their product as a medical device.
During the qualification phase, a manufacturer must also take into consideration the way the intended purpose of the standalone software is achieved. For instance:
- Is the software acting as an accessory to another medical device?
- Does the intended purpose benefit the individual patient? If so, what are the benefits?
- Does the definition of a medical device include the intended purpose?
- Is the intended purpose limited to storage, lossless compression, communication or a simple search?
A detailed overview of the process for qualifying standalone software as a medical device or an accessory is presented in the document ‘Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR’, issued by Medical Device Coordination Group (MDCG)
III. Risk classification of the medical device standalone software
Medical devices can be categorised into three main classes depending on the risk they bring to the patient: class I, II and III. Class I includes medical devices of low risk, while medical devices of class III have the highest risk. The guidance document mentioned above provides instructions on how to determine the risk classification of standalone software according to the MDR and IVDR.
However, if manufacturers have difficulty qualifying and classifying their standalone software according to the MDR or IVDR, they can get in touch with Clever Compliance’s team of certification experts.
IV. Select an appropriate conformity assessment procedure
In short, the conformity assessment procedure is the process that any manufacturer must follow to demonstrate the compliance of their medical device with the product health and safety requirements of the relevant European Regulations. The risk class of a product determines the conformity assessment procedure to be followed. And the manufacturer cannot follow a procedure relevant to another risk class.
However, manufacturers must note that a conformity assessment procedure involving only product testing is usually considered inappropriate for standalone software. That’s because the standard product testing doesn’t address all safety requirements of the medical device standalone software. Therefore, manufacturers should undertake a conformity assessment where any system failures eventually present in the standalone software can be adequately assessed.
- Class I medical device standalone software
The conformity assessment procedure for medical device standalone software class I, excluding software class I with a measuring function, is called EC Declaration of Conformity. The procedure doesn’t require the intervention of a Notified Body (NB). All that manufacturers need to do is compile a Technical file, have a Quality Management System in place and sign a Declaration of Conformity.
- All other standalone software
For any other medical device standalone software, incl. class I standalone software with a measuring function, the conformity assessment procedure depends on the risk classification. The European regulations (MDR and IVDR) state all conformity procedures relevant to such products. Usually, each of them requires the intervention of a Notified Body.
Note that the NB’s intervention is limited when it comes to assessing the conformity of class I software with a measuring function. The Notified Body only assesses the product’s compliance with the metrological requirements.
V. Determine and fulfil relevant essential requirements
A manufacturer is responsible for identifying all legal provisions relevant to their medical device standalone software. The MDR and IVDR state all requirements applicable to medical products. The following are examples of essential requirements pertinent to standalone software:
- Regarding the compatibility of the software: If the medical device is supposed to be used in combination with other medical devices or equipment, the whole combination, plus the connection system, must be safe and harmless and must not diminish the specified performances of the devices. The product label or instructions for use should indicate any restrictions on use.
- About the software’s validation: For medical devices, incorporating software or being medical device software themselves, the software has to be validated according to state of the art taking into consideration the principles of the development lifecycle, risk management, validation and verification.
Some specific essential requirements may not apply to standalone software at all — for example, chemical composition or biocompatibility.
When demonstrating conformity to the identified essential requirements, manufacturers must maintain documentation of all the solutions adopted.
VI. Technical documentation (aka Technical file)
A manufacturer must have a technical file that demonstrates the conformity of their standalone software with the respective provisions of the applicable regulations. The technical documentation includes various types of information related to the design, manufacture and CE conformity of the product. The appropriate conformity assessment procedure determines the types of information contained in the technical documentation.
The following sections cover some specific considerations for manufacturers of medical device standalone software:
Any medical device standalone software manufactured according to harmonised standards can benefit from the presumption of conformity to the relevant legal requirements. A manufacturer can choose whether to use harmonised standards or not. However, if they decide not to apply in full harmonised standards, then they will need to justify their decision and provide additional data detailing the solutions adopted to meet the relevant essential requirements. Some harmonised standards cover procedures that are relevant to all medical devices, while others are more directly relevant to standalone software.
Additionally, a manufacturer must maintain a list of all relevant harmonised standards applied in full or in part to their products. A complete and updated listing of all harmonised standards applicable to medical devices can be found on the European Commission’s website.
2. Design and maintenance of the standalone software
When designing and maintaining a medical device standalone software, a manufacturer should consider the principles of the lifecycle approach. This approach helps to ensure the safe design and maintenance of medical device software. Some harmonised standards provide a framework for a lifecycle approach. Key aspects considered within such a framework, and indicated in the product’s technical documentation, include:
- Medical device software design planning for ensuring repeatability, reliability and performance in line with the intended purpose,
- Software development planning (e.g. verification and validation plan),
- Software requirement analysis (e.g. software requirements and user)
- Implementation and verification of the software,
- Maintenance of the software (e.g. modification plan),
- Software configuration management (e.g. change control and management).
3. Risk management system
The risk management system is meant to help manufacturers:
- identify hazards associated with their medical device standalone software,
- estimate and evaluate the associated risks,
- have control over the risks and monitor the effectiveness of that control.
As overall, the risk management system helps ensure that any risks associated with the use of a specific medical device software are compatible with a high level of health protection and safety. Furthermore, the risks must be acceptable when weighed against the benefits to the medical device user. However, a manufacturer must always bear in mind that the nature of the clinical risk associated with their medical device standalone software may cause direct or indirect harm (e.g. misdiagnosis and delays in decision making) to the user.
The risk management system used should be appropriate to the complexity and risk class of the standalone software. Moreover, it should be based on international or other recognised standards. The risk management system should be integrated across the entire lifecycle of the medical device standalone software.
4. Clinical evaluation
The clinical evaluation is a requirement that applies to all medical devices, hardware and software, regardless of their risk classification. It must follow a well-defined and methodologically sound procedure that is based on one of the following:
- A critical assessment of the relevant scientific literature that is currently available and related to the safety, performance, design and intended purpose of the medical device. Here, a demonstration of equivalence of the device to the device to which the data relates is needed. The data should adequately demonstrate compliance with the applicable essential requirements.
- A critical evaluation of the outcomes of all clinical investigations performed.
- An assessment of the combined clinical data provided in both options above.
VII. Notified body assessment for medical device standalone software
In some cases, a Notified body will need to assess the medical device standalone software by reviewing its technical documentation and quality management system. Manufacturers of class I software can self-declare the compliance of their medical devices with the relevant legislation. However, manufacturers of class II and III products, as well as of class I software with measurement function, will need to pass a Notified body assessment.
A list of all Notified bodies designated to assess medical devices according to the MDR and IVDR is available in the Nando database.
VIII. Data protection and cybersecurity
Sometimes, a part of the functionality of the standalone software is to collect and store users’ health data. Where that’s the case, a manufacturer must ensure compliance with the relevant legislation concerning data protection.
All manufacturers should consider the security and protection of user data from the design stage of their standalone software.
To ensure data privacy, a manufacturer of medical device standalone software should:
- Describe minimum requirements on hardware, IT networks characteristics and IT security measures, incl. protection against unauthorised access.
- Implement security tools, such as data encryption and authentication mechanisms.
- Implement appropriate pre-market and post-market measures against cybersecurity attacks. Such measures should be taken during the device’s development and design phase. Additionally, manufacturers should have detailed cybersecurity risk management procedures and communication protocols for post-market use.
IX. Instructions for use and labelling
Any medical device standalone software placed on the EU market must be accompanied by information about the manufacturer and instructions for use (IFU). The potential users must be able to understand the IFU. The IFU is not required for medical devices of class I which can be used safely without it. In such cases, a justification for not providing IFU should be documented within the technical documentation. However, manufacturers of standalone software must take into account all aspects of the use of their software when considering the need for an IFU. E.g. system requirements, foreseeable medical emergencies, and downloading instructions.
Medical device standalone software can be made available to users in one of the following ways:
- On a disc that includes a copy of the instructions for use.
- Via download (e.g. mobile apps).
Whatever the way of distributing the standalone software is, manufacturers should:
- Ensure that the IFU is available to users, where required.
- Ensure that it’s clear to the users where they can access the IFU. (e.g. via a website or on the app itself)
- Consider the information provided with the standalone software, and the format it is supplied in, as part of the risk assessment of the medical device.
- Ensure that the label and the IFU are controlled within the documentation system.
National language requirements must also be taken into consideration when it comes to the product’s labelling and IFU.
X. Affixing the CE mark
Manufacturers of medical device standalone software must follow the instructions below when attaching the CE marking to their products:
- The CE marking has to be affixed to the product in a visible, legible and indelible form on the. If that’s not possible, then it must be put on its sterile pack, in the instructions for use, and on any sales packaging.
- The HPRA expects the CE symbol to be visible, at a minimum, on the home screen or landing page of the medical software.
- If a Notified body assessment is carried out, the CE marking must be accompanied by the identification number of the respective Notified body.
- It is illegal to affix marks that could mislead third parties about the meaning of the CE marking.
- Other marks may be affixed to the device if the visibility or legibility of the CE marking is not impaired.
- The format of the safety marking should comply with the regulations. In cases where the medical device is tiny, the minimum dimensions of the CE marking may be waived.
XI. Post-market surveillance of medical device standalone software
A manufacturer must have, and keep updated, a system allowing them to review users’ experience and implement corrective actions if needed. This type of system is called a post-market surveillance (PMS) system. It allows manufacturers to assess different kinds of information (e.g. customer feedback and complaints). The PMS system is required for all types of medical devices.
In the event of incidents involving their medical device standalone software, manufacturers must report to the competent authority.
XII. Registration in the EUDAMED
The European Database for Medical Devices (EUDAMED) is a database that will be used to monitor the safety and performance of medical devices under the Medical Devices Regulation (MDR) and the In Vitro Diagnostics Regulation (IVDR). The system will launch on March 25th, 2020.
Any medical devices placed on the EU market will need to be registered in the EUDAMED and have a Unique Device Identifier (UDI). Manufacturers entering data in the EUDAMED will be identified by their Single Registration Number (SRN). Each manufacturer will need to appoint at least one Local User Administrator (LUA) that can appoint users and authorise them to execute specific activities (e.g. entering, reviewing and uploading).
Additional information on the registration process can be found on the website of EUDAMED.
If you need help with any aspect of your medical device CE certification process, get in touch with Clever Compliance’s team of experts at [email protected]. We have helped countless small and large enterprises get CE marking approval for their medical devices. We facilitate the CE marking of medical devices significantly by allowing clients to do everything digitally, from the comfort of their home or office.
Additionally, we at Clever Compliance have also developed a product compliance management system that helps compliance officers and departments stay on top of their compliance work.