Connected Medical Devices: From Radio to Clinician

Most modern medical devices talk. They connect to phones, gateways, clouds and clinicians, often over the same protocols consumer electronics use. Connected medical devices have moved from niche to default in the last five years, but the regulatory and architectural choices that make them safe at scale are still poorly understood.

This raises a practical question:
How do you design a connected medical device that meets MDR cybersecurity expectations, holds up under real-world signal conditions and stays clinically useful over its lifecycle?

This guide treats connected medical devices as a layered stack: radio, protocol, backend and clinical workflow. We walk through what MDR Annex I §17 demands on cybersecurity, what GDPR adds for patient data and where teams burn budget in the connectivity layer. By the end you will have a workable mental model of the layers, the standards and the operational commitments connectivity adds on top of standard MDR.

Table of Content

Why Connected Medical Devices Are Different

Connected medical devices share most of the regulatory structure of any other medical device under MDR. Classification rules apply, technical documentation requirements apply and clinical evaluation applies. So far, nothing unique.

Where they diverge is in three layered areas: the connectivity stack itself, the cybersecurity expectations that come with networked operation and the post-market lifecycle complications that arise when software ships over the air. Each area brings its own standards, its own risk surface and its own regulatory weight. So the same product, once connected, carries three more regulatory commitments than its offline equivalent.

Take a wearable with no app: a standard medical device shape, classified under Rule 9 or Rule 10, with the usual technical file and clinical evaluation. Add the app, the cloud and the data feedback to a clinician portal and the same product now has four interfaces to validate, four risk surfaces to defend and four moving parts in its post-market lifecycle. Connected medical devices are the integration of those layers.

-> In short: moving from offline to networked adds three regulatory layers on top of standard MDR: the connectivity stack, the cybersecurity surface and the OTA lifecycle. Each one needs its own design decisions and its own evidence pack.

What To Do:

Map the device's connectivity stack on paper before architecture decisions lock in.
Treat cybersecurity as a Phase 1 design constraint. It should not be a Phase 4 documentation task.
Plan OTA and software change governance into the QMS from the start.

The Connectivity Stack: From Radio to Clinician

The way to think about a connected medical device is as a stack of four layers, each with its own standards, risk surface and post-market obligations. Every layer carries its own evidence pack at audit.

The Radio Layer

The radio layer is where the device sends and receives bits. BLE dominates wearables and low-power sensors, while NB-IoT and cellular show up in standalone or implantable products that need wide-area coverage. Wi-Fi is common in hospital-bound equipment, with LoRa appearing where range outweighs throughput.

EMC and frequency rules live here. IEC 60601-1-2 governs electromagnetic compatibility for medical electrical equipment, including the radio interface, and regional spectrum rules (CE for the EU, FCC for the US) sit on top. So the radio layer carries a power budget, an environment-of-use specification and a documented signal-reliability profile.

The Protocol Layer

Above the radio sits the data protocol. MQTT, CoAP and BLE GATT profiles handle device-to-device or device-to-cloud messaging, while HL7 FHIR and IEEE 11073 govern medical-data interoperability with hospital systems. Pairing protocols and OTA update channels also live in this layer.

Software safety classification lands here. IEC 62304 sets the lifecycle expectation for medical device software at safety class A, B or C and most connected device software lands B or C. So the protocol layer is where the software change-control mechanics actually have to be defined.

The Backend Layer

The backend is everything that lives on the server side. A device registry, a data store, an authentication service, an event bus and the integration paths into EHRs and clinical research databases sit here. For most products, this is where GDPR obligations crystallise and where ISO 27001 alignment becomes a credibility issue with hospital procurement.

EN IEC 81001-5-1:2022 anchors the cybersecurity expectation for this layer. It defines a cybersecurity lifecycle for health software, including the cloud and integration components and it is treated as the current state of the art in MDR cybersecurity guidance. So manufacturers not applying it have to justify equivalence at notified body review.

The Clinical Workflow Layer

At the top of the stack is the clinician. Connected medical devices land in a clinical context: a portal, an alert routing system, an escalation pathway and often an integration into the patient's electronic record. Decision support, risk thresholds and on-call routing all live here.

The clinical workflow layer carries the clinical evaluation. MDCG 2020-13 sets the expectation: evidence of safety and performance in the intended use, with traceability through every layer below. Where the connectivity layer affects clinical decisions, the evidence has to follow.

-> In short: the four layers (radio, protocol, backend, clinical workflow) carry distinct standards and risk surfaces. Audit-grade evidence has to track per layer.

What To Do:

