Topic 4.4 — Connected Devices, IoT & Clinical Engineering

In health and care, the connected device is where software meets the patient's body, so how you manage the fleet of pumps, monitors, scanners and wearables is a clinical-safety, cyber-security and public-trust decision, not a facilities line item.

Why this matters in health and care#

A modern hospital runs on machines that touch patients directly and talk to the network constantly. Infusion pumps meter drugs by the microlitre, ventilators keep people breathing, monitors watch vital signs, imaging scanners emit ionizing radiation, and building management systems hold the temperature of vaccine fridges. A growing share of these are connected: they push data into records, pull configuration from servers, and expose management interfaces. When one behaves unexpectedly, the failure is not an inconvenient outage — it can be a dose error, a missed alarm, or a corrupted image that changes a diagnosis.

That is why device management sits at the intersection of three duties you already carry. It is a clinical-safety duty, because a device fault or a bad patch can harm a patient (see Topic 1.6 — Clinical Safety & Risk Management). It is a cyber-security duty, because connected clinical kit is one of the largest and least-governed attack surfaces in the estate (see Topic 1.7 — Information Governance, Data Protection & Cyber Security). And it is a regulatory duty, because medical devices are regulated products with post-market obligations that fall partly on you as the operator.

The stakes are widening, not narrowing. Care is moving into the home through wearables and remote monitoring, so the "device estate" now includes kit you do not own on networks you do not control. Devices last far longer than the software inside them, so a scanner bought for a fifteen-year clinical life may run an operating system that lost security support after five. Ransomware crews have learned that clinical technology is fragile, unpatched and mission-critical — a profitable combination. Treating connected devices as someone else's problem is how organizations discover, mid-incident, that nobody owns them.

Core concepts#

A medical device is any instrument, apparatus or software intended by its manufacturer for a medical purpose — diagnosis, monitoring, treatment or prevention — that does not achieve its effect through pharmacology. A connected medical device adds a network interface: it sends or receives data, or can be managed remotely. The Internet of Medical Things (IoMT) is the health application of the wider Internet of Things (IoT) — the population of sensors and everyday objects that connect to networks and exchange data. In a care setting the IoMT spans bedside monitors, smart pumps, wearables, home sensors and the clinical-grade middleware that stitches them together.

Clinical engineering is the specialism, sitting within biomedical engineering, responsible for the safe and effective use of medical technology in a healthcare organization. In the NHS these teams are often called medical engineering, medical physics, or Electronic and Biomedical Engineering (EBME). Medical device management is their core discipline: maintaining an accurate inventory, planned preventive maintenance, calibration, repair, safety alerts, training, and controlled decommissioning at end of life.

Operational technology (OT) is the hardware and software that monitors or controls physical processes and equipment, as distinct from conventional information technology (IT) that processes business data. Clinical devices and building systems are OT: they have real-world physical effects, long lifecycles, and constraints (uptime, certification, real-time behaviour) that make ordinary IT practice — reboot, patch, replace — risky or forbidden without the manufacturer's blessing. The attack surface (attack surface) is the sum of points where an attacker could enter or affect a system; connected devices enlarge it dramatically because each one is a small, often un-hardened computer on your network.

Two controls recur throughout this topic. Network segmentation is the practice of splitting a network into isolated zones so that a compromise in one cannot spread freely to others — the single most effective mitigation for un-patchable clinical kit. Asset visibility is simply knowing what you have: every device, its location, firmware, ownership, network behaviour and support status. You cannot protect, patch or retire what you cannot see.

Finally, the regulatory frame. In the UK the Medicines and Healthcare products Regulatory Agency (MHRA) regulates medical devices, and postmarketing surveillance — monitoring safety and performance after a product is on the market — is a shared obligation between manufacturers and the operators who use and report on the devices. Wearable technology and remote patient monitoring extend all of these concepts beyond the building, into the patient's home and pocket.

Best practices#

1. Build and maintain one authoritative device inventory. You cannot manage, secure or retire what you have not counted. Merge the clinical-engineering asset database with network-discovery data so the inventory records not just make, model and location but firmware version, operating system, network behaviour, data flows, ownership and support status. Treat the inventory as a living safety system with a named owner, reconciled continuously against what is actually on the wire, not a spreadsheet refreshed once a year for the audit.

