Medical device firmware development — IEC 62304 Class B aligned, 510(k)-ready

Why founders hire HydraTech to build their medical device firmware

Medical device firmware fails in two predictable ways. The first is a regulatory failure: working software that lacks the requirements, traceability, and verification evidence the FDA expects, forcing a re-write the week before submission. The second is a clinical failure: code that meets every requirement on paper but loses BLE in a noisy ICU, mis-detects motion as arrhythmia, or drains the battery before a 24-hour Holter recording finishes. We have rescued both kinds of programs.

HydraTech's medical firmware team has shipped continuous heart-rate, blood pressure, SpO₂, ECG, EEG, and biopotential devices for US and international clients. Our engineers debug at the silicon level — Nordic Power Profiler Kit II, Joulescope, J-Link Ultra, Saleae Logic MSO — and our process meets the IEC 62304 software lifecycle expectations that your QA/RA partner needs for FDA submission.

What we deliver

Our IEC 62304 process

We adapt the depth to your software safety classification — Class A is lighter, Class B is the most common, Class C engagements run jointly with your regulatory partner. The shape stays the same:

1. Software development plan. One-page-per-section plan covering safety classification, lifecycle model, tools, and configuration management. Signed before code is written.
2. Software requirements. Each system requirement traces down to one or more software requirements. We use a lightweight matrix that lives next to the code, not a 200-page Word document.
3. Architecture & detailed design. A clear separation of safety-relevant items, third-party components (SOUP), and the test surface. Documented as Markdown that ships with the source.
4. Implementation & unit verification. Code reviewed against your style guide, unit-tested on host with Unity / GoogleTest, and continuously built in CI.
5. Integration & system verification. Hardware-in-the-loop tests on real boards, BLE conformance, OTA round-trip tests, and clinical signal regression on captured biosignal datasets.
6. Release. Signed binary, release notes, anomaly log, and trace-matrix snapshot. Your regulatory partner attaches it to the submission.

Hardware platforms and protocols we ship in production

Layer	What we ship in production
MCUs	Nordic nRF52832 / nRF52840 / nRF5340, STM32L4 / U5, Espressif ESP32 / ESP32-S3, Qualcomm QCC51xx, ATtiny (for accessories)
RTOS & SDKs	Zephyr RTOS, nRF Connect SDK, FreeRTOS, ESP-IDF, bare-metal (HAL + interrupts)
Biosignal front-ends	TI ADS1299 (EEG / biopotential), MAX86150 / MAX30102 (PPG / SpO₂), accelerometers and motion sensors for artifact rejection
Connectivity	BLE 5.x (peripheral + central), Wi-Fi, LoRaWAN, NB-IoT / LTE-M, USB-CDC, MQTT over TLS
Cloud	AWS IoT Core, Device Shadow, IoT Jobs (fleet rollouts), Azure IoT Hub, custom REST + WebSocket pipelines
Security	ARM TrustZone, secure boot (MCUboot), code signing, ATECC608 / nRF KMU-based key storage, signed and encrypted OTA
Tools we live in	SEGGER J-Link Ultra+, Nordic PPK II, Joulescope JS220, Saleae Logic MSO, GDB / Ozone, GitHub Actions CI

Proof — medical firmware programs we have shipped

These case studies are not stock photos. Each one is firmware our team wrote and shipped.

Engagement models

Most medical firmware programs run as milestone-based engagements with a fixed-price discovery phase up front. The discovery phase produces a software development plan, requirements outline, and a calibrated estimate for the rest of the build. From there you can choose:

• Fixed-scope program. 12–24 weeks for a full firmware build from spec to release. Best when the hardware is locked.
• Time-and-materials with a weekly cap. Best for iterative work, in-house teams that need a senior firmware lead, or programs where the hardware is still moving.
• Audit & rescue. 2–4 weeks. We come in, read the code, profile power and BLE behavior, and produce a written audit with a fix plan. Useful when an existing build is stuck before submission.

FAQ

Do you handle FDA 510(k) submission directly?

We do not act as the regulatory submitter. We partner with your QA/RA consultant or in-house regulatory team and deliver firmware, design records, traceability matrix, V&V protocols, and test results that drop straight into a 510(k) package.

Which IEC 62304 software safety classifications can you handle?

Class A and Class B are routine for us. For Class C devices we will scope a joint engagement with your regulatory partner so lifecycle activities meet the higher rigor.

What deliverables do I receive at the end of the engagement?

Source code in your repository with IP assigned, signed release binaries, the CI build pipeline, design and architecture documents, requirements-to-test traceability matrix, software unit and integration test results, anomaly log, and release notes suitable for design history file inclusion.

Can you implement the FDA Premarket Cybersecurity Guidance controls?

Yes. Secure boot, code-signing, encrypted at-rest storage, certificate-based authentication, and SBOM generation are part of our default stack. Threat-modeling and risk-management activities are run jointly with your security and regulatory partner.