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

Part One

In the health-care domain, over the years, software has become a pervasive technology, no longer confined to controlling traditional medical devices (e.g., radiology equipment).

Medical purpose software has been assuming increasing responsibilities by redefining classic health-care services or offering new facilities. It is now found on desktop and mobile devices to give health-care operators access to clinical information stored in large and distributed applications of electronic health records or to clinical decision support systems, wherever and whenever they need. Modern hospitals are, nowadays, supported by a variety of complex software systems able to ease and improve almost all clinical practices.

Pervasive healthcare is highly multifaceted, with many applications focusing on interoperability with the legacy hospital assets, the “traditional hospital”, the security and privacy of sensitive information and the usability of end users. The notion of smart hospitals is introduced when Internet of Things (IoT) components are supporting core functions of a hospital.

These are just a few examples of new classes of medical purpose software (software used to make clinical decisions) all of which—with a different “level of concern”—must be safe, dependable, reliable, and secure. A certain level of quality, of course, maybe a desired characteristic that medical purpose software producers would like to confer on their products in order to better compete on the market. However, this is not enough. Indeed, some of the previously described systems must be treated as medical devices themselves (referred as software as a medical device (SaMD) or medical device software) and, consequently, they must be designed, built, and maintained according to stringent regulations and standards. TQM and QMS principles are applicable to all kinds of organization and product, but it is important to note that a software system has features that make it special with respect to other products. It is not the result of a classic manufacturing process (e.g., an assembly line in a factory). A software system is immaterial, and the quality does not deteriorate with use in time, but with maintenance operations. Consequently, the question “What is software quality?” is likely to relate to responses different from other kinds of product and is, generally, difficult to answer. An alternative question is: “What are the characteristics of quality software?”, with respect to the different quality views (customer and manufacturer) and expectations. From this perspective, some models and frameworks have been proposed to define quality-related attributes and measurements.

SaMD, as well as embedded software (software in a medical device), falls under the regulatory environment.
The requirements concern four major topics:

1. 1. The QMS
   2. The risk management
   3. The system verification
   4. Validation

All medical device standalone software that is about to be or already placed on the EU market must go through the registration process. It could be wrapped in the following description.

I. Confirmation of the qualification of the product

During the first step of the certification procedure, manufacturers of standalone software must confirm whether their product belongs to any of the following groups:
• Medical devices
• In-vitro diagnostic medical devices
• Accessory to either of the above two
• Active implantable medical devices.

Based on this assessment, manufacturers can identify the Regulations applicable to their standalone software.
To qualify standalone software as a medical device, the intended purpose of that specific product must be shown and defined by the manufacturer in the product’s documentation (e.g. instructions for use and labelling). When defining the intended purpose, manufacturers must specify all the functions of the medical software. This means that if, for example, a user can perform many different calculations using the software, each of these calculations must be stated in the product’s documentation.
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, in such cases, manufacturers must take into consideration all the modules when qualifying their product as a medical device.

During the qualification phase, manufacturers must take into consideration the way the intended purpose of the standalone software is achieved. For instance:
• Is it acting as an accessory to another medical device?
• Is the action performed benefits the individual patient? What are the benefits?
• Is the purpose of the action performed included in the definition of a medical device?
• Is the action performed on data limited to storage, archival, lossless compression, communication or simple search?

A detailed overview of the process for qualifying standalone software as a medical device or an accessory is presented in the guidance document ‘MEDDEV 2.1/6 Guidelines on the qualification and classification of standalone software used in healthcare within the regulatory framework of medical devices’, issued by the European Commission.

II. Confirm the class of the medical device standalone software

Medical devices can be classified into four categories depending on the risk to the patient. These categories are: class I, IIa, IIb, and III. Class I includes medical devices of low risk, while medical devices of class III have the highest risk. The mentioned above guidance document MEDDEV 2.1/6 provide instructions on how to determine the classification of standalone software.In cases where qualifying and classifying standalone software is of extreme difficulty, manufacturers may refer to the classification section of the HPRA website at www.hpra.ie.

III. Selecting the appropriate conformity assessment procedure

In a nutshell, conformity assessment procedure is the process that any manufacturer must follow to demonstrate the compliance of their medical device with the relevant requirements of the applicable European Regulations.
The conformity assessment procedure is determined by the risk class of the product, and the manufacturer cannot follow a procedure relevant to another risk class. However, manufacturers must take into consideration the fact that the procedure followed must be appropriate for standalone software. This means that a conformity assessment procedure involving only product testing is usually considered inappropriate for standalone software. The reason for this is simple: 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 that may be present in the standalone software can be adequately assessed.
• Class I medical device standalone software:
The conformity assessment procedure for medical device standalone software classified as class I, excluding standalone 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). Detailed information on the processes, involved in CE marking medical device class I, can be found in the HPRA guide.
• All other standalone software:
For any other medical device standalone software, including class I standalone software with a measuring function, must be undertaken a conformity assessment procedure appropriate to its risk classification. These procedures are stated in the respective European regulations, and usually, each of them requires the intervention of a Notified Body. In this regard, it’s good to note that the NB’s intervention is limited when it comes to assessing the conformity of standalone software class I with a measuring function. Here, the Notified Body is only concerned with assessing the product’s conformity with the metrological requirements.

IV. Identifying relevant essential requirements

Manufacturers hold the responsibility for identifying the relevant requirements to their medical device standalone software. These requirements are laid down in the Regulations/Directives applicable to their products. Here are some examples of essential requirements relevant 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. Any restrictions on use must be specified on the label or in the instructions for use.
• About the software’s validation:
For medical devices, incorporating software or being medical device software in themselves, the software must be validated according to state of the art taking into consideration the principles of the development lifecycle, risk management, validation and verification.
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.

The next steps will be discussed in the part two of the article.