2. Bring IT, clinical engineering and cyber-security into one governance forum. These devices fall between three teams, and the gaps between them are exactly where incidents live. Establish a joint medical-device security group with clear decision rights over onboarding, patching, segmentation and decommissioning, and give it a standing link to the clinical safety function. The clinical engineers understand the device and the patient risk; the security team understands the network threat; neither can act safely without the other.

3. Segment the network and default to least connectivity. Most clinical devices cannot be hardened or patched on your timetable, so contain them instead. Place devices in segmented zones with tightly controlled flows, allowing only the connections a device genuinely needs and denying the rest, so a compromise cannot traverse the estate. Segmentation is the control that lets you keep running a device that is safe clinically but weak digitally — it buys time that patching alone never will.

4. Treat patching as a clinical-safety change, jointly owned with the manufacturer. A patch on a regulated device is a change to a safety-critical product, and applying an unvalidated update can be as dangerous as leaving a hole open. Track manufacturer security advisories and MHRA field safety notices, validate updates against the manufacturer's guidance, and schedule them through clinical change control with fallback plans. Where a device cannot be patched, record the accepted residual risk and the compensating controls rather than pretending the gap does not exist.

5. Plan the whole lifecycle, including end of life, before you buy. A device's clinical life routinely outlasts the vendor's software support, creating years of unsupported, internet-shaped risk. At procurement, demand a software bill of materials, a stated support and patching commitment, secure-by-design features and a clear end-of-support date, and budget for replacement against that date, not the mechanical one (see Topic 6.3 — Procurement & Commercial). Decommissioning is a controlled step too: wipe patient data, revoke credentials and network access, and update the inventory, because a forgotten monitor in a store cupboard is still a live route in.

6. Get device data into the record safely and meaningfully. The value of connected devices is realized when readings flow into the clinical record accurately, with the right patient, units and timestamps, and with a clear provenance. Use recognized interoperability standards and integration middleware rather than bespoke point-to-point links, and validate that a device reading maps to the correct patient every time (see Topic 4.3 — Interoperability & Data Standards). A vital sign attributed to the wrong patient, or an ambiguous unit, is a clinical-safety hazard dressed up as an integration convenience.

7. Design remote monitoring and wearables for the home, not the ward. When care moves into the home, you inherit devices on domestic broadband, shared by families, charged intermittently and used by people who are unwell. Design for connectivity gaps, clear escalation when readings breach thresholds, digital inclusion, and explicit consent about what is collected and who acts on it (see Topic 1.9 — Digital Inclusion & Accessibility, and Topic 3.3 — Patient & Citizen-Facing Digital Services). Be honest about clinical accountability: a stream of home readings that no one is resourced to watch is a false reassurance, not a service.

8. Rehearse the loss of your devices, and report faults upward. Assume a class of devices will one day be unavailable — through ransomware, a recall, or a network fault — and rehearse the clinical fallback so staff are not improvising during an incident (see Topic 3.9 — Business Continuity & Disaster Recovery). In parallel, feed device faults, near-misses and adverse events into MHRA post-market surveillance through the Yellow Card scheme, because your reports are how systemic device flaws get caught before they harm someone else.

Questions to discuss with your team#

1. Who actually owns the connected device fleet across its whole life — and where are the gaps between IT, clinical engineering and cyber-security today? This matters because unowned devices are the ones that go unpatched, unmonitored and unmapped until an incident forces the question. In most organizations clinical engineering owns the asset record, IT owns the network, security owns the threat, and no one owns the device as a connected, regulated, patient-facing whole. Debate where the seams are: who decides a device can join the network, who validates a patch, who signs off decommissioning, and who is accountable when a device is both a safety-critical instrument and a vulnerable computer. Consider whether your governance forum has real decision rights and budget, or is a talking shop that escalates everything and resolves nothing. A good, honest answer names the accountable owner for each lifecycle stage, admits where today the answer is "nobody", and commits to closing specific seams rather than restating that collaboration is important.

2. How much of our connected estate can we actually see, and how confident are we in that number? You cannot segment, patch or retire devices you have not counted, yet most organizations discover during an incident that their inventory understates reality by a wide margin — shadow devices, vendor-installed kit, forgotten equipment in store rooms, and home devices no one catalogued. Discuss how your inventory is built and reconciled: is it a static spreadsheet, or is it continuously matched against what network discovery sees on the wire? Probe the honesty of your team's confidence — a precise-looking count with no reconciliation process is more dangerous than an admitted "we don't fully know", because it breeds false assurance. Consider the hardest categories: building management systems, third-party managed equipment, and devices in patients' homes. A good answer states a realistic coverage figure, describes how discrepancies are found and closed, and treats the inventory as a safety-critical system with a named owner rather than a compliance artefact.

