Wearable medical devices offer a huge advantage in monitoring and early detection of symptoms. In order for them to fulfill their potential, they need a number of features to make them scalable, interoperable and more.

The skyrocketing costs of healthcare have given rise to a rapidly growing segment: Mobile Health, or mHealth. mHealth technology is helping establish a continuum of care that encompasses genetic and dietary predisposition, risk factors, asymptomatic and active diseases. This enables new levels of efficiency in healthcare management by improving affordability, accessibility and quality of care with the final result of curbing costs for healthcare companies, providers and patients. Microtechnology companies ease this process by defining products, strategies and road maps that improve the capability of healthcare to address specific needs and personalization of services. Within the same context, platforms that ease the development of devices and that standardize their approval process are clearly needed.

Such a platform, a general remote health monitoring system, would integrate a variety of components including a suite of sensors, a patient-wearable device for data processing and connectivity or body gateway, a host communication device along with a system of service and data repository devices (Figure 1). The sensors suite is a set of on and off-body sensors that monitor vital signs and physiological parameters such as electrocardiogram (ECG), heart rate, body activity, blood pressure and weight to name a few. The body gateway device (BGW) is a wearable processing and connectivity unit that collects data from the sensors, performs initial processing, stores the data and prepares data for transmission over a network to the remote application server. The BGW device is responsible for sending alarms and messages to the user as well as for managing the overall interface between the user and the service provider.

mHealth system architecture

A host communication device is needed to form the bridge between the BGW device and the remote server. It is used by the BGW device to establish a network connection when data transmission is required. The network link is used by the host device to transfer data to and from the patient location to the remote application server. The device can host a user graphic interface for patient consultation purposes.

Finally, the server repository and services architecture represents the hardware and software remote processing unit that is responsible for establishing secure connections and authenticating the user, for collecting the data received by the BGW as well as for providing the functions of querying, monitoring and issuing alerts or messages to the user. These servers represent the aggregation center for service provision.

Device Platform Features

Framing a Wearable Device Platform
Wearable devices are one of the pillars of an mHealth system. Their architecture integrates and shares a number of distinctive features that need to comply with defined rules and procedures through the design, verification and validation phases of the project.
The most obvious feature of a wearable device platform is wearability, which relates to size, weight and ergonomic characteristics of devices. Microtechnologies and packaging solutions don’t pose severe limits to device miniaturization and form factors. Today devices can weigh less than 0.5 oz and body size is easily contained within 1.5”x 1.5”. This overcomes most of the ergonomic limitations presented by human body morphology. Examples are “wrist watch” devices for vital signs in fitness and wellness and “Electronic Patches” for monitoring chronic diseases.
Solutions must be capable of following the course of the disease through on-thefly reconfiguration and without the need of on-site installation and service support.

Electrical block diagram of BGW (a) and the fusion of signals from the sensor suite to the gateway (b).

From the device manufacturers’ perspective, this requirement for scalability translates into a platform whose hardware can be incrementally upgraded and diversified to address different disease conditions. Finally, scalability will allow easy FDA approval procedures thanks to a pre-approved platform development process that avoids the need for repetitive and expensive tests and trials to validate each device.
There must be a common medical nomenclature through all devices. This means interoperability among devices that translates into easy access for patients to interchangeable solutions and into more costcompetitive solutions. Continua Health Alliance (CHA) represents an ecosystem of more than 240 companies with the mission to develop interoperability guidelines to harmonize mHealth communication processes and data flow from patient to service provider.
Along with interoperability must come connectivity. In mHealth this has two concurrent and interrelated characteristics: one is supporting technical requirements including data rate capacity, response/wake up time and reliable communication. The second is supporting functional requirements for optimal power management and longest battery life according to the type of service and specific application requirements. By adopting CHA-approved radio communication stacks (i.e., BT, BTLE, Zigbee) or those under approval (i.e., AZT, NFC, WIFI), it is possible to connect with a vast family of devices from different vendors and to get access to the large mHealth devices market.
Since no two patients are alike, there must be an ability to provide solutions that can address each patient’s physiological diversity within the same disease conditions by leveraging the adjustment of parameters and control functions. Such personalization can be supported through technologies that allow on-the-fly adjustment of medical protocol parameters depending on drug efficacy and patient adherence. Personalization is enabled by technologies that allow the downloading and reprogramming of memories or through device disposability. Health care systems must provide a safe level of security, including patient privacy, through robust data encryption while avoiding temporary or local decryption of data that can affect the safety of the information chain. Security may also be handled by adopting hardware solutions such as crypto card or dedicated smart cards that authenticate devices and patients.
Also important is the proper implementation of disposability. Single-use solutions are more practical and user-friendly than non-disposable ones. The decision to go disposable is a trade-off process that involves costs, efficacy and effective patient advantage. Currently there is a clear trend toward a mixed solution that keeps the valuable and more expensive part (i.e., data memory, intelligence, connectivity parts) reusable and keeps the less expensive part or any part that needs to be frequently removed for physiological reasons (i.e., patches) disposable.
Given the battery-operated nature of a wearable platform, energy efficiency falls within a general trend for microtechnology to provide highly efficient solutions with almost zero power consumption. This may be achieved through different converging strategies, which includes reduction of the operating voltage, adoption of lower leakage technologies, proper partitioning of active/standby time, optimization of data handling and transmission.
Finally, of course, there is regulatory compliance. Wearable medical devices must meet a number of rules and stan-dards: EN 60601 dictates conditions for safety (electrical, electromagnetic, mechanical hazards); EN 62304 for software life cycle; EN 980 for labeling; EN 60529 for IP protection; ISO 14971 for risk management; ISO 10993 for biological evaluation; EC38 for ambulatory ECG performances and EC57 for algorithm testing. Having a flexible, scalable platform that conforms to all these standards is a demanding requirement but it adds the benefit of having both the platform and its hardware and software components compliant so that devices generated by that platform can easily go through the approval processes and procedures requested for FDA or EC.
Platform for mHealth Devices

