--- title: Hardware Development for Medical Devices: PCB Design and Documentation description: Hardware development and PCB design for medical devices under MDR: safety and EMC decisions, schematic and BOM control, and evidence auditors request. authors: Tibor Zechmeister, Felix Lenhard category: Electrical Safety & Systems Engineering primary_keyword: hardware development PCB medical device MDR canonical_url: https://zechmeister-solutions.com/en/blog/hardware-development-pcb-design source: zechmeister-solutions.com license: All rights reserved. Content may be cited with attribution and a link to the canonical URL. --- # Hardware Development for Medical Devices: PCB Design and Documentation *By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.* > **Hardware development for a medical device is not just electrical engineering. It is electrical engineering under EN 60601-1 and EN 60601-1-2, documented under EN ISO 13485:2016+A11:2021 clause 7.3, traceable to risk controls under EN ISO 14971, and auditable against MDR Annex II §6.1. The PCB is the smallest artifact. The evidence around it is the thing that gets you certified.** **By Tibor Zechmeister and Felix Lenhard.** ## TL;DR - PCB design for a medical device must account for creepage and clearance distances, insulation coordination, and leakage currents as defined in EN 60601-1. These are design inputs, not test-time surprises. - EMC is a design decision, not a post-design fix. EN 60601-1-2 compliance is cheapest when it is built into the layout, grounding scheme, and shielding strategy from the first revision. - Schematics and BOM belong under document control (EN ISO 13485:2016+A11:2021 clause 4.2.4 and 7.3). Every revision, every approval, every change linked to a change request. - The design history file required through EN ISO 13485 clause 7.3 is the auditor's single window into hardware development. It needs to tell a complete story from user needs to verified design. - Auditors ask three hardware questions first: show me your risk controls on the schematic, show me your creepage and clearance analysis, and show me BOM version control tied to your production records. ## Why this matters Hardware is the subsystem where notified body findings get expensive. A software finding usually means a documentation cycle. A hardware finding can mean a new board spin. Tibor has seen startups lose four months and forty thousand euros because a creepage distance on a single trace was below EN 60601-1 requirements and nobody caught it until the accredited test lab did. The root cause was never a bad engineer. It was always a missing link between the risk file, the design input, and the schematic review. Under MDR, the device manufacturer is responsible for the hardware regardless of whether the PCB was designed in-house or at a contract engineering house. Outsourcing the layout does not outsource the responsibility. The design history file must tell the whole story, and the auditor will ask for it. The good news: hardware under MDR is not harder than hardware for a consumer product. It is just more documented. Teams that have done a consumer wearable and then tried to certify a Class IIa version underestimate the documentation. Teams that start with the documentation discipline usually finish faster. ## What MDR actually says MDR Annex I §14 ("construction and interaction with their environment") requires that devices be designed and manufactured in such a way as to reduce as far as possible the risks posed by energy sources, including electrical energy. Annex I §14.5 addresses electromagnetic interference. Annex I §17 covers devices incorporating electronic programmable systems. The MDR does not tell you the creepage distance. It tells you the device must be safe. The presumption of conformity comes from the harmonised standards. For electromedical devices that is EN 60601-1:2006+A1+A12+A2+A13:2024 for basic safety and essential performance, and EN 60601-1-2:2015+A1:2021 for electromagnetic compatibility. EN 60601-1 contains the actual numbers: creepage and clearance tables, leakage current limits, dielectric strength requirements, the concept of means of protection (MOOP for operator, MOPP for patient), single-fault safe operation, and the pathway from the applied part to the patient. EN ISO 13485:2016+A11:2021 clause 7.3 wraps all of this into the design and development process: planning (7.3.2), inputs (7.3.3), outputs (7.3.4), review (7.3.5), verification (7.3.6), validation (7.3.7), transfer (7.3.8), change control (7.3.9), and the design and development file (7.3.10). The PCB is an output. Its specification, revision history, and review records are evidence. The design history file is the controlled location where all of this lives. MDR Annex II §6.1 requires the technical documentation to include the design and manufacturing information in sufficient detail, the test reports demonstrating conformity with the applicable GSPRs, and the critical analyses thereof. ## A worked example A team is developing a Class IIa wearable patch with an applied part in direct contact with intact skin, wireless charging, Bluetooth telemetry, and a rechargeable lithium-polymer cell. Early in architecture the team makes three decisions that will drive the PCB design: First, the applied part is Type BF. This means the patient-connected circuit must be isolated with at least one means of patient protection from other parts, and creepage and clearance in the isolation barrier must meet the EN 60601-1 tables for the relevant working voltage and pollution degree. These numbers are written into the hardware requirements document before the schematic starts. Everyone on the layout team knows what the isolation barrier looks like before placing the first component. Second, the charging path is designed assuming single-fault conditions. The charging IC can fail, the thermistor can go open, the battery management IC can latch. The schematic review walks through each of these with the risk file open. Every hazard that requires a hardware control is annotated on the schematic with the risk ID from the EN ISO 14971 risk file. When the notified body asks "how is this risk controlled," the answer is "look at R47 and U12, referenced in risk file entry RM-0034." Third, EMC is planned at layout time. Ground pours, stitching vias, a proper return path under the Bluetooth antenna, filtering on the power rails, and a shielded enclosure allocation. The team books the pre-compliance EMC slot at the accredited lab for the week after board bring-up, not the week after "final" verification. The first pre-compliance run finds three findings. Two are fixed with component value changes, one with a minor layout correction. The board re-spins once, deliberately, and passes full EMC testing on the second run. Schematics live in a PDM system tied to the QMS. Every release is reviewed under clause 7.3.5 with records of who reviewed, who approved, and what was agreed. The BOM is a controlled document. Every component has an approved manufacturer part number and at least one verified alternate where possible. When a component goes end-of-life and is replaced, a change request is opened and closed under clause 7.3.9. When the notified body audits this device, the hardware section of the audit lasts about ninety minutes. The auditor asks for the creepage and clearance analysis, the risk controls traced to the schematic, the EMC test report, the BOM revision history, and the component change records. All of it exists, all of it is findable in under a minute. The team passes the hardware section on the first review. ## The Subtract to Ship playbook **Write the hardware requirements before the schematic.** Creepage and clearance, leakage current limits, MOOP/MOPP allocation, applied part type, pollution degree, operating altitude, temperature range, input voltage range, immunity levels. These are inputs to layout, not things you discover during testing. **Annotate risk controls directly on the schematic.** A schematic note that says "R47, R48 redundant current limit, ref RM-0034" costs nothing to add and saves hours in the audit. It also forces the engineer to be honest about whether the risk control actually exists in the circuit. **Treat pre-compliance EMC as a development activity, not a verification activity.** Book the lab during bring-up. Use the findings to drive the next spin. The cheapest EMC fix is a layout change before manufacturing scales. **Lock the BOM under document control from the first prototype.** Yes, from the first prototype. No, it does not slow you down. What slows you down is reconstructing a BOM for a batch you built ten months ago because a notified body asked for the exact parts used in verification testing. **Manage component alternates deliberately.** EN ISO 13485 clause 7.4 covers purchasing. If a part can be sourced from two manufacturers, both belong in the approved supplier list and both get verified. If only one source exists, that is a supply risk and it goes in the risk file. **Control the transition from prototype to production.** Design transfer under clause 7.3.8 is where hardware startups bleed time. The contract manufacturer needs the BOM, the assembly drawings, the test procedures, the acceptance criteria, and the first-article inspection plan. Missing any of those pushes your first production build back by weeks. **Keep the design history file current, not final.** The DHF is a living file that is maintained during development, not assembled the week before the audit. If you build it as you go, the audit costs you days. If you build it the week before, it costs you weeks and the auditor can tell. ## Reality Check 1. Do your hardware requirements explicitly state creepage and clearance distances, applied part type, and leakage current limits before the schematic was drawn? 2. Can you point to risk controls on the schematic that reference entries in your EN ISO 14971 risk file? 3. Is your BOM under document control with a revision history and change records for every component substitution? 4. Has your board been through pre-compliance EMC testing, and were the findings driven back into the layout before the final spin? 5. For every approved component on the BOM, can you show a qualification record or justification for use in a medical device? 6. Is the design and development file maintained in your QMS, or is it a folder somebody is going to assemble next month? 7. Do you have a documented design transfer plan that your contract manufacturer is actually working from? 8. If your lead hardware engineer left tomorrow, could a replacement rebuild the board from the controlled documents alone? ## Frequently Asked Questions **Do I need EN 60601-1 compliance if my device is battery-powered and never connected to mains?** Usually yes. EN 60601-1 applies to medical electrical equipment in general, not only mains-powered. The standard has provisions for internally powered equipment. Read clause 4 of EN 60601-1 carefully with your test lab. **Can I design the PCB without involving regulatory until later?** You can, but you will pay for it twice. Risk controls, isolation requirements, and EMC decisions shape the layout. Adding them after the fact means a board respin. Bring regulatory thinking into the hardware requirements phase. **How much does EN 60601-1 testing cost for a typical startup device?** Ranges widely. For a Class IIa wearable or small benchtop device, accredited EN 60601-1 plus EN 60601-1-2 testing in the EU typically costs between fifteen and forty thousand euros, plus re-test fees if something fails. Budget for one re-test cycle. **Does the notified body audit my PCB directly?** No. The notified body audits the documentation and the test reports from the accredited lab. But they will look at your schematic during the technical file review, and they will ask pointed questions about risk controls visible on it. **Can I use a contract design house for hardware?** Yes, and many startups do. The contract with the design house must require design records compatible with your QMS, and the outputs must come into your document control. The responsibility under MDR stays with you. ## Related reading - [MDR Electrical Safety Requirements](/blog/mdr-electrical-safety-requirements) — how MDR Annex I maps to EN 60601-1 - [EMC Requirements under EN 60601-1-2](/blog/emc-requirements-iec-60601-1-2) — the companion standard for electromagnetic compatibility - [Design History File under MDR](/blog/design-history-file-mdr) — where hardware evidence lives - [Design Input Requirements in MedTech](/blog/design-input-requirements-medtech) — writing inputs your hardware team can actually build to - [Electrical Safety Testing for Medical Devices](/blog/electrical-safety-testing-medical-devices) — sequencing lab testing with development ## Sources 1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex II §6.1, Annex I §14, §14.5, §17. 2. EN 60601-1:2006+A1+A12+A2+A13:2024 — Medical electrical equipment — General requirements for basic safety and essential performance. 3. EN 60601-1-2:2015+A1:2021 — Medical electrical equipment — Electromagnetic compatibility. 4. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems. Clauses 4.2.4, 7.3, 7.4. 5. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices. --- *This post is part of the [Electrical Safety & Systems Engineering](https://zechmeister-solutions.com/en/blog/category/electrical-safety) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*