Medical device software development.
The embedded software and electronics inside clinical instruments and therapy devices: firmware, measurement chains, touchscreen operator interfaces and connectivity. Engineered alongside the hardware, from bench prototype through to units that hold up in a hospital.
Where medical device software gets difficult.
Working code is not the same as evidence.
A device can behave correctly on the bench and still lack what the technical file needs: requirements traced to tests, a record of what was verified, and a defensible account of the software's own risk contribution. That evidence is far cheaper to produce during development than to reconstruct afterwards.
The prototype and the clinical unit are different products.
A proof of concept demonstrates that the measurement or the therapy works. A unit that goes into a hospital has to survive being switched off mid session, recover from a disconnected sensor, produce the same reading twice, and be serviceable by someone who did not build it.
Measurement integrity is the whole device.
For a diagnostic instrument, the number on the screen is the product. Sampling, timing, filtering, calibration and drift all sit in the embedded layer, and a fault there is not visible to the clinician using it.
Interfaces are used under time pressure.
Operator screens are used by clinicians mid procedure, not by engineers reading a manual. Where a control sits, what happens on a mis tap, and what the device does when a protocol is interrupted are engineering decisions with clinical consequences.
How the engineering is organised.
Requirements traced through to test.
Software requirements, architecture, implementation and verification are kept linked, so the relationship between what the device is supposed to do and what was tested remains visible as the product changes.
Risk led, not risk documented afterwards.
Hazards arising from software behaviour are identified early enough to change the architecture, because mitigations designed in are cheaper and more effective than mitigations bolted on.
Deterministic where the clinical outcome depends on it.
Dose control, stimulation timing, measurement windows and safety states are designed around bounded timing and verified against it, not assumed from typical behaviour.
Third party components treated as what they are.
Operating systems, stacks and libraries brought into a device are identified, version pinned and assessed rather than absorbed silently, so the software of unknown provenance in the product is known and justified.
Built to be handed over.
Source, build environments, configuration and test material are structured so the client's own team, a notified body, or the next engineer can pick the product up.
Medical device software development services.
Medical device firmware development
Bare metal and RTOS firmware for instruments and therapy devices, developed against the timing, power and safety constraints of the actual hardware.
Embedded software under IEC 62304 practices
Software lifecycle work structured to the practices set out in IEC 62304, including architecture, unit and integration verification, and the records that support them.
Clinical measurement chains
Sensor front ends, sampling, filtering, calibration and derived values, characterised so a reading is repeatable across units and across sessions.
Closed loop therapy control
Control loops where the device responds continuously to sensor feedback: dose, pressure, flow, stimulation intensity, with defined behaviour at every limit.
Touchscreen and operator interface development
Clinical GUIs running on the device itself, including protocol selection, live display, service modes and the data layer behind them.
Connectivity, records and cloud
BLE, WiFi and cellular connectivity, session records reduced on the device, synchronisation to a hospital or client cloud service, provisioning and secure update.
Prototype to trial unit hardening
Taking a working bench proof of concept to repeatable units: enclosure integration, power path, fault recovery, manufacturing repeatability and field diagnostics.
Verification, test evidence and production transfer
Functional, timing, endurance and environmental testing, the records that accompany them, and the manufacturing handover that follows.
MCU and SoC firmware for diagnostic and therapy hardware, written to the board in front of us.
Clinical and physical sensing modules that each speak their own protocol, brought under one interface.
Filtering, feature extraction and derived clinical values computed at the edge rather than off the device.
Yocto and Buildroot builds, update infrastructure and service partitions for application class instruments.
Qt, QML and LVGL interfaces for touchscreen instruments, including service and calibration modes.
On device storage, reduction of a session to what matters, and upload to a hospital or client cloud.
Secure boot, signed firmware, encrypted transport and controlled update paths.
Test hooks, logging and diagnostics designed into the architecture rather than retrofitted for testing.
Requirements, architecture and test records kept linked to one another as the software changes.
Production test fixtures, configuration management and manufacturing handover.
From bench prototype to units a hospital can use.
Tell us what the device does and where the engineering currently stands.
What the engineering leaves behind.
The measurement chain owned end to end.
Sensor front end, sampling, firmware and the number the clinician reads are engineered by one team, so a discrepancy is traced through the chain rather than negotiated between suppliers.
Devices that behave the same way twice.
Measurement and therapy behaviour is characterised across units and across conditions, so repeatability is a property of the design rather than of a good sample.
Evidence produced alongside the product.
Architecture, verification and test records accumulate during development, in a form that supports the client's own quality system and technical file.
A prototype that becomes a device.
Bench proofs of concept are taken through the engineering that makes them buildable, serviceable and fit to put in front of clinicians.
Work that transfers to the client's file.
Source, build environments, configuration and the engineering record are handed over so the product can be carried forward by the client's own team rather than staying with the team that built it.
Platforms, sensing and tooling.
Embedded platforms
Microcontrollers, application processors and embedded Linux platforms on custom carrier boards.
Representative platforms include STM32, Nordic nRF, NXP i.MX, Texas Instruments and Raspberry Pi Compute Module.
Software environments
Bare metal, FreeRTOS, Zephyr, Embedded Linux, Yocto and Buildroot.
Languages and frameworks
C, C++, Python, Qt, QML and LVGL.
Sensing and measurement
Analogue front ends, ADC and sampling design, calibration routines and signal processing on device.
Interfaces and buses
UART, SPI, I2C, USB, CAN, RS 485, Modbus, Ethernet and analogue interfaces.
Connectivity
BLE, WiFi, cellular, MQTT, HTTPS, device provisioning and OTA update.
Practice and tooling
Git, JTAG, SWD, GDB, OpenOCD, logic and power analysis, continuous integration for firmware builds, and requirement and test traceability.
How a medical device engagement works.
Review
Existing hardware, firmware, requirements, intended use and known problems are reviewed before implementation begins.
Architecture
System behaviour, software structure, hardware interfaces, data flow and the hazards arising from software behaviour are defined before implementation.
Implementation
Firmware, measurement and control code, the operator interface and connectivity are developed against the target hardware, with requirements kept linked to what is built.
Integration
Hardware and software are brought together and characterised as one system, including behaviour at the limits, on interrupted protocols and under fault conditions.
Verification
Functional, timing, endurance and relevant environmental testing against the requirements established for the device, with results recorded as they are produced.
Handover
Source, build environments, configuration, documentation and supporting engineering material are prepared for continued development, regulatory work or manufacture.
Delivered medical work.
NIBRA-CS — portable autonomic neurofunction assessment
Clinical measurement and pressure sensing brought under one interface, the test protocol implemented as written, and sessions reduced on the device and synchronised to the client's cloud service.
Knobzz — trigger point therapy device
Electronics, firmware, closed loop pressure control, enclosure, application and cloud, with treatment responding continuously to sensor feedback.
ODSSY — portable fluid management and infusion platform
Embedded control, dose and flow control and a seven inch touchscreen operator interface for a platform intended for emergency and field care.
C100 — AI enabled environmental monitoring
A compact sensing node for sterile healthcare stores, combining multi parameter sensing, embedded software and an application specific machine learning workflow.
Frequently asked questions.
What is medical device software development? ▼
The engineering of software that runs on a medical device's own hardware — firmware, embedded applications, measurement and control code and the operator interface — carried out under a lifecycle that produces evidence as well as working software.
Do you work to IEC 62304? ▼
Yes. Development is structured to the practices set out in IEC 62304, including architecture, verification activities and the associated records. The standards our engineering is designed toward are set out in full on our standards page.
Who is the legal manufacturer of the device? ▼
The client. We provide engineering and the supporting technical evidence; regulatory submission, conformity assessment and market placement remain with the client.
Which software safety class do you work to? ▼
Whichever class the device's risk analysis establishes. The class affects the depth of architecture, unit level verification and documentation, and is agreed at the start of the engagement rather than assumed.
How do you handle SOUP and third party components? ▼
Operating systems, stacks and libraries are identified, version pinned and assessed for their contribution to risk, so what is inside the device is known and justifiable.
Can you take an existing prototype to trial units? ▼
Yes. This is a substantial part of our medical work. Existing hardware and software are characterised first, then taken forward through the engineering that makes a proof of concept repeatable, serviceable and fit for use outside the lab.
Do you develop the touchscreen interface as well as the firmware? ▼
Yes. The operator interface and the firmware underneath it are developed as one system: protocol selection, live measurement display, service and calibration modes, and the session data layer behind them.
Do you support usability engineering under IEC 62366? ▼
We build interfaces around how the device is actually used and support the client's usability engineering activities, including implementing changes arising from formative evaluation.
What about device cybersecurity? ▼
Secure boot, signed firmware, encrypted transport and controlled update paths are treated as part of the architecture rather than added late.
Who owns the IP? ▼
You do. All intellectual property developed during an engagement is assigned to the client as it is paid for, the engineering records produced alongside the software included, so nothing the technical file depends on stays with a supplier. The full position is set out on our IP and ownership page.
What do we receive at handover? ▼
Source code, build environments, configuration, and the architecture, verification and test material produced during development — handed over as sources with build instructions rather than binaries, in a form the client's quality system can absorb.