mHealth devices already on the market monitor vital signs as well as one or more physiological parameters addressing single (active or preventive) disease conditions. Most common target diseases are heart related such as atrial fibrillation, arrhythmia, or sleep apnea while parameters under observation are a combination of electrocardiogram (ECG), heart rate, body activity, blood pressure, temperature, respiration rate, SPO2 and/or weight.
These devices can be either single or multiuse, and batteries may last from aminimumofonedaytouptotwoor more weeks depending on the monitoring conditions. Most of these devices are not interoperable, nor scalable, with limited flexibility for personalization and in some cases do not support wireless connectivity. Accompanying each of the devices is a list of procedures, sometimes repeated for each device, which must be implemented to achieve full compliance with the application’s specifications and patient safety.
Therefore, considering an architecture that could facilitate integration of the entire process would add remarkable value to a device’s project and validation process. This means a set of hardware and software components of a scalable architecture prevalidated according to regulated procedures and requirements must be defined.
In this way, platform implementation becomes a recommended passage to generate devices with the extended capability to address multiple disease conditions through a diversified sensor suite and by both signal fusion and parameter fusion processing capability to improve efficacy and ultimately the outcome of monitoring diseases.
At the same time, compatibility among different solutions that may need to be adopted and implemented to address the early stage of a disease or for preventive purposes is preserved. All of the above is reflected through an alignment to the features presented in the device platform section above.
The main areas of activity that need to be considered while developing a platform include packaging, the framework of the design and modularity. The packaging issue has two parts. One is for items that are for single use such as the patch itself, to allow easy replacement of parts that come in contact with the skin. The second part—the module—can be reused to keep memory of the evolving health conditions and allow further data post processing. The patch and module need to comply with robustness, humidity and wetness requirements according to standards.
The design framework needs to be based on a layered architecture. The software part with all its sub-layers including connectivity stack, RTOS, interoperability layers, medical protocols, data aggregation library, etc., must be 510(k) pre-approved and compliant with healthcare device safety and design robustness standards. The hardware part must be composed of components and boards compliant to the required quality and safety rules. And the solutions must be modular in order to scale both software and hardware components according to application needs.
From a hardware perspective, this means having access to a scalable family of microcontrollers compatible in terms of firmware and pinout and that can be tailored around application requirements to meet an optimal power budget. A sensor suite to extend its capability would include accelerometer, temperature sense, microphone, impedance measurement, ECG, IR and photodiode and/or weight scale. This same scalability applies to the software cells library modularity.
An example of such a platform is exemplified by a first BGW device targeting CHF applications as shown in Figure 2. The platform is intended to support singularly, or in combination, disease conditions such as Metabolic Syndrome (Obesity) diagnostics, Obstructive Sleep Apnea (OSA), Atrial Fibrillation (AF) and Biofluidic Analytes. Table 1 lists the complete features of the platform.
Drivers to mHealth Devices Platform Evolution
Electronic patches used for long-term monitoring of multiple parameters will bring important benefits, including early warnings based on detection of rare but significant anomalous events, verification of long-term effects of therapy and medication, and statistical analysis for medical research. Further analysis of the application’s requirements will reduce the amount of data transmitted and increase the amount of data pre-processing in the device.
Power management granularity is another key avenue of exploration driving the development of lower power libraries to reduce the energy per bit figures. We can envisage an order of magnitude lower power consumption, which would open the door to devices powered by energy harvesting technologies rather than batteries. The introduction of System on Chip (SoC) solutions will help contain costs and reduce both size and weight of BGW devices.
Healthcare consumerism will lower costs, providing access to a larger number of people. In the prevention and prediction domain, there is a clear need for monitoring physiological parameters to detect the presence of risk factors and of asymptomatic diseases. Most such devices will not need an FDA approval and possibly will not be constrained by traditional reimbursement practices. Diabetes management, where the ratio between population at risk and population suffering from diabetes is 10 to 1, and sleep apnea, are examples of the potential of healthcare consumerism. More patches will become disposable when the cost becomes low enough and the increasing volumes will accelerate this process.


Geneva, Switzerland