Software for connected medical devices
Connectivity, ingestion, dashboards, companion apps and fleet management around your device.
Device engineering and platform engineering are different disciplines
Device companies are strong in hardware, firmware and regulatory work. The platform around the device needs distributed systems, data pipelines and healthcare integration. Built in-house it struggles at volume; bought from a general agency it misreads what the device sends.
What we build for device companies
Device connectivity
BLE, Wi-Fi, cellular and gateway connectivity, including provisioning, pairing and certificate management.
Data ingestion at scale
Services that accept device data reliably, handle retries and duplicates, and cope with a whole fleet reconnecting at once.
Device management
Registration, configuration, firmware status, connectivity health and battery state across the estate.
Companion applications
Patient or operator applications for setup, readings, alerts and support.
Dashboards
Views for care teams, for your support desk and for your own product team.
Device analytics
Usage, adherence, reliability, fault patterns and cohort analysis across the fleet.
Clinical integration
Device data written into EHR systems through FHIR or HL7 so that it reaches clinicians.
Customer-facing APIs
Interfaces your own enterprise customers can integrate with.
The platform around the device
Regulatory position
We build software, data services and applications that work with connected devices. We are not a regulated medical device manufacturer and we do not hold ISO 13485 certification. Where your platform or a component of it falls within a medical device classification, we work alongside your regulatory and quality teams, supply the technical documentation their process requires, and follow the development controls they specify.
What this looks like in practice
| Scenario | What is needed |
|---|---|
| A device is ready and there is no platform | Connectivity, ingestion, storage, dashboards, fleet management, then integration |
| A platform exists but will not scale | Assessment of the current design, then targeted rebuild of the ingestion and storage layers |
| A hospital customer wants device data in their EHR | FHIR or HL7 integration, with decisions about frequency and detail |
| Support cannot see why a device in the field is failing | Fleet visibility, diagnostics and alerting on connectivity and battery |
| The product team wants usage data | Analytics across the fleet, with cohorting and adherence measures |
Frequently asked questions
Yes, and it is usually necessary. The protocol, payload format and connectivity behaviour are decided jointly, because choices made in firmware determine what the platform can do.
That is an architecture question rather than a fixed number. We design for the fleet size you expect within three years, not the one you have at launch, because rebuilding the ingestion layer later is disruptive.
No. Certification is yours, with your regulatory advisers. We provide the technical documentation and follow the development controls your quality system requires.
Yes, through APIs we build for that purpose. It is worth planning early, because a platform designed only for your own applications is awkward to open up afterwards.
Talk to us about your device platform
Bring the device, the fleet size you are planning for and the systems the data needs to reach.