Embedded firmware for medical devices

About the project

The project focused on developing firmware for a diagnostic medical device designed to automate a clinical measurement process that had previously been performed manually.

To bring the system to production readiness, the client required a robust firmware layer capable of safely connecting hardware components with the diagnostic application. The firmware also needed to meet regulatory expectations applicable to medical software.

This required reliable embedded firmware for medical devices, ensuring stable communication between the device hardware and the software layer while supporting future regulatory documentation and product development.

What did our client need?

The client approached us to support the development of firmware for their new diagnostic medical device. The company already had an early prototype demonstrating core functionality, but it required a production-ready firmware layer to ensure stability, regulatory compliance, and seamless integration with the diagnostic application.

They were looking for a partner capable of transforming the prototype into custom firmware for medical devices that would be reliable, well documented, and fully tested.

Our responsibilities included:

• developing firmware enabling safe and precise communication between hardware components and diagnostic software,

• implementing data persistence and configuration storage mechanisms for operational parameters,

• preparing documentation aligned with IEC 62304 and supporting MDR classification needs,

• supporting the client’s team during integration and system verification.

During the initial phase, we also helped refine certain aspects of the device architecture to improve operational safety, including defining firmware-level safeguards for motor movement limits.

How did we approach it?

We treated the existing firmware concept as a proof of concept. This allowed us to preserve working elements while systematically replacing unstable components and improving the architecture, maintaining regulatory traceability throughout the development process.

Phase 1 – Planning & Audit

We began with a rapid audit of the existing firmware, system architecture, and available documentation. During the first month, we worked closely with the client to define the development scope, align on system safety classification, and extend the existing risk management approach.

Phase 2 – Implementation

Over two months, our engineers rewrote the firmware in C for the STM32 microcontroller. The new system implemented a custom communication protocol enabling reliable control of motors, sensors, and temperature management components.

All configuration parameters were stored in non-volatile memory, ensuring that operational settings persisted after device restart.

This architecture formed the foundation for stable embedded software for medical devices designed to support reliable device behaviour in clinical environments.

Phase 3 – Testing & Handover

The firmware was continuously tested on the target hardware after each new functionality was implemented. This iterative approach ensured high quality throughout the implementation process.

Once the firmware became fully operational on the device, our Quality Assurance team performed comprehensive regression testing to verify system stability and performance before transferring the firmware to the client for final software integration and system validation.

Phase 4 – Outcome

The project was completed within the planned schedule and met both regulatory and technical expectations. The successful delivery led to further collaboration between our teams.

Ensuring compliance with regulatory requirements

Because the device is intended for clinical use and falls under the Medical Device Regulation, compliance and documentation were essential from the very beginning.

Together with the client’s regulatory team and product owner, we:

• performed software classification under IEC 62304, confirming a Class A safety level

• supported intended purpose definition and preliminary risk assessment

• ensured traceability between hardware components, firmware modules, and system requirements

• conducted risk analysis using the Failure Mode and Effects Analysis (FMEA) method

• prepared documentation aligned with IEC 62304 and designed to support MDR conformity assessment.

The firmware and its supporting documentation were structured to provide the foundation for future technical documentation and clinical evaluation activities.

Technology and reliability

The new firmware architecture was built for reliability and maintainability, featuring:

• Modular communication protocol ensuring a stable connection between hardware components and diagnostic software

• Persistent configuration layer to store operational settings safely

• Temperature and safety monitoring with automatic protection logic

• Robust error reporting and fallback behaviour in case of hardware faults

• Comprehensive traceability linking requirements, design, code, and test cases

This architecture allowed the client to maintain strong control over device safety while simplifying future software updates and regulatory reviews.

What did we deliver?

• Complete STM32 firmware, rebuilt from scratch

• Documentation aligned with IEC 62304 and supporting MDR classification needs

• Risk management files (plan, preliminary risk register, risk management file)

• Integration and regression testing support

• Communication protocol specification and persistence logic

• Knowledge transfer and ongoing advisory