R&D for Problems That
Have No Off-the-Shelf Answer
We take on engineering work where the standard approach does not exist yet — custom algorithms, bespoke acquisition hardware, and clinical systems designed to be verified rather than merely demonstrated.
Engineering services
Algorithm & Signal Processing Development
From raw waveform to defensible inferenceWe design the computational layer for physiological measurement: filtering and artifact handling, predictive state models, and streaming inference that holds its latency budget on real hardware rather than on a workstation.
What's Included
- Signal conditioning, filtering and artifact rejection design
- Predictive physiological and state-space modelling
- Real-time inference pipelines with bounded latency
- Uncertainty quantification and confidence scoring
- Reproducible evaluation harnesses and benchmark suites
- Versioned, reviewable model and signal code
Embedded Hardware & Firmware Design
Custom acquisition where off-the-shelf failsWhen commercial instrumentation cannot meet the requirement, we build the acquisition path ourselves — front-end design, sensor interfacing, and firmware that makes the assembly behave as a single instrument.
What's Included
- Analog front-end and sensor interface design
- Mixed-signal board layout and low-noise considerations
- Microfluidic sample handling and assay integration
- Real-time firmware and device drivers
- EMC, thermal and mechanical design for bench and bedside
- Design-for-manufacture and prototype reproducibility
Clinical System Engineering & Verification
Safety and validation designed in from the startFor systems that will touch patients or clinical decisions, verification and hazard analysis are part of the architecture. We build the test rigs, regression harnesses, and risk documentation alongside the system itself.
What's Included
- System architecture and requirements decomposition
- Hazard analysis and risk-management documentation (ISO 14971 principles)
- Hardware-in-the-loop and simulation testbeds
- Regression suites and verification traceability
- Human-machine interface design and evaluation
- Regulatory pathway strategy and pre-submission support
Research Collaboration & Pilots
Joint work with academic and clinical partnersOur most productive engagements are joint ones. We work alongside academic groups, clinical teams, and companies who need engineering capacity on a problem that is not yet a product.
What's Included
- Scoped engineering pilots with defined exit criteria
- Joint research programmes and shared IP negotiation
- Clinical site coordination for feasibility studies
- Grant and grant-support engineering input
- Publication and open-source collaboration
- Technology transfer and licensing discussions
How An Engagement Runs
Discovery
Understand the problem, the constraints, and what would count as success
Hypothesis
State explicitly what you believe will work and what would falsify it
Prototype
Build the smallest rig that can test the hypothesis honestly
Validate
Verify, document, and decide together whether to continue or stop
Common Questions
Scoped engineering pilots, joint research programmes, and longer development tracks — usually where the problem is technically under-determined and someone needs an engineering team willing to go build and test the thing. We are most useful early, before the architecture has calcified.
Yes, and it is our preferred model. We collaborate with university groups, hospital research departments, and clinical feasibility sites. IP ownership, publication rights, and licensing are negotiated up front rather than discovered at the end.
Not yet. CBMS is an early-stage research and venture lab — we do not currently manufacture, distribute, or service regulated medical devices, and we do not hold device certification. Work in the closed-loop systems track is pre-clinical and exploratory.
Scope and commercial terms are agreed per engagement — project fees, milestone-based funding, or equity depending on the partner and the risk. We price against the engineering actually required, not against a service catalogue. Contact us with the problem and we will come back with a proposed scope.
Often, yes. Debugging and instrumenting existing prototypes is a common entry point — especially when someone has a rig that nearly works and cannot work out which of six assumptions is wrong.
Start With the Problem
Tell us what you are trying to measure or build, and what has gone wrong so far. We will tell you honestly whether we are the right lab for it.