Internet of Medical Things (IoMT): Architecture, Connectivity and MDR in Practice

A modern medical device is rarely alone on a bench any more. A continuous glucose monitor talks to a phone in someone's pocket. Across a hospital floor, an infusion pump reports to the nursing station.

An implant streams data to a clinician who may be hundreds of miles away. This web of connected devices, sensors and software has a name: the Internet of Medical Things.

This raises a practical question:
Your product is one node in that web. Which parts of it does the regulator treat as a medical device?

This guide walks through the Internet of Medical Things from a builder's point of view. We cover what the term spans and how the architecture stacks up from sensor to clinician.

We look at the connectivity choices that lock in early, then at where the product meets EU MDR. By the end you should know which components of your connected product carry regulatory weight.

Table of Content

What the Internet of Medical Things Means

The Internet of Medical Things is the network of connected devices, sensors and software that collect health data with little human intervention. Then it moves that data over the internet for analysis and action, often far from the point of care.

It is the healthcare branch of the wider Internet of Things (IoT), with one important difference. The data is clinical, so the stakes around safety and accuracy are far higher.

What Counts as an IoMT Device

The category is broad. It spans body-worn wearables, in-home monitors, implantable sensors and the large connected equipment that fills a hospital ward. A smartwatch that records an ECG sits in the same family as a networked infusion pump or a remote patient monitoring platform, both patient monitoring systems in their own right.

What ties them together is connectivity with a clinical purpose. Each device senses something about a patient, then shares that reading with another system. That second system might be a phone, a gateway in a clinic or a cloud service that a care team logs into.

In practice, builders tend to group these IoMT technologies into a few families by where the device sits:

On-body IoMT: wearable technology that runs from consumer grade wearables such as fitness bands and activity trackers to medical grade wearables like ECG patches that monitor patients continuously.
In-home IoMT: smart devices and mobile devices, from personal emergency response systems to monitors that help people manage chronic conditions away from the clinic.
Implantable devices and even smart pills that sense from inside the body.
Connected medical devices on the ward, from infusion pumps to imaging systems and other hospital equipment.

Why It Matters Now

Two forces are pushing adoption across the healthcare industry. Ageing populations and chronic disease need continuous monitoring that stretched healthcare systems cannot staff in person, in hospitals and smaller medical settings alike.

Meanwhile, sensors have become small and cheap enough to make that monitoring practical. Indeed, analysts put the IoMT market well into the hundreds of billions of dollars by the late 2020s.

In practice, for a product team, the appeal is concrete:

Earlier intervention and better diagnoses from continuous, real-time patient data.
Fewer hospital readmissions and lower healthcare costs.
Remote patient care that reaches people at home while reducing costs.
Operational efficiency for healthcare providers and the healthcare facilities that monitor patients at scale.

Still, every one of those benefits depends on the device being trusted. Trust is where regulation and security come in.

-> In short: The Internet of Medical Things connects clinical sensors and devices over the internet. The promise is continuous, remote care. The price of entry is safety, accuracy and trust.

The IoMT Architecture, Layer by Layer

Most Internet of Medical Things systems follow a layered architecture. Data climbs from the body to the clinician through a stack of horizontal layers.

Meanwhile, security and management run across all of them. In practice, understanding the stack helps you see where a decision in one layer constrains every layer above it.

Perception, Network and Gateway

The perception layer is the sensing foundation. It captures vitals such as heart rate, blood oxygen, blood pressure, ECG and temperature, then turns them into a digital signal. Indeed, this sensor technology is tightly limited on power and size, which shapes everything that follows.

The network layer carries those readings over short-range links to a gateway. The gateway is the hinge of the whole system. In fact, it collects data from nearby devices and decides what travels onward, so a weak gateway design becomes a bottleneck for the entire product.

Edge, Cloud and Application

The edge layer runs compute close to the device. Filtering and pre-processing data at the edge cuts latency and bandwidth. That matters when an alert needs to fire in seconds rather than minutes.

Above the edge sit the cloud and application layers. The cloud stores data and runs the analytics and artificial intelligence models behind predictive healthcare. These AI systems turn raw signals into clinical predictions.

Then the application layer turns results into dashboards and alerts that healthcare professionals can act on. The closer you get to that top layer, the more your work depends on interoperability.

Security and Management Across the Stack

Two concerns run vertically through every horizontal layer. Security has to hold at the sensor, on the wire, at the gateway and in the cloud, because the weakest point defines the whole device. A strong cloud means little if the radio link leaks data.