Diagram the stack before any sprint planning. Mark which radios, protocols and standards each layer uses.
Map each layer to its standard (IEC 60601-1-2, IEC 62304, EN IEC 81001-5-1, MDCG 2020-13).
Tie the technical file to the stack so traceability holds per layer at audit.

MDR Cybersecurity Expectations for Connected Devices

Cybersecurity carries more weight under MDR than most teams expect. Three documents define what good looks like.

Annex I §17 in Plain English

MDR Annex I §17 sets the general safety and performance requirements specifically for medical devices that incorporate software. It requires the manufacturer to apply principles of development lifecycle, risk management, verification and validation, and to lay out minimum requirements for hardware, IT networks and IT security measures. So Annex I §17 is the legal anchor and everything else flows from it.

The wording is short, but the operational consequences are not because implementation expectations come from MDCG 2019-16 and EN IEC 81001-5-1:2022.

MDCG 2019-16 and IEC 81001-5-1

MDCG 2019-16 is the working guidance for cybersecurity in medical devices. It defines three domains: general principles such as security-by-design and defence-in-depth, cybersecurity-related processes such as security risk management, and technical specifications. Most articles ranking for connectivity-and-MDR topics cite it as the framework.

EN IEC 81001-5-1:2022 is the under-cited document. It is the current state of the art for health software cybersecurity lifecycle and it applies to all health software including the cloud and integration components. A manufacturer not applying it has to justify equivalence and increasingly the notified bodies want to see that justification in writing.

The implication for new builds is that cybersecurity-by-design has to start at week one. A documented threat model, a security architecture diagram, key management and a software cybersecurity lifecycle all become Phase 1 artefacts.

-> In short: cybersecurity expectations under MDR run from Annex I §17 through MDCG 2019-16 to EN IEC 81001-5-1:2022. The third one is the standard most teams underweight.

What To Do:

Build a threat model and security architecture diagram at Phase 1.
Decide whether EN IEC 81001-5-1:2022 applies (it usually does) and document the basis.
Run an SBOM (software bill of materials) and a vendor cybersecurity assessment alongside the QMS.

Data, Interoperability and the GDPR Overlay

Connectivity moves data and where it moves, regulations follow.

GDPR for Connected Device Data

Patient data flowing through a connected medical device usually qualifies as a special category of personal data under GDPR Article 9. So the manufacturer is either a controller or a joint controller of data, alongside the healthcare provider operating the device. Either role brings legal-basis, transparency, data-minimisation and breach-notification obligations.

Practical consequences for the backend layer are concrete and data residency in the EU matters for many member states. Pseudonymisation, encryption at rest, encryption in transit and access logging all become design decisions that get audited.

Interoperability Standards

HL7 FHIR is the modern interoperability standard for healthcare data exchange. Most EHRs in the EU and US either support FHIR natively or expose a FHIR gateway and integration projects with hospital IT increasingly assume it as default. Where FHIR is not enough, IEEE 11073 covers medical device communication semantics.

Interoperability is regulated. Article 19 of the MDR requires the manufacturer to assign a UDI and register the device in EUDAMED and the data structures behind both presume specific interoperability standards. So picking the protocol layer carelessly shows up in the technical file as a gap.

-> In short: GDPR and interoperability sit alongside MDR for connected products. Both shape backend and protocol design decisions at Phase 1.

What To Do:

Decide controller or joint-controller status with the healthcare provider before launch.
Default to FHIR for hospital interoperability and document the rationale.
Map data flows end-to-end so GDPR Article 30 records (record of processing) are audit-ready.

Where Connectivity Adds Real Clinical Value

Connectivity earns its place when it changes clinical reality. The clinical value of a connected medical device comes from what the connection enables: remote monitoring, real-world evidence loops, predictable software updates and integration into clinician workflow.

Remote Monitoring and Real-world Evidence

Remote monitoring is the most established connected medical device use case. Devices stream vital signs or device-state data to a clinician portal between visits, surfacing trends that would otherwise need an outpatient appointment to detect. If the device is Class IIa or above, the monitoring stream feeds back into the evaluation through the PMCF plan.

PMCF for connected medical devices can run as a structured registry of device-generated data. The manufacturer pulls sensor readings, alarm events and intervention outcomes into a defined CEAR update cadence. So connectivity supplies the post-market clinical evidence loop directly.

OTA Updates and the Post-market Lifecycle

Software updates over the air are the operational payoff of connectivity. Bug fixes, security patches and incremental algorithm improvements ship to the installed base without a recall or a service visit, provided the OTA channel and change control sit inside the QMS. Done well, OTA is the operational difference between a connected device and a legacy device with a USB port.

