How to develop and certify a medical device

How to Develop and Certify a Medical Device

Intro

HiTech Service has successful software development experience across many projects, including software as a medical device. That experience was not easy to earn, and we want to share our thoughts and experiences in this article (or a set of them) with those who are new to this market and want to go live with a medical device of some kind. We will concentrate more on software development, where we have solid experience, though we will also describe the whole process for you to have an idea of how things work in the sphere of developing a medical device and getting it certified.

Planning

Planning should always go first in any new venture, especially when going to the market with a new medical device. You should plan all your steps ahead and estimate how long each step would take. Our experience says that this saves a considerable amount of time and money. In the case of going to the market with a medical device, we would suggest the following universal steps to consider:

1. Market investigation (choose the product)
2. Medical device assessment and classification
3. Document studies
4. Build production process
5. Develop the device and its documentation
6. Develop software as a medical device and its documentation
7. Certify the medical device

Investigate the market to choose the product

Do devote some time to investigating the market needs. It may take you from several days to several weeks. Keep in mind that development and certification processes are not quick procedures. In the most positive scenario, they will take at least six months, depending on multiple factors. So plan ahead! You need to be sure that the medical device of your choice will stay in demand when you go to the market. 

Medical device assessment and classification

Now it is time to determine what type of device you are about to bring to the market. Under the EU MDR, medical devices are classified into four risk classes, depending on the possible risks posed to the users or patients, indications for use and intended use. Classes of medical devices, depending on the risk levels, are:

• Class I
• Class IIa
• Class IIb
• Class III

Here, Class I stands for the minimum possible risk, and Class III has the highest risk probability.  To classify the device correctly, you should strictly define: 

• The medical purpose and intended usage for the medical device - users (doctors), who will utilize the device, patients, who will be treated, context of use, environment prerequisites, physical parameters needed (light, dust, humidity, temperature and other environmental variables where the device will be utilized). 
• Device characteristics - measuring functions, sterile, disinfection, disposal, contact with patient or user, materials and components, invasive, implantable, substances delivered/extracted, electrical, delivery of energy, environmental influence, outputs of energy or substances, lifetime, installation, storage, calibration and maintenance, interface, critical data for patient’s care etc.

All these factors will have a considerable impact on the complexity and duration of the whole development and certification process. For instance, when developing SaMD for Class III device, infrastructure and development teams will need to include the following actions if compared to Class I device:

• refine software architecture into software units;
• develop the detailed design of each software unit;
• develop a detailed design for interfaces;
• review detailed design and maintain records;
• evaluate all known residual defects and possible unacceptable risks;
• document the procedures and deployment environment;
• ensure precise logging of every sensitive step of the application;
• develop and maintain strict backup and disaster recovery procedures;
• develop unit tests and reports
• other

As you can see, this is a considerable amount of extra work, if compared to Class I, so it will take more time and money spent on development.  

Study the documents