3. What happens clinically when a class of these devices is unavailable, unsafe or compromised — and have we ever rehearsed it? Connected devices fail as a class, not one at a time: a ransomware event, a firmware bug, a recall or a network outage can take out every pump or monitor of a type simultaneously. Discuss which device classes would cause the most harm if lost, what the manual or alternative clinical fallback is, and whether front-line staff actually know it or would be improvising under pressure. Surface the trade-off between availability and security: the pressure to keep a fragile device running clinically versus the risk of leaving a known hole open, and who is empowered to make that call. Consider whether you would even detect a compromised device behaving subtly wrong — a monitor reporting plausible but false readings is harder to catch than one that goes dark. A good answer identifies the highest-harm classes, confirms a rehearsed and resourced fallback exists for each, and is candid about the detection blind spots that remain.

4. Are we buying and budgeting for the software life of a device, or only its mechanical life? A scanner may have a fifteen-year clinical life while the operating system inside it loses security support after five, so a procurement decision made today quietly commits you to a decade of un-patchable risk unless someone plans for it. Discuss whether your procurement process treats a software bill of materials, a stated patching commitment, secure-by-design features and an explicit end-of-support date as contract terms, or as nice-to-haves that fall away under price pressure. Probe who holds the replacement budget and against which date it is set — the mechanical failure point, or the software end-of-support point that arrives years earlier. Consider the awkward cases already in the estate: devices bought before anyone asked these questions, now years past support, with no replacement funding in sight. Surface the tension between clinical teams who want the newest capability, finance who wants assets sweated for their full physical life, and security who see the growing liability. An honest answer connects the buying decision to the whole-life cost, names who owns the replacement budget, and admits where the estate already carries unfunded software-obsolescence risk.

5. For the devices moving into patients' homes, who is actually watching the readings — and have we designed for the people using them? Remote monitoring and wearables shift the device estate onto domestic broadband, shared with families, charged intermittently and operated by people who are unwell, so the ward assumptions about connectivity, control and support no longer hold. Discuss whether a named, resourced clinical team is accountable for acting on home readings, or whether data flows into a dashboard that no one is funded to watch — a false reassurance dressed up as a service. Surface the digital-inclusion tension: a home-monitoring programme can quietly exclude those without reliable broadband, a suitable device or the confidence to use one, widening the very inequalities it was meant to narrow (see Topic 1.9 — Digital Inclusion & Accessibility). Consider consent and clarity of accountability — patients and carers need to know what is collected, who sees it and what happens when a reading breaches a threshold. Weigh the pull to scale these programmes quickly against the duty to make them safe and equitable. A good answer confirms who watches and escalates, is candid about the inclusion risks, and treats home devices as a governed clinical service rather than a convenient data feed.

6. When a device reading reaches the clinical record, are we sure it is the right value, in the right units, for the right patient? The clinical value of a connected device is only realized when its data lands in the record accurately, yet each integration is also a fresh chance to attribute a vital sign to the wrong patient or to lose the units and provenance behind a number. Discuss whether device data flows through validated interoperability standards and integration middleware with explicit patient-matching checks, or through bespoke point-to-point links that no one fully understands (see Topic 4.3 — Interoperability & Data Standards). Probe the failure modes that look like convenience but are safety hazards: an ambiguous unit, a mis-timed reading, a value written to the previous patient still logged in at the bedside. Consider how you would even detect such an error, given that a plausible-but-wrong number is far more dangerous than an obvious gap. Surface the trade-off between the speed of connecting a new device and the assurance work that makes its data trustworthy. An honest answer describes how patient-matching and unit integrity are validated end to end, names who owns that assurance, and treats a mis-attributed reading as the clinical-safety incident it is rather than an integration nuisance.

In practice: a health & care example#

Meadowfield NHS Foundation Trust runs a mid-sized acute hospital and, increasingly, a virtual ward that monitors patients at home. After a peer trust suffered a ransomware incident that spread through unmanaged clinical devices, Meadowfield's board asks a simple question: how many connected devices do we have, and who owns them? The honest answer is that no one can say. Clinical engineering's database lists around 6,000 assets; the network team's passive discovery tool sees closer to 9,000 things behaving like devices. The gap is the problem.