Device management is the second. For instance, a fleet of thousands of devices needs provisioning, monitoring and a safe way to update firmware in the field. Teams that treat management as an afterthought struggle the moment the product leaves the lab.

-> In short: An IoMT product is a stack: sensing, network, gateway, edge, cloud and application, with security woven through every layer. A constraint low in the stack ripples all the way up.

Connectivity and Interoperability

Connectivity is where many IoMT projects quietly commit to decisions they cannot easily reverse. The protocol you pick shapes battery life, range and reliability. The data standard you pick decides whether your device ever fits into a hospital's existing systems.

Picking the Right Protocol

There is no single best radio among the communication technologies on offer. Bluetooth Low Energy suits body-worn wearables that need low power over a short range.

Wi-Fi handles richer in-facility data at a higher power cost. Cellular and 5G give devices internet connectivity out in the field, while Zigbee builds resilient meshes across a building.

The right choice falls out of three constraints: signal range, available power and required latency. Get those straight before the radio is chosen, because a late switch usually means new hardware.

Speaking the Hospital's Language

A reading is only useful once another system can read it. Most hospitals run connected medical devices from more than ten manufacturers across a mix of protocols, so a new device that ignores the standards is a new integration headache.

Two standards do most of the work. HL7 FHIR is the modern API for exchanging data with electronic health records.

IEEE 11073 defines the device nomenclature that those records map onto. Designing toward both early is far cheaper than retrofitting them after a failed pilot.

-> In short: Connectivity choices lock in early. Match the radio to range, power and latency, then design toward HL7 FHIR and IEEE 11073 so the device fits the systems it must join.

How IoMT Devices are Classified Under MDR

Here is the point most introductions skip. An Internet of Medical Things product is rarely one regulated thing.

Under EU MDR, the hardware, the firmware and the companion software can each carry their own classification weight. In practice, treating them as a single block is where teams lose months.

One Product, Several Regulated Parts

MDR Annex VIII sorts devices into Class I, IIa, IIb or III by risk. The physical device, with its sensors and measuring function, often lands in Class I or IIa. The firmware that drives it inherits the risk of the function it controls and follows the IEC 62304 software lifecycle.

The companion software is the part that surprises people. An app or cloud service that processes readings and informs a clinical decision is usually Software as a Medical Device in its own right. It needs its own classification, its own documentation and its own conformity route.

Rule 11 and the Software Jump

MDR Rule 11 governs software, with little mercy. Software that provides information used to take diagnostic or therapeutic decisions starts at Class IIa.

However, it climbs higher when the decision could lead to serious harm. Very little clinical software stays in Class I.

So a simple-looking Class I sensor can carry Class IIa software. That pulls in a notified body, clinical evaluation and a far larger technical file. Mapping each component to its class early is the single most useful thing you can do for the timeline.

What This Means for Your Conformity Route

Class matters because it sets who has to sign off. A Class I device can often self-certify, while Class IIa and above require a notified body to audit your quality system and review the technical file. Moreover, that review takes time and notified body capacity is tight.

The practical lesson is to design the conformity route alongside the architecture. Knowing a component is Class IIa early lets you budget for the audit, the clinical evidence and the documentation before they sit on the critical path.

-> In short: Split your IoMT product into hardware, firmware and software, then classify each on its own. Rule 11 routinely pushes the software to Class IIa or higher, which reshapes the whole programme.

Cybersecurity and Post-market Obligations

A connected device is an attack surface, so regulators treat it that way. By one widely cited study, more than half of the connected medical equipment in hospitals carries a known critical vulnerability, a direct patient safety risk. Under MDR, security is a lifecycle obligation that you cannot bolt on at the end.

Security by Design

MDR Annex I requires devices to be developed according to the state of the art, with IT security considered from the start. In practice that means threat modelling at the architecture stage, a software bill of materials from the build and vulnerability scanning during verification.

The supporting standards point the same way. IEC 81001-5-1 sets out security activities across the health software lifecycle.

In addition, MDCG 2019-16 gives the EU cybersecurity guidance manufacturers are expected to follow. Building to them from the start is far cheaper than bolting them on for an audit.

Data protection sits right alongside security in the EU. Connected health data is confidential medical data under the GDPR, so encryption in transit and at rest, strict access control and a lawful processing basis are expected from day one. As a result, many teams run an ISO 27001 information-security programme to evidence it for auditors and hospital buyers.

Security Does Not End at Launch

Clearance is the beginning of the security job rather than the end. Post-market surveillance under MDR includes monitoring for new vulnerabilities, issuing patches and notifying authorities within set timelines when something serious appears.

