Medical Devices: What You Need To Know.

Let us imagine the following scenario: 

You have founded a startup company to bring an eHealth software application to market. After several months of work and research, you finally release the application. Your team has been working hard on it: You developed the idea, discussed it with healthcare professionals, and designed and developed an app that will be an innovative advantage for this sector.
But in order for your company to bring the product to the European market, you need to ask yourself if your product is fully mature. Could it have compliance issues with the medical device regulations set out in the new Medical Device Regulation (MDR)?

As a start-up, you have started development in small steps to see if you are able to do it, to learn everything you can, and to get enough funding. As was to be expected for someone just starting out, you did not have enough experience in all the stages specified in the applicable standards. So how can you assess whether you are complying with all the regulations, and what more do you need to do to achieve what is really necessary to comply with the regulations?

Let us first try to understand what we are talking about. 

With the new Medical Device Regulation (MDR), the European Commission has created a set of rules that includes its own set of definitions, classifications, and rules for software as a medical device. To put it relatively simply: The classification of software as a medical device depends on its intended use. If a manufacturer states a clear medical purpose in the statement of purpose – for example, interpreting heart rhythms, controlling seasonal depression, or relieving migraines – then that software is considered a medical device. Software for more general lifestyle and wellness purposes, on the other hand, is not, unless the manufacturer makes therapeutic or diagnostic advertising claims.
On the other hand, if an application is used to take photos of a rash to share with a doctor, for example, and merely stores those images then it is not considered a medical device.

There are five software classifications – Class I, Im, IIa, IIb, and III – with specific definitions for each described in Rules 9, 10, and 11. Understanding the classification rules can be quite complex, so let us illustrate with some examples from a 2019 Regulatory Affairs Professional Society article (RAPS):

“Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as Class IIa, except if such decisions have an impact that may cause death or an irreversible deterioration of a person’s state of health, in which case it is in Class III or a serious deterioration of a person’s state of health or a surgical intervention, in which case it is classified as Class IIb. Software intended to monitor physiological processes is classified as Class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as Class IIb. All other software is classified as Class I. As an example, software used to monitor heart rates or any other physiological parameters during a routine checkup is classified as Class IIa. However, if the monitoring aims at vital physiological parameters, and where those parameters could result in immediate danger to the patient, the classification is elevated to Class IIb.”

You can read more here. 

Back to the point: What do you and your software development team need to improve about your product and your development process in order to deploy a medical device in Europe?
To help you with this process, we would like to walk you through a series of questions that you need to answer for yourself:

THE MANUFACTURER

1 – Who will place the medical device on the market? A European company can place a medical device on the market, whether it is software or not, only if it is registered as a manufacturer with the national health authority of its country. In Portugal, for example, where LOAD is headquartered, this registration is with INFARMED.

2 – What certificates are required? To obtain regulatory approval to place medical devices on the market, medical device manufacturers must demonstrate the technical and administrative compliance of their products with the relevant standards and obtain the necessary certifications. The most important certification is the ISO 13485 Quality Management System (QMS).

THE PROCESS

3 – What process did your team follow in developing your software? Is it described in a technical file that should accompany your product? The IEC 62304:2006 standard describes the essential documents related to the development plan, risk assessment, requirements, design, implementation, review, and version control.

4 – Is there a software development plan?

• Does it describe the risk classification according to IEC 62304:2006 (A, B, or C)?
• Does it describe the process used in software development?
• Are records kept of development activities and tasks?
• Are the requirements implemented in the software and their control measures traceable?
• Is there change control management?

5 – Is there a documented list of requirements and associated risk assessment with a plan and risk assessment map based on software hazard analysis or FMEA (failure modes, effects and analysis) methods?

6 – Was the software development process carried out according to a documented architecture or design?

7 – Is there a verification cross-reference matrix to track requirements, risks, verification, and verification results?

THE CODE DEVELOPMENT

8 – How are software backup and version control performed? Is there a version control system/repository in place?

9 – Do you have a documented review process for how detected bugs are fixed and managed?

10 – How are the software versions managed and who is responsible for this management?

11 – For Class B software, IEC 62304:2006 requires unit testing*. Have unit tests been performed?

12 – Does your team conduct code reviews by taking turns reviewing the code pieces developed by others?

As you can see, there are a lot of processes to follow before an app is launched as a medical device. Since we’ve been involved in medical device processes since 2016, these are the basic steps that LOAD, which is certified with the ISO 13485 quality management system and has a specialized medical device development team, tends to go through.
Our team can guide you on your way to bringing the software to market as a medical device!

Get in touch with us and launch your Medical Device safely. 

_________________________________________

*Unit testing is a software testing methodology by which individual units of code are tested autonomously to determine whether they produce the expected output regarding a known input. All the software units together, interacting with each other, will compose the system. Unit testing is therefore a different thing from system testing since this one intends to verify the behavior of a system or a subsystem as a whole.