What you will learn
By the end of this topic, you should be able to explain how electronics engineering fits into a controlled medical-device lifecycle, identify the evidence expected from hardware development, recognise the interfaces that require active ownership and understand why design responsibility continues through manufacturing, change and post-market support.
The electronics engineer’s role
A technically sound circuit is not yet a complete medical-device design. The electronics must be derived from controlled requirements, implement risk controls, operate safely in its intended context, be independently verified, be reproducible in manufacture and remain understandable when the product changes years later.
Functional performance
Deliver the required sensing, actuation, processing, power and communication performance across stated operating, storage, transport and lifetime conditions.
Safety and risk control
Control electrical, thermal, EMC, battery, functional, data and foreseeable misuse-related risks through the design wherever practicable.
Reproducible manufacture
Define components, processes, programming, calibration, inspection and acceptance well enough for consistent production.
Objective evidence
Connect requirements, analyses, reviews, tests, deviations and changes so another competent person can reconstruct the design reasoning.
If an engineer outside the project cannot determine what was intended, why the design is suitable, what configuration was tested and why the released product is acceptable, the evidence is incomplete.
What changes when electronics becomes MedTech?
The circuit is part of a medical purpose, a risk-management process and a controlled product definition. The same processor, power supply or radio may need very different controls in a home-use therapy system, an IVD analyser, a wearable monitor or a hospital accessory.
- Start from intended purpose, users, patients and use environments—not an assumed list of familiar standards.
- Confirm whether the electronics form a device, accessory, subsystem or reusable platform.
- Identify applied parts, conductive connections, delivered energy, fluid paths, sensors and external dependencies.
- Define product variants, accessories, cables, chargers, networks and consumables covered by the evidence.
- Record target jurisdictions, regulatory classification and the applicable standards strategy.
IEC 60601 is important for medical electrical equipment, but it is not universal. Laboratory and IVD equipment may instead use the IEC 61010 family, while other products require different safety frameworks. Component approvals support finished-device assessment; they do not replace it.
Contribution across the lifecycle
Electronics engineering is not a design-stage service that ends when the PCB works. Its responsibility follows the controlled product through seven connected areas.
Purpose and context
Understand the medical purpose, intended users, patients, use environments, system boundary, variants and target markets before selecting a technical solution.
Typical evidence: Intended-purpose contribution, use-environment assumptions, interface inventory and applicable-standards input.Requirements
Translate system needs, risks, interfaces and standards into measurable hardware requirements with defined conditions and acceptance limits.
Typical evidence: Hardware requirements, interface specifications, rationale and bidirectional traceability.Architecture
Make energy paths, isolation, protection, diagnostics, operating states, safety functions and hardware–software dependencies visible and reviewable.
Typical evidence: Architecture description, power tree, state model, interface controls and protection concept.Detailed design
Develop schematics, PCB, component choices, calculations and programmable content under configuration control, with manufacture and test already considered.
Typical evidence: Schematics, PCB package, BOM/AVL, analyses, reviews and controlled design baseline.Verification
Show objectively that hardware outputs meet their inputs across representative configurations, tolerances, environments, faults and relevant disturbances.
Typical evidence: Plans, protocols, raw data, reports, anomalies, worst-case rationale and requirements traceability.Transfer and production
Ensure approved manufacturing can build, program, inspect, test, trace and release the verified design without undocumented development support.
Typical evidence: Manufacturing package, supplier controls, qualified fixtures, pilot-build results and readiness review.Change and post-market
Assess component changes, obsolescence, complaints and field failures against requirements, risk, compliance, evidence and installed product.
Typical evidence: Change assessments, regression evidence, investigations, updated risk records and configuration history.Requirements, architecture and interfaces
Make hardware requirements testable
A strong requirement states an observable outcome, the conditions under which it applies and an objective acceptance limit. Replace “the battery must last a long time” with a defined number of use cycles, load profile, storage history and environmental conditions. Replace “the PCB shall pass EMC” with the behaviour and limits required during and after specified tests.
Make safety visible in the architecture
Architecture should identify energy and signal paths, isolation boundaries, patient and operator connections, safety-related sensors and actuators, diagnostic coverage, power states, communications and dependencies on software.
Every electrical interface needs agreed ownership: signal meaning, timing, voltage, current, impedance, connector allocation, grounding, shielding, allowable states, fault behaviour and verification responsibility.
Electrical safety, EMC and risk control
Compliance cannot be added at the test laboratory. Power integrity, insulation, protection, EMC, thermal design and environmental robustness must be built into architecture, components, PCB and enclosure integration.
Power and protection
Address peak loads, inrush, brownout, interrupted-power recovery, overcurrent, overvoltage, reverse polarity, temperature and the energy needed to reach a safe state.
Isolation and ratings
Determine creepage, clearance and insulation from working voltage, transients, pollution degree, material group, altitude and required means of protection.
EMC robustness
Control return paths, shielding, filtering, cabling, stack-up and enclosure interfaces. Monitor safety-related performance during immunity testing—not simply whether power remains on.
Environmental robustness
Consider temperature, humidity, altitude, transport, vibration, contamination, battery ageing and worst-case accessory and operating configurations.
Hardware FMEA is useful, but it is not the complete device risk analysis. Detailed failure mechanisms—open, short, drift, intermittent, stuck, substitution, common cause or manufacturing defect—must connect to device-level hazards, hazardous situations and harms.
Show that the control is implemented in the released design and that it is effective under the specified normal, fault and environmental conditions. Also show that production can reproduce it.
Design outputs, verification and evidence
Schematics and layout are essential outputs, but they are not the complete electronic product definition.
- Controlled schematics, PCB data, stack-up, fabrication and assembly drawings.
- BOM and approved manufacturer/source combinations, including controlled substitutions.
- Calculations, simulations, tolerance, derating, thermal, power and reliability analyses.
- Firmware, FPGA, programmable-device and configuration identifiers.
- Manufacturing, programming, calibration, inspection and production-test information.
- Review records, baselines, deviations and traceability to requirements and risk controls.
Verification must identify the approved method, requirement, risk control, product configuration, equipment, samples and acceptance criteria before execution. It should challenge tolerances, supply limits, battery age, temperature, cable length, radio state, accessory load, manufacturing variation and relevant software timing.
A failed test is not erased by a successful retest. Preserve the original result, investigate the cause, assess risk and prior evidence, control any design or test change and justify the regression scope.
Working across functions
Systems engineering
Agree allocation, interfaces, system states, performance budgets, assumptions and traceability.
Software engineering
Define start-up, reset, timing, diagnostics, drivers, programmable content, update and fault responses together.
Mechanical engineering
Resolve enclosure, thermal, grounding, shielding, connector, tolerance and environmental dependencies as one design.
Risk and quality
Connect failure analysis and hardware controls to the device risk file and the controlled design process.
Verification laboratories
Agree configurations, monitoring, acceptance criteria, samples, fixtures and deviations before formal testing.
Manufacturing and suppliers
Design for manufacture and test, control sources and changes, qualify the production system and learn from yield.
The legal manufacturer retains responsibility when design, fabrication, assembly or testing is outsourced. Supplier capability and controls must be proportionate to the significance of the supplied item or service.
Common misconceptions
“My responsibility ends when the schematic is released.”
No. PCB implementation, verification, transfer, production behaviour, change and field investigation all depend on electronics expertise.
“A certified component makes the device compliant.”
No. Ratings, conditions of acceptability, integration, interfaces and finished-device behaviour still require assessment.
“Passing EMC means the hardware is safe.”
No. The test must use representative configurations and monitor defined safety and performance criteria during and after disturbances.
“A form-fit-function replacement is equivalent.”
No. Substitution can affect safety, EMC, reliability, firmware, manufacturing and previous evidence; it requires controlled impact assessment.
“No fault found closes a complaint.”
No. Intermittent failures may depend on configuration, environment, accessories or production history and need an evidence-based investigation.
Electronics engineer’s practical checklist
- Understand the purpose, users, environments, system boundary and applicable standards.
- Make hardware requirements and interfaces measurable, approved and traceable.
- Expose safety controls, energy paths, states, diagnostics and dependencies in the architecture.
- Control schematics, PCB, components, programmable content, analyses and configuration.
- Verify risk-control implementation, effectiveness and production reproducibility.
- Use representative configurations, objective criteria and justified worst cases.
- Ensure suppliers, manufacturing, programming and test systems are capable and controlled.
- Feed nonconformities, changes and post-market information back into design and risk management.
Authoritative starting points
- ISO 13485:2016 — Medical-device quality-management systems
- ISO 14971:2019 — Application of risk management to medical devices
- IEC 60601-1 — Basic safety and Essential Performance
- IEC 60601-1-2 — Electromagnetic disturbances
- US FDA Quality Management System Regulation
- Regulation (EU) 2017/745 on medical devices
Exact requirements depend on the device, intended purpose, markets, applied parts, environment and selected conformity strategy. Confirm the applicable editions, amendments, national adoptions, collateral standards and particular standards for the project.