The Trust stands up a joint medical-device security group chaired jointly by the Head of Clinical Engineering and the Chief Information Security Officer, with the Clinical Safety Officer attending. Their first deliverable is a reconciled inventory: they merge the two data sources, chase down the discrepancies, and find infusion pumps on the general network, a CT scanner running an operating system three versions past end of support, and a set of building-management controllers for the pharmacy fridges that IT had never catalogued. Each finding is logged with a clinical risk rating rather than a purely technical one.

They cannot replace the scanner this year, so they contain it: it moves into a tightly segmented zone that permits only the flows to its imaging archive and the vendor's support gateway, and the accepted residual risk is recorded and signed off through clinical governance. The pumps are enrolled in a managed patching cycle validated against the manufacturer's advisories and scheduled through change control. For the virtual ward, the group insists that home monitoring devices report into the record through validated integration middleware with patient-matching checks, and that a named clinical team is resourced to watch and escalate the readings — not a dashboard no one owns.

Six months later a vendor issues a field safety notice about a monitor firmware defect. Because the inventory is now accurate and reconciled, Meadowfield identifies every affected unit within an hour, applies the validated fix through change control, and reports its own related near-miss to the MHRA through the Yellow Card scheme. The work was unglamorous — an inventory, a forum, a segmentation project — but it turned an invisible, unowned risk into a managed one.

Sector lenses#

Startup#

A digital-health startup shipping a wearable or a home-monitoring device is on the manufacturer side of the regulatory line, and its ways of working must reflect that from day one. Build secure-by-design: signed firmware, an over-the-air update path, a software bill of materials, and a plan for patching devices already in the field — retrofitting security after a funding round is far harder. Understand that you carry post-market surveillance duties and MHRA obligations that do not scale down for a small team, and that a hospital customer will assess your security posture before letting your device near its network. Your competitive edge is not just the device but the credible, documented promise that you will support and secure it for its whole clinical life.

Small business#

An established small provider — a GP practice, a community pharmacy, a care home or a single-site clinic — operates a modest but real fleet of connected kit: BP monitors, ECG units, vaccine-fridge sensors, spirometers and the growing trickle of patient wearables, all on a network no dedicated IT team watches. The same MHRA, cyber-security and clinical-safety duties apply as they do to a large trust, but there is no clinical-engineering department and often no in-house IT at all, so start by simply knowing what you have: a short, honest inventory with make, firmware and support status beats an elaborate system you cannot maintain. Lean hard on your suppliers and managed-service partners — insist that maintenance contracts, patching responsibilities and end-of-support dates are written down, because you are relying on them for capability you cannot staff. Use the buying moment as your main control point, since replacing an obsolete device is often more realistic for you than hardening it in place. Keep the highest-harm items — a fridge holding cold-chain vaccines, a monitor a clinician trusts — off the flat office network where a compromise could reach everything, even if full segmentation is beyond you.

Enterprise#

A large NHS trust or hospital group manages thousands of devices from dozens of vendors across a sprawling, long-lived estate, and its challenge is coordination and scale. The realistic goal is a reconciled inventory, disciplined segmentation, and a joint governance forum that spans clinical engineering, IT and security with real authority — not perfect patching everywhere, which the vendor constraints make impossible. Embed device security into procurement so that support commitments, secure-by-design features and end-of-support dates are contract terms, and align the replacement budget to the software life, not the mechanical one (see Topic 4.0 — Technical Architecture, Cloud & Legacy). At this scale the biggest wins come from a small number of estate-wide controls done consistently, not heroics on individual devices.

Government#

A national or regional body — NHS England, a devolved health department, the MHRA — shapes the environment every operator works in. It sets device-security standards and procurement frameworks, runs national threat intelligence and alerting so a vulnerability found in one trust protects all, and regulates devices and their post-market surveillance. Its leverage is to make secure-by-design and lifecycle support the market default through standards and buying power, so individual trusts are not each negotiating security from a weak position. Government also carries the equity duty: ensuring home-monitoring and wearable programmes do not widen the digital divide, and that safety reporting flows up so systemic device flaws are caught nationally rather than rediscovered trust by trust (see Topic 9.1 — Working with Local & National Governments).

Common failure modes#