For an IoMT fleet, that obligation has teeth. You need a way to push updates safely to devices already in the field and a coordinated disclosure process for researchers who report flaws. Plan the update path while the architecture is still on the whiteboard.

-> In short: Security is a lifecycle duty under MDR, from threat modelling at design to patching in the field. Build to IEC 81001-5-1 and MDCG 2019-16, then plan secure updates before launch.

Building an IoMT Product: What Trips Teams up

The architecture and the regulation come together in the build, where a few patterns sink projects again and again. Most of them trace back to a decision made early without its full consequences in view.

The Common Failure Modes

The first is treating regulation as a final-stage task. Classification, risk management and security shape the architecture, so leaving them until the end means rebuilding what you have already shipped to a prototype.

The second is underestimating the software. Teams plan the hardware in detail, then discover the companion app is Class IIa Software as a Medical Device with its own heavy documentation. The third is leaving interoperability for later, only to fail the first hospital pilot on data exchange.

Designing for the Whole System

By contrast, the teams that ship treat the device, the firmware, the software and the regulatory path as one system from day one. They map components to MDR classes before committing to an architecture and they pick protocols and data standards against the environments the device must live in.

None of this slows a serious project down. It front-loads the hard questions while they are still cheap to answer, which is exactly when an experienced partner earns their place on the team.

What To Do:

Map your product into hardware, firmware and software, then classify each component under MDR before you commit to an architecture.
Choose your connectivity protocol and data standards against the real deployment environment and not the easiest demo.
Treat security and the field-update path as design inputs.

Where IoMT is Heading

The Internet of Medical Things is still moving fast. A few shifts are worth designing for now rather than retrofitting later:

Edge and on-device AI systems that score data locally, so alerts fire without a round trip to the cloud.
Wider 5G and low-power networks that give wearable devices reliable internet connectivity outside the hospital.
Tighter EU oversight, as the AI Act layers new duties onto MDR for any diagnostic model inside an IoMT product.
Steady growth in remote patient monitoring as payers reward care that keeps people out of hospital.

-> In short: IoMT is trending toward on-device intelligence, stronger connectivity and stricter EU oversight. Design for edge AI, resilient networks and the AI Act now, so the product ages well.

Closing Thoughts

The Internet of Medical Things rewards teams that think in systems. The architecture, the connectivity, the classification and the security work as one design problem seen from different angles, rather than separate work streams.

Decide early which components are regulated. Pick connectivity and standards that fit the real world your device will live in. Treat security as a property of the whole lifecycle.

Do all three. The technical file then becomes a record of good decisions rather than a scramble to justify late ones.

FAQs

What is the difference between IoMT and IoT in healthcare?

A1: IoT in healthcare is a loose term for any connected device used in a care setting. The Internet of Medical Things is the regulated subset where devices have a clinical purpose and fall under medical device rules such as EU MDR. A networked vending machine is IoT. A connected infusion pump is IoMT.

Q2: What are the layers of an IoMT architecture?

A2: A common model has five horizontal layers: perception or sensing, network, gateway, cloud analytics and application. Security, device management and the cloud platform run across all of them. Data climbs from the sensor on the patient up to the clinician's dashboard.

Q3: What MDR class does an IoMT device fall into?

A3: It depends on the component. The physical device often sits in Class I or IIa, while companion software that informs clinical decisions usually reaches Class IIa or higher under Rule 11. You classify each part of the product separately rather than the product as one block.

Q4: Which connectivity protocol is best for an IoMT device?

A4: There is no universal answer. Bluetooth Low Energy fits low-power wearables, Wi-Fi suits richer in-facility data and cellular or 5G reaches remote devices. Choose against range, power budget and latency, then design toward HL7 FHIR and IEEE 11073 so the data is usable once it arrives.

Q5: What does MDR require for IoMT cybersecurity?

A5: MDR requires security by design across the lifecycle, with threat modelling, a software bill of materials and vulnerability management. Post-market duties include monitoring for new threats, patching devices in the field and reporting serious issues to authorities within set timelines. IEC 81001-5-1 and MDCG 2019-16 set the expected approach, while the GDPR and an ISO 27001 programme cover the data-protection side.

Q6: Can an IoMT companion app qualify for DiGA reimbursement in Germany?

A6: Potentially, for the software component. Germany's DiGA pathway, under the DiGAV, reimburses lower-risk digital health applications that are CE-marked as Class I or IIa under MDR. So a connected device's companion app can pursue a DiGA listing when it meets the evidence, data-protection and interoperability requirements. Those requirements sit on top of the MDR classification rather than replacing it. For a German launch, a DiGA listing then opens a route to statutory reimbursement.