Medical device software has to work reliably and be supported by the right evidence
We engineer medical devices across hardware, firmware, and cloud, with design controls and DFMEA matched to the device class. That includes the embedded software, the backend for connected devices, the risk work that feeds into the design, and the verification needed before a system goes into production.
What does the device class actually change?
The device class affects the amount of evidence, testing, and design control a programme needs. Class I covers lower risk devices under general controls, handheld instruments or simple monitoring. Class II is moderate risk and usually needs demonstrated equivalence to something already cleared. Class III is life sustaining, implantable or first of its kind, and carries the most rigorous premarket approval.
Software has its own safety classification as well. IEC 62304 defines the lifecycle for medical device software and sorts it into safety classes: Class A for software that cannot contribute to a hazard, Class B where it can contribute to a non serious injury, Class C where it can contribute to death or serious injury. Firmware on a therapeutic or implantable device is frequently Class C. ISO 14971 covers risk management for the device as a whole, and the firmware's hazards feed into it.
Design controls tie the pieces together. In the US they are required under 21 CFR 820.30 for most Class II and Class III devices, with equivalent expectations under ISO 13485 in most other markets. They connect user needs to design inputs, design inputs to design outputs, and both to the verification that proves the device was built right and the validation that proves the right device was built. A traceability matrix ties each requirement to the output that implements it and the test that proves it, and the design history file holds all of it. That file is what an auditor asks to see.
Class I
General controls. Handheld instruments or simple monitoring.
Class II
Usually needing demonstrated equivalence to something already cleared.
Class III
Life sustaining, implantable, or first of its kind, requiring the most rigorous premarket approval.
What do we build?
Three areas, which come together on a connected device.
Firmware. The embedded software that reads the sensor, drives the pump, controls the display, and on an implantable device does all of that for years without a service visit.
The cloud platform behind it. A glucose meter may sync with a phone app and clinician portal. A monitor may send telemetry to a hospital system. A therapeutic device may report usage and receive configuration. The backend handles device provisioning and identity, telemetry ingestion as the fleet grows, patient data with the required retention and permissions, clinician and patient interfaces, and fleet management for firmware updates and device health. Device data is more useful when it can reach the clinical record, which is why publishing observations as HL7 FHIR resources can be preferable to a proprietary API.
Design controls and DFMEA need to be part of the development process, not paperwork added at the end. Design failure mode and effects analysis asks, for every component and function, what happens if it fails, and rates each failure mode for severity, occurrence and detection. Done early it changes the design. Done late it mainly records decisions already made, and the difference shows up in how many hazards get engineered out versus how many end up on a warning label.
Why is firmware the hard part?
Because several constraints have to work together, and they often compete with each other.
Real time behaviour has to be predictable. A drug delivery device or a sterilizer has timing requirements that have to be met every cycle. The architecture choice, bare metal or a real time operating system or embedded Linux, is made to guarantee them, and the choice has to be justified rather than assumed.
Safety mechanisms are part of the design. Watchdog timers, redundant checks on critical values, defined safe states on fault, and fault logging. When something fails, the device needs to move into a defined safe state.
Power and battery life affect the rest of the firmware design. Wearables and implantables run on batteries nobody can swap casually, so low power design, from sleep states to sensor duty cycling, is a core firmware concern rather than a late optimisation.
Updates after release introduce another risk. Secure boot, signed images, and update pipelines that can roll back on failure are the standard pattern, and regulators now expect them.
Cybersecurity is now part of the premarket work. Threat modelling across the full path, a software bill of materials, and a plan for handling vulnerabilities after release. Most of that has to be implemented in firmware, and on a connected device it extends to every system the device touches.
How do you verify a device at production scale?
Systematically, with every test tied back to a requirement. Unit tests, integration tests, hardware in the loop testing against the real device, and regression suites that run on every change.
At production scale, that means automated test infrastructure rather than people working through checklists. Device farms can run the same test cycles across many units. That is what makes it possible to ship a change to a device already in the field and know what it did.
The cloud side carries the same obligation. Changes to the platform are changes to a regulated system, so release management, validation of changes and audit trails apply there just as they do in firmware. Availability matters too, because a platform a clinician depends on cannot go dark, which means redundancy, monitoring and disaster recovery that has actually been rehearsed.
What does an engagement usually look like?
The work follows the programme, with the depth at each stage based on the device risk, what already exists, and how new the design is.
Concept and feasibility establish the device class, risk profile, and what needs to be proven before the design is committed.
Design and implementation cover the hardware, firmware, and cloud under design controls, with DFMEA early enough to affect the design.
Manufacturing and post market work covers design transfer, production scale verification, and support after release, including firmware updates and vulnerability handling.
A Class I device with an established design history does not need the same depth as a first of its kind Class III device. The process should match the device.
Settling class, risk, and what has to be proven before anything is committed to.
Hardware, firmware, and cloud built under design controls and DFMEA.
Design transfer, production scale verification, and support after release.
The amount of process depends on the device risk, what has already been developed, and how new the design is.
Medical device firmware
The embedded software that runs the device itself, where real time behavior, safety, and updatability all have to hold at once.
Connected device cloud platforms
The backend a modern device talks to, and the security and privacy obligations that come with the connection.
Design controls and DFMEA
The process discipline that makes a device defensible to a regulator, and how it works in practice rather than on paper.
Questions people ask
Which standards do you work under?
IEC 62304 for the software lifecycle and its 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. DFMEA sits inside the ISO 14971 risk management file rather than beside it.
Do you do hardware as well as software?
We work across hardware, firmware, and cloud, with design controls and validation applied across the system rather than stopping at the boundary between teams. On a connected device, the firmware and backend are part of the same regulated system, and that boundary matters when different vendors are involved.
How do you handle firmware updates on devices already in the field?
Secure boot, signed images, and an update pipeline that can roll back if an update fails. Every update to a released device is a change to a regulated system, so it goes through the same verification and traceability as the original release.
Does the cloud platform fall under the device regulation?
Usually yes. It is an area teams sometimes underestimate. Device data tied to a patient is protected health information under HIPAA, so encryption in transit and at rest, access logging, least privilege and a business associate agreement with the cloud provider all apply, and FDA's premarket cybersecurity expectations cover the platform as well as the device.
When should DFMEA happen?
It should start early enough to influence the design. Rated for severity, occurrence and detection, the failure modes that matter should feed back into the design inputs and the verification plan. Run late, a DFMEA mostly documents decisions that were already made.
Building a device, or working on one that needs firmware, a cloud platform, or the supporting evidence?
Tell us the device, its class, and where you are in the programme.
Start a conversation