QA Medical Industry: Registering medical device standalone software on the EU market

Part Two

In the preceding part of the article, we have tried to provide a summary of the first steps that should be taken into the certification process for a Software as a Medical Device. The successive part of the path can be described as follows:

V. Technical documentation

Manufacturers must hold technical documentation that demonstrates the conformity of their standalone software with the respective provisions of the applicable Regulations/Directives. The product’s technical documentation, along with its Declaration of Conformity, must be presented to the HPRA for inspection.
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 with respects to the technical documentation for medical device standalone software:

1. Harmonized standards

Any medical device standalone software manufactured according to harmonized standards can benefit from the presumption of conformity to the relevant legal requirements. Products’ manufacturers can choose whether to use applicable harmonized standards. However, if they decide not to apply in full harmonized standards, then they will need to justify their decision and provide additional data detailing the solutions adopted to meet the applicable essential requirements.
Some harmonized standards cover procedures that are relevant to all medical devices, while others are more directly relevant to standalone software. Manufacturers must determine the harmonized standards applicable to their device.
Additionally, manufacturers must maintain a list of all relevant harmonized standards applied in full or in part to their products. A complete and updated listing of all harmonized standards applicable to medical devices can be found on the European Commission’s website.

2. Design and maintenance of the standalone software

Of importance is that when designing and maintaining a medical device standalone software, manufacturers consider the principles of the lifecycle approach. This approach helps to ensure the safe design and maintenance of medical device software. Some harmonized 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 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, manufacturers must always bear in mind that the nature of clinical risk associated with medical device 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 medical device. Moreover, it should be based on international or other recognized 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 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.
Detailed information on how to perform a clinical evaluation can be found in the guide MEDDEV 2.7/1 ‘Clinical evaluation: Guide for manufacturers and notified bodies.

VI. Data protection and cybersecurity

Sometimes, a part of the functionality of the standalone software is to collect and store users’ health data. Where this is the case, manufacturers must ensure compliance with the relevant legislation concerning data protection.
The security and protection of user data should be considered by all manufacturers from the design stage of their standalone software.
To ensure the data privacy, manufacturers of standalone software should:
• Describe minimum requirements on hardware, IT networks characteristics and IT security measures, including protection against unauthorized.
• 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 considered during the device’s development and design phase. Additionally, manufacturers should have detailed cybersecurity risk management procedures and communication protocols for post-market use.

VII. Instructions for use and labelling

Each medical device 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 consider all aspects of the use of their software when considering the need for an IFU. For example, system requirements, foreseeable medical emergencies, and downloading instructions.
There are different ways of standalone software being made available to users, such as:
• 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 medical 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, where also can be seen any changes to the IFU.
National language requirements must also be taken into consideration when it comes to the product’s labelling and IFU.

VIII. 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 must be placed in a visible, legible and indelible form on the medical device. 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 standalone.
• 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 which are likely to mislead third parties regarding the meaning of the CE marking.
• Other marks may be affixed to the device as long as 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 very small, the minimum dimensions of the CE marking may be waived.

IX. Manufacturer’s post-market surveillance

Manufacturers must have and keep updated a system allowing them to review users’ experience and to implement corrective actions if needed. This type of system is called post-market surveillance (PMS) system. It allows manufacturers to assess different types of information (e.g. customer feedback and complaints). The PMS system is required for all types of medical devices. However, manufacturers of standalone software must keep in mind when developing their PMS system that standalone software differs from the other types of medical devices in how it is made available to users and distributed. For example, manufacturers must be able to implement revisions to software that is already in use or the software design and functionality allow efficient reporting from users.
In the event of incidents involving their medical device standalone software, manufacturers must report to the competent authority. The same applies to the occurrence of certain events stated in the HPRA Guide to Vigilance System for Medical Devices.

X. Registration of persons placing devices on the market

Manufacturers of class I medical device standalone software, placed on the EU market, must register with the HPRA by:
• notifying the HPRA of their registered address, and
• providing the HPRA with a description of the medical device which is sufficient to identify it.

In this article, we have tried to provide an overview of the regulations, that should be considered in order to realize high-confidence certification process for a Software as a Medical Device. We have introduced the regulations currently in force in European Union. All such regulations share common elements such as the need for a classification system, a Quality Management System, a Risk Management framework, and certain verification and validation activities. However, they differ to a certain degree in imposing a few different requirements, making it impossible for a manufacturer to realize a Software as a Medical Device through a unique framework for all markets. The regulations, moreover, have been originally focused on traditional Medical Devices with the consequence that the application to software is not always possible or direct.