Let’s picture the following scenario: 

You’ve created a startup company to launch an eHealth software application. After several months of work and research, you are finally releasing it. Your team worked exhaustively on it: coming up with the idea, discussing it with professionals in the Health sector, designing and developing an App that will be an innovative advantage for this sector.
Yet, in order for your company to put the product on the European market, you must ask yourself if your product is completely ready. Could it have any compliance issues with the medical devices regulations, stated in the new Medical Device Regulation (MDR)?

Being a startup company, you started the development in small steps, to evaluate if you were able to do it, to learn all you could, and to get enough funding. As expected for someone who is just starting out, you were not experienced enough in all the stages defined in the applicable standards. So, how can you assess if you are following all the regulations, and what can you expect to still be done in order to achieve what is truly necessary to be compliant? 

First of all, let’s try to understand what we are talking about.

The European Commission established a regulatory landscape with the new Medical Device Regulation (MDR), which has its own set of definitions, classifications, and rules for Software as a Medical Device. To put it in a relatively simple way, the classification of Software as a Medical Device depends on its intended use. If a manufacturer includes a clear medical purpose in the intended use statement – such as interpreting heart rhythms, controlling seasonal depression, or alleviating migraines – then that software qualifies as a medical device. Software for more general lifestyle and well-being purposes does not, provided the manufacturer makes no therapeutic or diagnostic promotional claims.
On the other hand, if, as an example, an application is used to take pictures of a rash to be shared with their physician and performs no action on those images other than storage, that will not qualify as a medical device.

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

“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 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 can you and your software development team expect to still improve in your product and your development process to be able to deploy a medical device in Europe?
To help you on this process, let’s guide you into a series of questions you have to answer to yourself:


1 – Who will launch the medical device into the market? A European company can only launch a medical device, whether it is software or not if it’s registered as a Manufacturer in the national health authority of its country. For instance, in Portugal, where LOAD has its headquarters, this registration is made with the INFARMED.

2 – What are the necessary certifications? In order to obtain regulatory authority approvals to bring medical devices to the market, medical device manufacturers must prove their products’ technical and administrative compliance with relevant standards and get the necessary certifications. The most relevant certification is the ISO 13485 Quality Management System (QMS).



3 – What process did your team follow while developing your software? Is it described in a technical file that should go along with your product? The standard IEC 62304:2006 describes the essential documents related to the development plan, risk assessment, requirements, design, implementation, verification, 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 the records of the development activities and tasks kept?
        Are the requirements implemented in the software and their control measures traceable?
        Is there a change control management in place?

5 – Is there a documented list of requirements, and an associated risk assessment, with a plan and a risk evaluation map, following methodologies based on Software Hazard Analysis or FMEA (Failure modes, Effects, and Analysis)?

6 – Did the software development process go according to a documented architecture or design?

7 – Is there a Verification Cross Reference Matrix, allowing to trace requirements, risks, verification, and verification results?


8 – How is the backup and software versioning control done? Is there a versioning control system/repository in place?

9 – Do you have a documented verification process of how the detected bugs are fixed and managed?

10 – How are the software releases managed and who is responsible for that management?

11 – In class B software, according to IEC 62304:2006, unit testing* is required. Unit testing is Was it done?

12 – Is your team making code reviews, by rotating reviews of each other’s developed pieces of code?

As you can see, there are a lot of processes to have in mind before launching an App as a Medical Device into the market. As we’ve been involved in the medical devices processes since 2016, these are basic steps that LOAD, being certified with ISO 13485 Quality Management System, and with a specialized medical device development team, is used to go through.
Our team can guide you in your journey to launch the software as a medical device into the market! 

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.

Pedro Colarejo