It is time to study the framework documents. Depending on location (Europe, USA, etc), every medical device should comply with the corresponding requirements and/or regulations. For instance, in the EU this is the Medical Device Regulation (EU) 2017/745 (MDR), which replaced the Medical Device Directive and the Active Implantable Medical Devices Directive and has applied since 26 May 2021 (and the IVDR 2017/746 for in-vitro diagnostics); in the USA this is FDA and HIPAA requirements, title 21 CFR Part 11 (regulations on electronic records and electronic signatures (ERES), 21 CFR 820, etc.  As a product owner, you need to know these high-level framework documents to organize the process and be sure that you did not miss anything crucial. 

Build production process

Building the correct production process is a must for medical device development. Make sure that all your (software) development processes comply with ISO 13485  standard (and IEC 62304 for software development) from the very beginning. This is a must, no matter in what country you are preparing your medical device for certification. Since 2 February 2026, the FDA’s Quality Management System Regulation (QMSR, 21 CFR 820) incorporates ISO 13485:2016 by reference. Also, depending on the product, additional requirements may apply: 

• EN/IEC 60601-1 “Medical Electrical Equipment and Systems”
• IEC 62366 “Medical devices – Application of usability engineering to medical devices”
• Cybersecurity requirements - NIST cybersecurity Framework and HIPAA Security Rule

The list of process documents will vary depending on the device class and type, but these framework documents are common for any medical device development process. 

Develop the device and its documentation

We will not go deep into engineering processes since we are a software development company, but working closely with engineering teams, we do know the common stages that any device will go through before being certified: 

• Prototype (design)
• Verification
• Risk Analysis
• DMR

Prototype (design)

Once you know what medical device you are going to throw to the market, you need a way to prove its efficacy to the certification body. Building the prototype of the medical device is the first step to do this. Design development and engineering process usually take time. This time very much depends on many factors like the level of complexity of the prototype and the level of proficiency of your team. If the device is simple enough, does not require unique parts and your team is efficient enough, the device prototype may be ready in several months, otherwise, it can take years. 

Verification

Once the device prototype is ready, you need to make sure that all its parts work as was initially intended. The device as a whole should also achieve the goals set and you should get the intended result as its user. This activity is called verification and needs to be thoroughly documented in the traceability matrix.

Risk Analysis

Every medical device has its “weak spots” that may potentially harm the user (doctor) or the patient if the device is used beyond its limits or incorrectly. And when we are talking about medical devices, lives could be at stake. That is why it is critical to find all potential risks of a medical device and ways to avoid them or mitigate the consequences. This process should also be carefully documented since the certifying body will definitely pay special attention to risk documents.

DMR and Technical file

Device Master Record is a compilation of records containing the procedures and specifications for a finished device, required for a medical device. DMR is required only by the FDA (in the USA) and if you start in Europe, ISO 13485:2016 requires a manufacturer of a medical device to establish a Technical file, similar to a Device Master Record. 

Develop software as a medical device and its documentation

A considerable number of modern medical devices cannot work without the software controlling all the activities of the device. This software should also comply with all the framework documents and requirements for the medical device and be developed according to the medical industry standards (ISO 13485 and IEC 62304). We have our software development process compliant with these standards and include the following processes: 

• Software development
• Risk management
• Configuration management
• Documentation management
• Software Safety Risk management
• Software validation
• Training and competence
• Internal audits
• Infrastructure management
• Purchasing management

Many of these usually go in parallel to each other throughout the whole project lifecycle. 

Software Development

This is the core process of developing software as a medical device. The software development life cycle (SDLC) should contain the following processes, each having its specific goals and well-defined exit criteria, depending on the Class of the medical device:  

• Software development planning
• Software requirements analysis
• Software architectural design
• Software detailed design
• Software unit implementation
• Software unit verification
• Software integration and integration testing
• Software system testing
• Software release

Software development planning

During this phase, the Project Owner and the team are defining the inputs and outputs of the project, its duration and milestones, high-level requirements and general approach. This is documented in the Software Development Plan and serves as a high-level index of all activities required to complete the project. 

Software requirements analysis

Software development cannot start without requirements. The project manager together with the product owner define a functional, system, business and other requirements including the preferred design of the resulting product. All the requirements are split into minimum possible items (units), described, labeled and added to the Software Requirements Specification document and Traceability Matrix. All the later changes to the requirements, if any, are also documented. 

Software architectural design

During this phase, the software architects and developers plan the technical implementation of the software requirements. This is documented in the Software Architecture document and has to fulfill the following goals:

• Serve as input for the development team how to technically implement/develop the system – ideally without the need for any further inquiries. 
• Provide an overview of the structure of the software system, also for the future project staff. 
• Give the test team sufficient information about the software components, about the integration strategy and how to perform software unit and integration tests.

Software detailed design

It is required that every developed part of the software as a medical device (unit) is described from the point of view of behavior, layout and applied technologies. This is usually done by the Architect and Developer followed by approval from the Project Manager.

Software unit implementation

When software units’ design is ready, the Project Manager plans them for implementation. Our development process is iterative-incremental (IID) and we develop according to Agile methodology. This means that we develop the application feature by feature (unit by unit) during self-contained cycles. These cycles include analysis, design, development and testing that end in the production of a stable, fully integrated and tested, partially complete system. This system incorporates all of the features of all previous iterations. Iterations are strictly time-boxed, usually 2 weeks. 

Software unit verification

Every software unit needs to be tested before approval for production. The verification testing approach may combine static and dynamic methods. Static unit verification includes code review and code analysis using code static analysis tools. Dynamic unit verification is a method of software analysis performed with code execution. According to the Test Plan, there is time booked at the end of every iteration by QA team to perform verification unit verification tests for units that were developed in the current iteration. This is usually done through executing corresponding test cases and documenting the results. Verification test cases make sure that the software unit functionality, layout, and numerous other parameters correspond to what is written in software design. Also, test efforts differ depending on the Class of the medical device. The more risk a medical device may pose, the more testing efforts it requires.

Software integration and integration testing

Integration testing is performed after software units are verified and integrated into the software product. This is done to ensure that all units intended for integration work as expected when combined in a group.

Software system testing

This is the next level of testing, done to make sure that the integrated group of units works as expected when combined with the baseline system. All testing activities, despite of their type, are documented. 

Software release

When the Traceability Matrix shows that all software components were tested, all the defects are fixed and verified or documented as known residual, the software is ready to be released. The release process is also covered by corresponding documents and is done according to the industry standards.

Risk management

Risks can negatively impact on the project that could result in decreased quality, increased cost, delayed completion, or project failure. Risk management process is intended to identify and handle causes of project risks. The risk management approach in our company follows the risk management model described in PMBOK. This approach consists of the following steps:

• Risk management planning
• Risk identification
• Risk analysis
• Risk response planning
• Risk monitoring and control.

Configuration management

This is one of the core processes that no one pays much attention to, but actually keeps everything going.  Configuration Management process is to establish and maintain the integrity of software engineering work products using configuration identification, configuration control, configuration status accounting, and configuration audits.  This process controls all environments needed for development, testing or production and is actually responsible for releasing the software product from a technical point of view. 

Documentation management

Documentation management process describes the way to manage all documented information required by a company. Project documentation, process documentation, organizational units’ documentation - every document that a company may require is the subject of the document management process. If applied to only developing software as a medical device, it identifies and tells how to handle the project documentation needed to cover the software development phase and other documents, required by the certification body for the successful certification process. For instance, there are more than 60 documents needed to certify a Class II medical device from the point of view of software development. 

Software Safety Risk management

On this stage a Project Team  have to identify potential hazards associated with a software product that is part of a medical device or the medical device itself, estimate, evaluate the associated risks, control these risks, and check the effectiveness of the controls. FMEA, FTA, PHA techniques can be used for risk analysis activity. Please pay attention to software tools and third-party components during the identification of potential risks. ISO 14971 is an ISO standard for the application of risk management to medical devices

Software validation

This process, from the angle of developing software as a medical device, makes sure that the third-party software, used in the software development phase (repositories, technologies applied, database types, etc), cannot be the cause of malfunction or other potential harm when the medical device is performing its core tasks. 

Training and competence

This procedure comes into action when there is a necessity in additional personnel assigned to the project or the existing personnel needs to be trained to comply with industry standards (medical industry standards in our case) that is backed up by corresponding records and certificates. 

Internal audits

Every once in a while a company must carry out internal audits to determine whether its quality management system complies with the requirements of the corresponding industry standard - ISO 9001:2015 or ISO 13485 and IEC 62304 - and to confirm that the quality management system is effectively implemented and maintained. If nonconformities were found, the Corrective and Preventive Actions (CAPA) procedure can be used to eliminate the cause of NC.  The reason for CAPA implementation also can be:

• nonconformities revealed during management QMS review,
• nonconformities revealed by employees of the company during the performance of their daily tasks,
• metrics analysis,
• customer feedback analysis,
• customer complaints analysis,
• risks analysis.

Infrastructure management

This is also one of the core processes in software development. It ensures that all developed and delivered services satisfy end-users as continually fitting both for purpose and use from the IT infrastructure standpoint. 

Purchasing management

This process is intended to satisfy the needs of the team in commercially available products and services in order to support the ongoing project - everything from keyboard and licensed software to specialized equipment. 

Certify the medical device

When your medical device is ready, well tested and documented it is time to get it certified. The certification body differs from country to country but what is common between them is that the device must undergo a series of tests to ensure that the device complies with the corresponding standards and requirements before being certified. The certification body also makes sure that all the documents for the medical device are in place and were developed according to the industry requirements.