Customized medical electronics: how equipment is certified

All posts

Certification of a medical device is a process that verifies that a device meets technical, safety and legislative requirements (e.g. MDR) and can be placed on the market. It involves the preparation of technical documentation, risk analysis, laboratory testing and, for higher grades, assessment by an independent body (Notified Body). Proper preparation has a major impact on the length, cost and success of the process.

However, how smoothly the certification goes is decided during development. In previous parts of our series Customized medical electronics: how to create a good assignment a Customized medical electronics: from technical concept to working prototype we got to the final prototype and the documentation freeze. At that point, we have a stable technical solution and a device that works to specification and that can go into mass production.

What are the differences between the certification of medical devices and common electronics?

Every electronic product sold in Europe must bear the CE marking and be accompanied by an EU declaration of conformity. The CE marking is a legal declaration by the manufacturer that the product complies with all relevant European regulations and tests and can be placed on the market in the EU. The manufacturer also takes full responsibility for the product’s compliance with the legislation.

For some high-risk fields, it is not possible to “just” issue a declaration yourself – medicine is one of them. This is where the European MDR (Medical Device Regulation, EU 2017/745) comes into play, which specifies what must be met in order to market a device as a medical device. The MDR also brings in strict documentation and procedural requirements.

The scope of these requirements varies according to the riskiness of the equipment. Medical devices are therefore divided into classes.

How does risk class affect the certification process of a healthcare facility?

Class I allows the manufacturer to prepare the documentation himself and issue a declaration of conformity without full external approval.

For the higher classes – IIa, IIb and III – a Notified Body enters the process – an independent, state-authorised organisation that reviews the manufacturer’s documentation and quality system and issues a certificate according to the MDR.

Class IIa is very common. In this case, the primary focus is on documentation – i.e. whether the manufacturer has met the technical requirements of the MDR (including the ‘soft’ requirements of usability, software documentation and validation), demonstrated clinical function (i.e. evidence that the device performs medically as promised by the manufacturer) and has processes under control.

As a development and production partner, we provide the technical part of the process: we prepare the technical documentation, arrange the necessary tests, participate in risk analysis and put together the documentation for both hardware and software. However, the quality management system (QMS) itself and the final responsibility for marketing the product is always the responsibility of the one who markets the product under his own name.

What all belongs in the MDR documentation?

From a technical point of view, this is what we do during certification:

  • risk analysis,
  • professional documentation of hardware and firmware according to medical standards,
  • electrical safety tests (typically to EN 60601-1),
  • EMC tests (EN 60601-1-2),
  • thermal, vibration and other mechanical tests,
  • specialised standards by product (e.g. specific to ECG devices) or by application (e.g. home use – homecare),
  • or specific environmental requirements, for example for use in ambulances or helicopters.

Some of the testing is done during the development process and some tests are outsourced to accredited laboratories. Thanks to continuous verification, we can catch weak points early and prepare the equipment so that the accredited tests are carried out without unnecessary complications.

We are also preparing software documentation, feature validation and cybersecurity solutions to meet MDR requirements.

Each device must also undergo a clinical evaluation process. However, this does not necessarily mean expensive clinical trials on patients. Most devices can be built on a history of using similar devices. Thus, data collected from the market can replace the need for new tests if it proves that the product is safe and fulfils its purpose.

Why is risk analysis key to certification?

One of the most important documents is the risk analysis (typically according to ISO 14971). It is a living document that is created continuously – ideally from the beginning of development – and is added to up to the certification phase and after the product has been launched on the market.

It typically involves a developer, a manufacturer, a user and possibly a doctor.

The risk analysis assesses:

  • what dangers may arise,

  • how often they can occur,

  • how serious their impact on the patient or user may be,

  • and whether the resulting risk is acceptable.

The process also includes designing risk reduction measures and verifying that these measures actually work.

It addresses not only obvious faults, but also non-standard situations – for example, when parts of the system (such as the processor and display) stop communicating with each other, when the device does not correctly signal its status, or when the user uses the device in a different way than intended.

The risk analysis is also the basis for other documents – for example, to justify the materials used, the protective measures or the method of notification of a defect.

How long does it take to certify medical electronics?

We plan certification realistically at the design stage. The exams themselves usually take two to three months, and the Notified Body documentation can take a similar amount of time. If the project is well prepared and the documentation is produced continuously along with the testing, the whole process can be completed in about half a year. In practice, however, it is reasonable to allow for a horizon of one year.

As a development and manufacturing partner, we have been working with this process since the beginning of the design process. We prepare the technical documentation in parallel with the testing, coordinate the testing and make sure that the project doesn’t go back a step unnecessarily. This allows us to keep the timeframe under control.

If the device is linked to an existing product and data from the practice is available, we help to incorporate this data correctly into the clinical trial, thus simplifying the whole process significantly.

What applies to non-EU markets?

For other markets, most of the technical documentation can be used because the technical standards are largely harmonised. Here too, we help clients set up a process that makes business sense and does not incur unnecessary parallel costs.

We take certification into account when designing the equipment. Decisions on intended use, class and production method influence the entire project. This allows us to guide the client through the process from development to certification without unnecessary extra steps.

If you are preparing your own medical device and want to be sure that the technical solution and the next steps are set up correctly, please contact us. We will be happy to walk you through the entire process from design to product launch.

 

Posts

More posts

25 years of EGMedical: from textile line to development and production of custom electronics

25 years of EGMedical: from textile line to development and production of custom electronics

In 25 years we have worked our way from modifying textile line management to developing and manufacturing custom electronics for medical, industrial and research applications.
Customized medical electronics: from technical concept to functional prototype

Customized medical electronics: from technical concept to functional prototype

Prototype development, manufacturing and testing are key to making a medical device actually work outside the development lab. How do we approach this here?