Software and engineering for medical devices
The engineering spans hardware, firmware, and increasingly cloud, and all of it has to be developed under design controls, documented in a form an auditor can follow, and validated to the depth the device's risk class demands.
Medical device classification and evidence
The classification sets the level of documentation, testing and design control the programme needs. Class I covers lower risk devices under general controls. Class II is moderate risk and often needs demonstrated equivalence to a device already cleared. Class III covers the highest risk devices, including life sustaining and implantable products, and carries the most demanding premarket requirements.
Software has its own classification under IEC 62304. Class A covers software that cannot contribute to a hazard. Class B covers software that can contribute to a non serious injury. Class C covers software that can contribute to death or serious injury. Firmware on a therapeutic or implantable device is often Class C. ISO 14971 covers device risk management, and software hazards feed into that risk work.
Design controls connect the product requirements to the design and the testing. In the US, 21 CFR 820.30 sets those expectations for most Class II and Class III devices, with equivalent requirements under ISO 13485 elsewhere. User needs lead to design inputs, design outputs and then verification and validation. The traceability matrix ties requirements to the design and the tests, and the design history file holds the evidence an auditor will ask for.
Firmware reliability and safety
Timing has to hold on every cycle, which affects the choice between bare metal, a real time operating system and embedded Linux. Safety mechanisms have to be designed in: watchdog timers, redundant checks on critical values, defined safe states and fault logging. On a wearable or implantable, power and product life place additional limits on the design, so low power work starts early rather than at the end.
Connected devices and the backend
A device that connects to a phone, a clinician portal or a hospital system brings the backend into the picture. The platform needs device identity and provisioning, telemetry at the scale of the fleet, a patient data model with the right permissions and retention, and a way to manage firmware and device health. Device data tied to a patient is protected health information, so the cloud side carries those requirements as well.
Design controls in the development process
Design failure mode and effects analysis looks at what happens when a component or function fails and rates the failure for severity, occurrence and detection. Done early, it can change the design. Done late, it mostly documents decisions that have already been made.
Software as the device
When the software is the device, the software lifecycle carries the burden directly: requirements, architecture, unit verification, integration and the evidence that each step was completed. The same applies to updates after release.
Embedded software developed against IEC 62304 expectations for its safety class, with software hazards feeding into the ISO 14971 risk file.
Secure boot, signed images and an update pipeline that can roll back on failure. An update to a released device is a change to a regulated system, so it goes through the required verification and traceability.
Unit, integration and hardware in the loop testing against the real device, regression suites that run after changes, and automated test infrastructure once the volume makes manual checking impractical.
Release management, validation of changes and audit trails on the platform as well as the device, with redundancy, monitoring and a disaster recovery plan that has been exercised.
Concept and feasibility, with the device class, risk profile and evidence requirements settled before design work is committed. Design and implementation, with hardware, firmware and cloud software developed under design controls and DFMEA completed early enough to affect the design. Or manufacturing and post market work, including design transfer, production scale verification, and the updates and vulnerability work needed after release.
Questions people ask
Which standards do you work under?
IEC 62304 for the software lifecycle and safety classes, ISO 14971 for device risk management, and design controls under 21 CFR 820.30 in the US with the equivalent ISO 13485 expectations elsewhere.
Does the cloud platform fall under the device regulation?
It depends on what the cloud software does in the device system. Where device data is tied to a patient, the platform also has to meet the requirements that apply to protected health information. Cybersecurity requirements can also extend beyond the device itself.
When should DFMEA happen?
Early enough to change the design. Done late, it mostly records decisions that have already been made.
Building a device, or carrying one already in the field?
Tell us the device, the class, and where you are in the programme.
Start a conversation