• The inventory that lies. A tidy spreadsheet last reconciled a year ago gives false confidence; the devices that harm you are the ones it never listed. Reconcile continuously against network discovery.
• Devices in the no-man's-land between teams. When IT says it's clinical engineering's kit and clinical engineering says it's IT's network, no one patches, segments or monitors it. Assign end-to-end ownership.
• Patching paralysis or patching recklessness. Both extremes harm patients — never updating leaves known holes open; applying unvalidated updates can break a safety-critical device. Route patches through joint clinical change control.
• Buying for the mechanical life, forgetting the software life. A fifteen-year scanner on a five-year-supported operating system becomes an un-patchable liability. Budget replacement against end of software support.
• Flat networks. Connected devices on the general network let a single compromise reach everything. Segment by default.
• Home monitoring with no one watching. A stream of wearable readings that no clinician is resourced to act on is a false reassurance and a governance risk, not a service.
• Decommissioning that isn't. A retired device still on the network with old credentials and patient data is a live attack route. Wipe, revoke, disconnect and update the inventory.

Maturity model#

Checklist#

• There is one authoritative device inventory, reconciled continuously against network discovery, with a named owner.
• A joint forum of IT, clinical engineering and cyber-security has real decision rights over onboarding, patching, segmentation and decommissioning.
• Connected devices sit in segmented network zones that permit only the flows they genuinely need.
• Patches and firmware updates for regulated devices are validated and routed through clinical change control, with fallback plans.
• Procurement contracts require a software bill of materials, secure-by-design features, and a stated end-of-support date.
• Replacement budgets are aligned to the software support life, not just the mechanical life.
• Decommissioning wipes patient data, revokes credentials and network access, and updates the inventory.
• Device data reaches the clinical record through validated integration with patient-matching and unit checks.
• Home-monitoring and wearable programmes have resourced clinical escalation, explicit consent, and inclusion by design.
• Clinical fallback for the loss of each high-harm device class is documented and rehearsed.
• Device faults, near-misses and adverse events are reported to the MHRA through the Yellow Card scheme.

Key sources#

• MHRA — Medical devices: guidance for manufacturers, operators and users, and the Yellow Card reporting scheme for adverse incidents and field safety notices.
• NHS England / NHS Digital — Data Security and Protection Toolkit and network/device security guidance for health and care organisations.
• NCSC (National Cyber Security Centre) — guidance on operational technology, network segmentation and securing connected devices.
• NHS England / IEC standards — clinical engineering and medical device management good practice (including IEC 80001 for risk management of IT-networks incorporating medical devices).
• NICE — Evidence Standards Framework for Digital Health Technologies and guidance on remote monitoring and wearables.
• Institute of Physics and Engineering in Medicine (IPEM) — professional guidance for clinical and biomedical engineering.

References#

1. Medical device — Wikipedia — https://en.wikipedia.org/wiki/Medical_device
2. Internet of things — Wikipedia — https://en.wikipedia.org/wiki/Internet_of_things
3. Clinical engineering — Wikipedia — https://en.wikipedia.org/wiki/Clinical_engineering
4. Biomedical engineering — Wikipedia — https://en.wikipedia.org/wiki/Biomedical_engineering
5. Operational technology — Wikipedia — https://en.wikipedia.org/wiki/Operational_technology
6. Network segmentation — Wikipedia — https://en.wikipedia.org/wiki/Network_segmentation
7. Attack surface — Wikipedia — https://en.wikipedia.org/wiki/Attack_surface
8. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
9. Postmarketing surveillance — Wikipedia — https://en.wikipedia.org/wiki/Postmarketing_surveillance
10. Wearable technology — Wikipedia — https://en.wikipedia.org/wiki/Wearable_technology
11. Remote patient monitoring — Wikipedia — https://en.wikipedia.org/wiki/Remote_patient_monitoring
12. Infusion pump — Wikipedia — https://en.wikipedia.org/wiki/Infusion_pump
13. Medicines and Healthcare products Regulatory Agency — Medical devices: guidance and Yellow Card reporting — GOV.UK — https://www.gov.uk/government/organisations/medicines-and-healthcare-products-regulatory-agency
14. National Cyber Security Centre — Guidance on operational technology and device security — NCSC — https://www.ncsc.gov.uk/
15. NHS England — Data Security and Protection Toolkit — NHS England — https://www.dsptoolkit.nhs.uk/
16. National Institute for Health and Care Excellence — Evidence Standards Framework for Digital Health Technologies — NICE — https://www.nice.org.uk/about/what-we-do/our-programmes/evidence-standards-framework-for-digital-health-technologies
17. Institute of Physics and Engineering in Medicine — Clinical and biomedical engineering guidance — IPEM — https://www.ipem.ac.uk/