Connected Medical Devices Development

Your FAQs on Connected Medical Devices Development

Q1: What counts as a connected medical device?

A1: A connected medical device is a device with a medical purpose that also exchanges data over a network, whether by Bluetooth to a phone, over Wi-Fi to a gateway or over cellular to the cloud. That connectivity is what separates it from a standalone instrument, and it is also what pulls in extra requirements around security, data protection and interoperability.

In practice the category spans wearables and patch sensors, home-monitoring hubs, point-of-care diagnostic devices and hospital equipment that reports into clinical systems. What makes a device a medical device is its intended use, not its form factor, so a wristband that informs a clinical decision is regulated while a general fitness tracker usually is not.

We help you place your product on that line early, because the classification drives the whole engineering and regulatory plan that follows.

Q2: Can you build the full device or only the software?

A2: We can build the full device or slot into whichever layer you need. A connected medical device is a stack: sensors and electronics, the embedded firmware that runs them, a connectivity layer and the companion app and cloud behind it, with security across all of it.

Our teams cover every one of those layers in-house, so you can hand us a concept and get an integrated device back, or bring us in for the firmware, the app or the cloud alone. When we build the whole stack, the advantage is that the hard cross-boundary problems, connectivity, power, security and data flow, are owned by one team rather than argued between vendors.

When we join an existing effort, we map onto your architecture and fill the specific gap, often electronics, RF or embedded, that is holding the build back.

Q3: Which connectivity options do you use, and how do you choose?

A3: The right connectivity depends on range, power budget, data volume and where the data has to go, so we choose it per device rather than by default. Bluetooth Low Energy is the usual choice for a body-worn device talking to a phone, because it is power-efficient and everywhere, while Wi-Fi suits stationary devices that move more data.

For devices that must work without a phone or a local network we use cellular, typically LTE-M or NB-IoT and for messaging between device, gateway and cloud we lean on lightweight protocols such as MQTT over TLS. We design the reconnection logic, buffering and over-the-air update path as part of this, because a link that works on the bench often drops in a real building or on the move.

Where the device has to talk to clinical systems we add interoperability through HL7 and FHIR, so the data lands where clinicians already work.

Q4: How do you handle EU MDR and IEC 62304 for a connected device?

A4: We engineer to the regulation from the first sprint rather than bolting it on at the end. A device with a medical purpose falls under EU MDR, where the classification and, for the software, Rule 11 set how much scrutiny applies and the connected, software-driven nature of the device usually places it in a higher risk class such as Class IIa or IIb.

Our in-house regulatory team works alongside the engineers and aligns the architecture, the software lifecycle under IEC 62304 and the risk management under ISO 14971 as the device is built, inside an ISO 13485 quality system. For devices with electronics we also design to the IEC 60601 electrical-safety series and carry out usability engineering to IEC 62366. That means classification, risk controls, verification and traceability grow with the device, so you reach conformity assessment without a last-minute scramble.

Having regulatory and engineering under one roof also means design decisions are checked against the standard before they are baked into hardware, which is far cheaper than finding the gap after tooling.

Q5: How do you secure a connected medical device?

A5: Security on a connected medical device is an architecture problem, not a feature you add at the end, so we build it into every layer. On the device that means secure boot, a hardware root of trust where the silicon supports it, encrypted storage and signed firmware; on the wire it means authenticated, encrypted transport such as TLS or DTLS and in the cloud it means access control, audit logging and tenant isolation.

We can run threat modelling early, maintain a software bill of materials and carry out penetration testing against recognised checklists such as the OWASP IoT Top 10. This also maps onto the regulatory expectations for connected devices, including the FDA premarket cybersecurity requirements and IEC 81001-5-1, which we can align the design to where your market needs it.

The goal is a device that stands up to both an attacker and an auditor, because for a connected medical device those are increasingly the same test.

Q6: Can the device run offline or process data on-device?

A6: Yes. When latency, privacy, cost or patchy connectivity rule out a round trip to the cloud, we run processing and inference on the device itself. We fit models and signal processing into constrained hardware through techniques such as quantisation and pruning and we trade accuracy against memory, power and battery life so the device performs within its limits.

A connected medical device also has to behave sensibly when the link is down, so we design local buffering and store-and-forward, letting the device keep working and sync safely once it reconnects. Where it makes sense we split the workload, running fast, safety-relevant logic on-device and heavier analytics in the cloud.

We draw on our embedded and wearable engineering experience for exactly this kind of on-device work.

Q7: How do you handle over-the-air updates and support after launch?

A7: Over-the-air update is part of the design, because a device you cannot update safely in the field becomes a liability the moment a bug or a vulnerability appears. We build a signed, tested update mechanism with staged rollout and rollback, so a firmware change across a fleet cannot quietly brick devices or break a feature that was not touched.

Around it we set up monitoring of device health, connectivity and errors, so you can see problems before your users report them. After launch we can run the maintenance, security patching, obsolescence management and support, or hand the device over with the documentation and tooling for your own team to run it, and we are happy to train them to do so.

We agree the support model and update cadence with you up front, so the device stays secure and current over its whole life rather than frozen at launch.