Medical electronics design, built for compliance from the schematic.

Most medical certification rejections don't come from a design defect, but from a file that fails to demonstrate the design. At AESTECHNO, 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. We've maintained a 100% CE/FCC first-pass success rate across all our projects.

Our experience with these standards. We have run several medical device projects compliant with IEC 60601-1 and IEC 62304, including a Class IIb certified device. The distinction matters: under MDR a Class IIb device cannot self-certify, it goes through a notified body. The design was therefore held against third-party scrutiny, not only our own review. They are under NDA, so we can neither name nor describe them, but they are real designs taken through the requirements set out above: essential performance defined, isolation barriers sized against patient contact, and a software life cycle documented to the safety class chosen.

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. At AESTECHNO, 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.

Our CI/CD pipelines secure deliveries with automated tests on every commit. 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 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.

At AESTECHNO, this approach avoids the classic situation of a working product that has to be redesigned during validation because a residual risk is judged unacceptable. We integrate risk management from the architecture phase, with our rigorous test processes.

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.

At AESTECHNO, 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. We apply our prototype → series transition experience to guarantee regulatory compliance at every stage.

IEC 60601-1 requires the manufacturer to define the essential performance of the device: the performance whose loss or degradation would create an unacceptable risk. It is not a feature list, and it is not the test laboratory's job to produce it. It is a conclusion of the risk analysis, and a notified body will read it as one.

This is what stalls files most often, through two symmetric mistakes. Declaring that there is no essential performance, which is sometimes true but must be demonstrated rather than asserted. Or declaring that everything is essential, which then obliges you to prove every function is maintained under every single-fault condition, and turns the test campaign into a pit.

The technical consequence is direct: whatever is declared essential must be maintained in single-fault condition, and that drives redundancy, monitoring and fallback behaviour. Decided at schematic stage it costs a few components. Decided after the first laboratory visit it costs a redesign.

The standard separates means of patient protection (MOPP) from means of operator protection (MOOP). The choice is not administrative: it sets creepage and clearance distances and dielectric test voltages, and therefore the footprint of the power supply and the topology of the PCB.

A 2 MOPP barrier is substantially harder than 2 MOOP at the same working voltage. Designing to MOOP and then discovering the applied part requires MOPP is among the most expensive reworks in medical design, because it hits the power supply, the signal isolators and the ground plan at the same time.

Applied-part classification follows the same logic. Type CF, intended for direct cardiac contact, carries the strictest patient leakage limits, far below Type BF. A device designed without settling B, BF or CF is a device whose power supply will be redrawn.

The confusion is common and expensive in time. IEC 60601-1 is the design and market-entry standard: it applies to the new product, at the manufacturer, and it underpins CE marking. IEC 62353 is the recurrent and post-repair test standard: it applies to a device already in service, at the operator, with different measurement methods and different limits.

In practice a 62353 report never replaces a 60601-1 file, and passing 62353 tests demonstrates nothing about design conformity. The reverse also holds: a 60601-1 compliant device still has to be testable in service, and that is prepared during design, through accessible measurement points and test documentation a biomedical technician can actually use.

The applicable IEC 60601-1 is edition 3 as amended: Amendment 1 produced edition 3.1, and Amendment 2, published in 2020, produced edition 3.2. The collateral standards run their own calendars, notably IEC 60601-1-2 for electromagnetic compatibility, whose edition 4 raised immunity levels and introduced the intended-use environment.

The practical implication is scheduling rather than engineering: the date of the test campaign determines which reference applies, and an edition transition mid-project can invalidate tests already passed. On a device whose development runs beyond a year, the target version is fixed at the start, not at the end.

It is also why a gap analysis run early, before the first laboratory visit, costs far less than a rejection. It consists of comparing the existing file against the target reference and producing the list of what is missing, while there is still time to add it.