Done badly, OTA becomes the path to an audit finding. So treat the OTA channel itself as a regulated subsystem, with signed images, secure boot, rollback and a documented change control process for every release.

-> In short: connectivity earns its weight when it enables remote monitoring, RWE feedback into PMCF and disciplined OTA. Each carries its own audit trail.

What To Do:

Define which clinical outcomes the connectivity is supposed to improve, before the architecture.
Tie the remote monitoring stream to the PMCF plan with named data points and cadence.
Build OTA as a QMS-governed process from day one, with signed images and rollback.

Pitfalls We See in Connected Medical Devices

Across the connected medical device builds we have worked on, five failure modes recur. All of them are avoidable with a few specific habits.

1. Pairing UX as Afterthought

Patient pairing is designed for the engineer who built it, instead of the 75-year-old patient who has to use it. The result is high onboarding drop-off, repeated support calls and lost data days where the device sits unpaired in a drawer.

Fix: run a usability test with the actual target population at Phase 2 prototype stage, before pairing UX is locked.

2. Signal Reliability Under-tested

BLE works on the bench and falls over in a hospital corridor with 200 other 2.4 GHz radios competing. Real-world signal testing in the actual environment of use is often skipped or run too late.

Fix: validate range, signal-to-noise and packet-loss profiles in the actual environment of use.

3. OTA Update Governance Missing

Software updates ship over the air without a documented change-control process under the QMS. The notified body asks how versions are tracked, how the rollback path is defined and how clinical impact is evaluated per release.

Fix: design OTA as a QMS-governed process with signed images, change classification and a release register from the first build.

4. Cybersecurity as Phase 4 Thinking

Threat modelling, secure boot, key management and security architecture all show up as documentation at submission time. MDR Annex I §17, MDCG 2019-16 and EN IEC 81001-5-1:2022 expect cybersecurity-by-design from week one.

Fix: build the threat model, security architecture and SBOM in Phase 1, alongside the QMS scaffold and risk file.

5. Backend as a Black Box

The cloud and data backend sit outside the technical file. At audit, the notified body asks for evidence on data residency, access controls, encryption and integration testing and there is no trail.

Fix: include the backend in scope of the technical file, with its own architecture description, threat model and verification evidence.

-> In short: the five failure modes are individually avoidable. They become fatal when accumulated two or three in parallel during a connected medical device build.

FAQs: Connected Medical Devices Questions

How are connected medical devices classified under MDR?

A1: Classification follows the same Annex VIII rules as any other medical device. The intended use, the type of risk and the contact with the body or with vital functions determine the class. For software components, Rule 11 applies and most clinical decision-support or monitoring software lands Class IIa or higher. The connectivity itself does not change the class, but it usually adds Class IIa expectations on the software stack.

Q2: What cybersecurity standards apply to a connected medical device?

A2: Three documents define the working framework. MDR Annex I §17 sets the legal expectation. MDCG 2019-16 provides the operational guidance with three cybersecurity domains: general principles, processes and technical specifications. EN IEC 81001-5-1:2022 covers the health software cybersecurity lifecycle and is the current state of the art that notified bodies expect manufacturers to apply or justify equivalence to.

Q3: Does a connected medical device need a notified body if it would be Class I offline?

A3: Class I non-sterile, non-measuring devices are self-certified, regardless of connectivity. However, most connected medical devices include software that triggers Rule 11 under Annex VIII, which moves the software (and therefore the product) to Class IIa or higher. Class IIa and above require a notified body audit of the QMS and the technical documentation. For more on Rule 11, see our SaMD explainer.

Q4: Can software updates ship over the air without re-certification?

A4: Yes, if the OTA channel, the change control process and the change classification are all defined inside the QMS and consistent with MDCG 2020-3 on significant changes. Updates that change intended use, performance claims or risk profile are significant and trigger re-submission. Bug fixes, security patches and minor enhancements within the existing technical documentation usually do not.

Closing Thoughts

Connected medical devices are the default direction of travel in MedTech. The work to make them safe, defensible and clinically useful is structurally larger than for offline devices, but it is well-defined: the stack, the cybersecurity framework, the GDPR overlay and the post-market lifecycle are all documented in standards and guidance. Teams that treat the connectivity layer as a Phase 1 design constraint reach certification with predictable timelines.

If you are at any stage of a connected device build and want a second pair of eyes on the connectivity stack, the cybersecurity architecture, the GDPR setup or the OTA governance, that is exactly the work our MedTech Product Development service exists for.