Medical electronics design, built for compliance from the schematic.
Designing a medical device isn't about retrofitting an industrial board. It's about embedding patient safety, software traceability and risk management into every architectural decision, from specification to MDR technical file.
- IEC 60601-1
- IEC 62304
- ISO 14971
- ISO 13485
- EU MDR 2017/745
Design for patient safety, not to pass certification
Most medical certification rejections don't come from a design defect, but from a file that fails to demonstrate the design. Our medical electronic boards are designed from the schematic around IEC 60601-1: dimensioned isolation barriers (MOPP / MOOP depending on patient contact), leakage currents measured on bench, clearances and creepage distances respected in PCB routing.
The result: a device that passes certification first time, and a technical file the notified body can audit line by line without asking for additional measurement campaigns.
IEC 62304 embedded software — end-to-end traceability
IEC 62304 doesn't describe how to write firmware; it describes how to prove that the firmware does what it's supposed to do and nothing else. We apply it strictly: requirements ↔ code traceability matrix, documented management of OTS components (open-source and third-party), software update process (SOUP), automated verification tests across the entire lifecycle.
On a Class C device, this discipline adds about 15-20% to initial development time — and saves several months in the certification phase.
ISO 14971 risk management — anticipated, not patched
ISO 14971 risk analysis starts with the specification. Every device function is mapped against its failure modes, patient impact, and probability of occurrence. Risk reduction measures are implemented in hardware (redundancy, monitoring, fail-safe) or software (watchdog, self-test, alarm), never only in the user manual.
This approach avoids the classic situation of a working product that has to be redesigned during validation because a residual risk is judged unacceptable.
MDR technical file — a deliverable, not a chore
EU MDR 2017/745 has tightened documentation requirements since 2021. The technical file expected by the notified body covers device description, performance and safety evidence, clinical evaluation, risk management, quality management system (ISO 13485), and post-market surveillance.
We deliver this file in parallel with development, structured according to MDR Annex II. This turns the submission phase from an end-of-project effort into a simple consolidation of documents already produced.
FAQ
- What's the difference between IEC 60601-1 and MDR?
IEC 60601-1 is a harmonised standard defining technical electrical safety requirements for electrical medical devices. MDR (EU 2017/745) is a European regulation defining the overall regulatory framework for placing devices on the market: essential requirements, classification, surveillance, traceability. Compliance with IEC 60601-1 is necessary but not sufficient for MDR; the MDR technical file also covers clinical evaluation, ISO 14971, ISO 13485, and IEC 62304 if the product contains software.
- Can you support a Class III device (active implant)?
Yes. Class III devices demand significantly higher documentary and clinical rigour (mandatory pre-market clinical evaluation, more involved notified body). Our approach doesn't change — the same traceability and risk management methodology applies — but the volume of evidence to produce increases. We work in extended team mode with a regulatory affairs partner for these projects.
- How long does it take to certify a Class IIb device with your method?
From design phase to market launch, count 18 to 30 months for a Class IIb. The technical phase (electronics design + firmware + V&V) represents about 12 months. The clinical evaluation and notified body audit phase represents another 6 to 18 months. Our work mainly reduces the risk of late redesign (which frequently doubles timelines when it occurs).
Hardware
A PCB we deliver is a PCB you can manufacture in series, certify without rework, and assemble in the factory without surprises. EMC, IPC standards and DFM are baked into the schematic — not bolted on after the prototype goes up in smoke.
Firmware
Industrial firmware isn't a script that works on delivery day. It's a system that has to keep running after ten years of series production, support secure OTA updates, and withstand a regulatory environment that keeps moving (CRA, IEC 62443).
Industrialization
The classic trap: a working prototype that needs six months and a re-spin to hold up in series production. Our technical signature is the opposite — DFM, IPC standards and testability are integrated into the initial schematic. The prototype is already a manufacturable board.