IoMT evolution runs across three layers at once: hardware, communication and intelligence. Connected medical devices are gaining sensing, local computation and power efficiency in silicon, connecting through resilient low-power protocols and clinical data standards, and interpreting physiological data at the edge. An IoMT system succeeds when those three layers are engineered together rather than in isolation.
If you are specifying a connected medical device now, decide three things before the architecture is drawn: which sensing and which inference must run on the device with no connection at all; which transport carries the data off the device and which clinical standard, HL7 or FHIR, the receiving system expects; and where the security decisions for the silicon, the link and the firmware update path are recorded. Those three answers are what a supplier’s proposal should be read against.
Connected healthcare is poised for a transformational leap. The Internet of Medical Things (IoMT) now signals a new era, one defined by advanced intelligent systems that reliably elevate care in any setting, whether a hospital, home, ambulance, or remote clinic.
Healthcare technology is shifting from centralised monitoring toward distributed, real-time, patient-centric systems. This transformation is happening across three interconnected layers: hardware intelligence, communication frameworks, and adaptive intelligence.
Only organisations that truly master these layers and their integration will lead and redefine the connected healthcare landscape of tomorrow.
A hospital has trained staff beside the device; a home, an ambulance and a remote clinic may not. IEC 60601-1-11 defines the home healthcare environment as “the dwelling place in which a patient lives; other places where patients are present both indoors and outdoors, excluding professional healthcare facility environments where operators with medical training are continually available when patients are present”, and a connected medical device designed to that definition has to sense, decide and communicate with nobody trained in the room.
What hardware intelligence do IoMT devices need?
IoMT devices need hardware intelligence in three forms: multiple sensing modalities such as ECG, SpO2, temperature, pressure, motion and bioimpedance in one compact platform; microcontrollers able to compute in real time so a medical device analyses data locally without continuous cloud connectivity; and power efficiency for days, weeks or years on limited energy, with security anchored in the silicon.
The foundation of IoMT begins with hardware. Advances in semiconductor technology, sensing systems, and ultra-low-power electronics are enabling devices that are smaller, smarter, and more efficient than ever before.
Modern medical device hardware design now integrates multiple sensing modalities into compact platforms. Devices that once required bulky instrumentation can now operate within wearable patches or handheld monitors.
Today’s IoMT devices commonly integrate:
- ECG sensing
- SpO₂ monitoring
- Temperature measurement
- Pressure sensing
- Motion tracking
- Bioimpedance measurement
These sensing capabilities are combined with microcontrollers capable of real-time computation.
Edge processors such as ARM Cortex-M (a family of efficient microcontrollers) and emerging RISC-V architectures (an open-standard processor type) allow devices to analyse data locally without relying on continuous cloud connectivity. This capability improves reliability and reduces latency in clinical decision-making.
In hardware firmware development, ensuring harmony between sensing hardware and embedded processing is crucial for efficient signal acquisition, processing, and power management.
Another important shift in medical device hardware design is power efficiency. IoMT devices must often operate for days, weeks, or even years on limited energy sources.
Energy optimisation strategies now include:
- Ultra-low-power microcontrollers
- Dynamic voltage scaling
- Duty-cycled sensing
- Energy harvesting techniques
- Optimised battery management systems
For implantable and wearable devices, energy efficiency directly determines usability and longevity.
Security is also becoming a hardware-level requirement. Hardware roots of trust (chip-based security anchors), secure key storage (protected memory for cryptographic keys), and encrypted communication engines (hardware components that protect transmitted data) are now essential components of IoMT architecture. Security cannot be layered on top later; it must begin at the silicon level.
Arm Cortex-M and RISC-V are not the same kind of thing, and a buyer choosing between them should know which is which. Arm lists its Cortex-M processors as “Low-power CPUs for microcontrollers used in embedded systems & real-time control”, a vendor describing its own core family; RISC-V International is “the global non-profit home of the open standard RISC-V Instruction Set Architecture (ISA)”, so RISC-V is an open instruction set architecture rather than one vendor’s part, and a RISC-V core is an implementation of that specification. The question worth asking is not which is better but what power budget and what inference workload the medical device has to meet, because those two answers choose the core; the check to run is whether a proposal states both before it names a processor.
Which communication frameworks does connected healthcare depend on?
Connected healthcare depends on communication frameworks of two kinds: resilient low-power networking, such as Bluetooth Mesh carried over Bluetooth LE and MQTT-SN from battery-powered sensors, and clinical interoperability standards, HL7 and FHIR, that turn device data into records a hospital system can use. Bandwidth is rarely the constraint; protocol design, latency and security architecture are.
While hardware enables sensing and processing, communication enables coordination across healthcare systems. If you want true interoperability and clinical continuity, especially across hospital, home, and mobile care environments, a resilient communication architecture is not optional; it is essential.
Traditional communication protocols were designed for static networks and predictable workflows. IoMT requires different, flexible, resilient communication models capable of supporting dynamic care environments.
Technologies such as BLE Mesh allow medical devices to communicate directly with one another, enabling local coordination without cloud dependency. This approach improves resilience in environments where network connectivity may be unreliable.
Low-power messaging protocols like MQTT-SN (a lightweight protocol for sensor networks) enable efficient data transmission from battery-powered medical devices. Private 5G networks (dedicated cellular networks within hospital campuses) are also emerging as a powerful tool for hospital infrastructure, offering ultra-low latency and high reliability.
But connectivity alone is never enough. Interoperability is the real test, and IoMT success demands it.
Healthcare systems depend on standards such as HL7 (Health Level 7, a clinical messaging standard) and FHIR (Fast Healthcare Interoperability Resources, a modern data format) to integrate device data with electronic health records (EHRs). These standards ensure that device-generated data becomes clinically actionable.
Within IoT product development services, the communication strategy determines whether your system scales for real-world impact. Even the best hardware and software are wasted if your protocol design creates data bottlenecks.
In IoMT, bandwidth is rarely the primary constraint. Protocol design, latency management, and security architecture are far more critical.
Bluetooth Mesh, also written BLE Mesh, is a networking layer carried over Bluetooth LE bearers, and the Bluetooth SIG describes it as suited to systems where hundreds or thousands of devices communicate with one another. Bluetooth Mesh, MQTT-SN, HL7 and FHIR each have a publisher that says in its own words what the technology is for, and if you need device data to land in a hospital system those words are what a proposal should be checked against.
Bluetooth Mesh, MQTT-SN, HL7 and FHIR: the primary source for each and what its publisher says
| Technology or standards body | Primary source | What the publisher says |
|---|---|---|
| Bluetooth Mesh (BLE Mesh) | Bluetooth SIG mesh page | Hundreds or thousands of devices communicating with one another |
| MQTT-SN v1.2 | OASIS MQTT specifications | Publish/subscribe for wireless sensor networks beyond TCP/IP |
| HL7 International | HL7 about page | ANSI-accredited standards body for healthcare data |
| FHIR R5 | FHIR specification | A standard for exchanging healthcare information electronically |
A connected medical device needs one of each kind: a transport that suits the device and a clinical data standard that suits the receiving system. MQTT-SN is “a publish/subscribe messaging protocol for wireless sensor networks (WSN), with the aim of extending the MQTT protocol beyond the reach of TCP/IP infrastructure”, which is why it suits sensor networks that do not carry TCP/IP to the device, while FHIR “is a standard for exchanging healthcare information electronically”, published by HL7 International, which is what the hospital system on the far end expects. Read a proposal for the sentence that names the transport and the sentence that names the clinical data standard; if only one of the two is there, the proposal has not yet described a connected medical device.
What does adaptive intelligence add to IoMT systems?
Adaptive intelligence adds local interpretation to IoMT systems: edge AI models running on the medical device detect early signs of conditions such as cardiac arrhythmias or respiratory irregularities and raise an alert without cloud connectivity. It also filters raw physiological data into clinically relevant events rather than continuous streams, and it makes firmware architecture the deciding factor.
The third layer of IoMT evolution is intelligence. Connected devices generate massive volumes of physiological data. Without intelligent interpretation, this data has limited clinical value.
Adaptive intelligence empowers IoMT systems to provide proactive, life-saving interventions. This is how organisations move beyond passive monitoring and truly elevate patient care.
Edge AI models are increasingly capable of detecting early signs of medical conditions, such as:
- Cardiac arrhythmias
- Respiratory irregularities
- Infection indicators
- Mobility decline
- Neurological abnormalities
By running inference locally, IoMT devices can provide immediate alerts without relying on cloud connectivity.
This shift has significant implications for firmware development services. Firmware must now support real-time signal processing, AI inference pipelines, and secure communication simultaneously.
Efficient firmware architecture ensures:
- Deterministic execution
- Low-latency processing
- Optimised memory usage
- Predictable power consumption
- Reliable device behaviour
In hardware firmware development, firmware bridges sensing hardware and clinical intelligence.
Another critical advantage of edge intelligence is reducing clinician fatigue. Instead of generating continuous streams of raw data, intelligent devices can filter and prioritise clinically relevant events.
This reduces false alarms and improves trust in connected healthcare systems. Predictive analytics is also transforming care delivery. By identifying patterns early, IoMT systems enable preventive interventions rather than reactive treatment. This represents one of the most significant shifts in modern healthcare technology.
A model that runs on a medical device is part of that device’s software, and IEC 62304 “defines the life cycle requirements for medical device software”, so the model sits inside that life cycle: the version of the model that shipped and the evidence behind its detection performance are records a buyer can ask to see. Where a medical device raises its alerts through an alarm system, a second standard applies: IEC 60601-1-8 “specifies basic safety and essential performance requirements and tests for alarm systems in medical electrical equipment and medical electrical systems”, and a buyer can ask which of its requirements and tests the device is being designed to meet. The check to run is to ask where the model version is recorded and who can reproduce its detection figure from what is recorded. Our post on on-device arrhythmia detection works one such model through the constraints of a small microcontroller, and our post on how embedded systems are changing healthcare takes the wider view.
How is security handled across all IoMT layers?
Security across all layers of an IoMT system is a requirement rather than a feature added to one: hardware roots of trust and secure key storage in the silicon, encrypted communication and hardware-backed authentication on the link, and secure firmware update mechanisms in the software. For a connected medical device, a cybersecurity risk is a clinical risk.
Security is a cross-cutting requirement across hardware, communication, and intelligence layers.
Connected medical devices must protect:
- Patient data
- Device integrity
- Communication channels
- Firmware updates
- Authentication mechanisms
Secure firmware update mechanisms, encrypted communication protocols, and hardware-backed authentication are now essential for IoMT deployments.
In IoT product development services, security must be a system of capability, not just a feature. Cybersecurity risks in healthcare are not just technical risks; they are clinical risks.
Patient data, device integrity, communication channels, firmware updates and authentication mechanisms are each protected by a decision made in a different place, and a buyer can ask where each decision is written down.
Five things a connected medical device must protect, where each is decided and the check to run
| What must be protected | Where the decision is made | Check to run |
|---|---|---|
| Patient data | Silicon and data handling: key storage, encryption | Which keys, stored where, generated by whom |
| Device integrity | Silicon and boot firmware: root of trust | What refuses to boot, and what proves it |
| Communication channels | Link layer and protocol choice | Which protocol, which cipher, which version |
| Firmware updates | Update path in firmware | What checks an image before it is applied |
| Authentication mechanisms | Hardware-backed credentials | Where the credential lives, how it is revoked |
There is a standard for the process behind those decisions: IEC 81001-5-1 “defines the LIFE CYCLE requirements for development and maintenance of HEALTH SOFTWARE needed to support conformance to IEC 62443-4-1” and establishes “a common framework for secure HEALTH SOFTWARE LIFE CYCLE PROCESSES”. It is a life cycle and process standard, so what it asks for is evidence of secure development activities rather than a particular chip or cipher. On a Pinetics programme the security decision is recorded at a gate: the architecture gate has published exit criteria, and one of them is a signed cybersecurity architecture decision. The check to run on your own programme is to ask which document records the security decision, who signed it and on what date; our page on how device software evidence is produced inside a customer’s quality system sets out the rest.
Why must hardware, communication and intelligence be engineered together?
Hardware, communication and intelligence must be engineered together because each layer only works through the others: hardware enables sensing, communication enables coordination and intelligence enables decision-making. IoMT systems designed as one discipline are resilient, scalable and clinically valuable in real healthcare environments and not only in laboratory conditions; those designed in isolation are fragile and hard to maintain.
The most important insight into IoMT evolution is that these three layers cannot be engineered independently. Hardware enables sensing. Communication enables coordination. Intelligence enables decision-making.
When these layers are designed together, IoMT systems become resilient, scalable, and clinically valuable. When they are designed in isolation, systems become fragile and difficult to maintain.
Modern medical device hardware design, firmware development services, and hardware firmware development must operate as a unified engineering discipline. This integrated approach ensures devices are reliable not only in laboratory conditions but also in real-world healthcare environments.
The convergence of hardware, communication and intelligence has a regulatory shape as well as an engineering one, and a buyer can ask for it by name: which standards is this connected medical device being scoped against? Pinetics scopes work against the medical device standards that actually gate a launch, among them IEC 60601-1 for basic safety and essential performance of medical electrical equipment, IEC 62304 for the software life cycle, ISO 14971 for risk management and ISO 13485 for the quality management system. Pinetics holds no certification of its own, is deliberately not ISO 13485 certified and works inside its customers’ quality systems, so work scoped against those four documents is recorded inside the customer’s quality system rather than under any certificate of ours. A proposal that names none of them has not yet said what the device will be measured against.
The future of connected healthcare will not be defined by the number of devices deployed, but by how intelligently those devices operate together. IoMT systems must accurately sense, securely communicate, and meaningfully interpret data across every layer of the architecture.
At Pinetics, we help healthcare innovators build connected medical systems through advanced medical device hardware design, firmware development services, hardware firmware development and IoT product development services. By engineering hardware, communication frameworks and embedded intelligence as a unified ecosystem, we enable medical devices that are secure, scalable and ready for the future of connected care: the sensing and the inference that must run on the device written down first, the transport and the clinical data standard chosen together, and the security decision signed at the architecture gate. That work rests on 100,000+ engineering hours and a leadership team with 20+ years of experience, and it runs inside the customer’s quality system rather than under a certification of our own. If your device must work in a home, an ambulance or a remote clinic, the conversation starts with those three decisions.
The next healthcare revolution will belong to organisations that design IoMT systems holistically from silicon to software to clinical insight.
Navin Goyal, Co-Founder and Global CEO, Pinetics. BE Electronics, Dr D. Y. Patil College of Engineering; MBA (Finance and Marketing), Indira School of Management Studies. 20+ years of experience. LinkedIn
