1

Wearable Medical Devices: High Level System

Design Considerations and Trade-offs

Esther Rodriguez-Villegas, Saam Iranmanesh and Syed Anas Imtiaz

I. INTRODUCTION

Wearable devices have seen tremendous growth over the last 10 years. This has been made

possible with the ever-shrinking electronics, reduction in costs as well as the rise in mobile

computing making it possible to share significant computational workload. Recent estimates

show an annual growth of 17% in wearable devices in the year 2017 with over 300 million

devices being sold. It is also projected that over 500 million devices will be sold by the year

2021 [1]. While these figures show some staggering growth and potential for wearable devices,

a detailed look at the numbers reveal that the application areas where wearable devices have

been a success are quite limited. Most of these devices which are considered wearable, take

the form of smartwatches, fitness trackers, body worn cameras and headphones. It should be

emphasized that the mentioned numbers are for devices that are made for consumers and used

mostly for entertainment, wellness and general health purposes. The benefits provided by most

of these health-related wearable devices are insufficient for medical usage mainly because of

low quality data and insufficient accuracy in classification tasks.

While wearables for consumer use will continue to grow, it is important to keep in mind

the distinction between consumer and medical-grade devices. In the sphere of medical devices,

wearables for monitoring, diagnosing and real-time management of illnesses is still at a very

early stage. One of the main reasons for this slow growth, as well as adoption, is the design

of such devices, which is inherently very challenging. In this paper, we will first look at the

need for wearable devices to improve healthcare in order to understand and define a set of

E. Rodriguez-Villegas, S. Iranmanesh and S. A. Imtiaz are with the Wearable Technologies

Lab, Electrical and Electronic Engineering Department, Imperial College London, United Kingdom.

Email: (e.rodriguez,s.ranmanesh10,anas.imtiaz,@imperial.ac.uk).

2

requirements for the design of such devices. Subsequently, based on these requirements, we will

look at the challenges that exist in the development of wearable medical devices particularly

from the perspective of their system and circuit level implementations.

II. LONG-TERM PATIENT MONITORING USING WEARABLE DEVICES

It has long been established that long-term monitoring of certain biosignals can significantly

help isolate health-related issues, improve patient outcomes and lead to early diagnosis in many

different health problems, illnesses and disorders. These include diabetes, epilepsy, sleep apnoea,

atrial fibrillation, REM behaviour disorder and many other neurological, respiratory and cardiac

problems.

For example, in the case of diabetes, continuous glucose monitoring [2] can be used to monitor

blood sugar levels and alert the patient instantly when these levels are too high or too low so

that corrective action may be taken without any delay. In case of epilepsy, patients are often

admitted to hospitals for monitoring of their brain signals (EEG) to capture epileptic events which

are otherwise difficult to record [3]. Having continuous long-term monitoring at home greatly

improves the likelihood of capturing these signals, and hence helps to provide the right kind of

medication. In even more advanced cases, automatic real-time seizure detection methods [4] in

wearable devices may be used to perform closed-loop brain stimulation for seizure suppression.

Sleep monitoring is yet another area where long-term monitoring brings many advantages.

For disorders like insomnia, narcolepsy and REM behaviour disorder, recording and analyzing

data over multiple nights of sleep provides great insights into sleeping patterns. This helps

medical professionals to bring in a lot more contextual information to improve the diagnosis.

Similarly, brain monitoring over long periods of time has the potential to have an impact on

mental health disorders - an area which desperately needs more understanding and improvement

of care provisions. In addition to these, looking after the health of the growing elderly population,

particularly in Western countries, is an urgent matter that requires novel methods of real-time

continuous monitoring at home. It is also with long-term monitoring of patients at home that

pharmaceutical research can benefit from big data analytics.

In most cases, the conventional way of long-term monitoring involves intermittent clinical

admissions at frequent intervals. This is quite inconvenient for patients because it completely

inhibits them and takes them out of their normal day to day lives. In addition, hospital admissions

are very expensive and not very cost effective. As an example, if we consider the case of

3

neurological sleep disorders, patients are generally admitted to sleep clinics for one or two

nights to record, amongst others, their brain waves, muscle activity and eye movement in a test

known as polysomnography (PSG). A technology that enables long-term monitoring at home

would make it much easier to gather more data, hence provide more information to the doctors

and save hospital admissions cost. In the case of narcolepsy, where daytime sleep is assessed,

it is even more inconvenient to carry on these tests where patients have to come in for testing

during the day, 3 to 5 times in a week. Apart from the inherent limitations, the other problem

with conventional methods in medicine is that they are reactive and hence monitoring starts only

in response to a more serious concern. To meet the demands of these healthcare challenges, it

is clear that long-term patient monitoring is fast becoming an integral requirement of the overall

patient care. However, together with the growing population and rise in chronic diseases, hospital

admissions for monitoring purposes is a huge bottleneck in the way of providing accessible

healthcare. Hence, the current model of providing care is unsustainable for the future and hence

requires a significant change.

This is where wearable devices in healthcare have the potential of huge disruptive impact. If

we could design medical devices that patients could take with them to their homes and easily

use them as part of their daily lives then we would be able to provide long-term monitoring

of patients at a significantly reduced cost. But, while the idea of a future in medicine full of

wearable devices sounds attractive, it does come with a lot of potential new challenges that need

to be addressed early on in order to make them a success. One of the key issues is that long-

term monitoring using wearables generates huge amounts of data. Analyzing this data manually

requires time and effort and hence adds to the overall cost. As an example, analyzing and scoring

one night of sleep monitoring data takes up to four hours [5]. Similarly, parsing through a month

of EEG data looking for seizure events is a very tiring, expensive and error-prone task. Hence,

we need to take advantage of the advances in machine learning methods to sift useful data from

these long recordings. This can be integrated in the overall system in a number of ways, but the

end result needs to be a wearable device that is not only a passive data collector, but something

that can sense and process signals in order to provide feedback, in some cases, in real-time.

The overwhelming trend over the last three decades has been the shrinking size of electronic

devices. Patient care at hospitals has naturally benefitted from this trend as a number of devices

are now portable enough to allow patient mobility during their stay at hospitals. A Holter monitor

is perhaps the most well-known example of a battery-operated portable medical device that is

4

used to monitor cardiac activity continuously, usually for 24-48 hours. A pulse oximeter is also

a portable medical device although its suitability for continuous monitoring is questionable due

to artefacts and its use is limited mostly at hospitals for vital signs monitoring [6]. Portable and

wireless EEG recorders are also beginning to be used where a storage unit is attached to the

patient’s body using a belt and allows them to move freely during the recording sessions [7].

III. GENERAL REQUIREMENTS FOR WEARABLE MEDICAL DEVICES

Although there is no formal definition of a wearable medical device, this can be considered as

something that can be comfortably worn by the user over long periods of time to continuously

sense a certain signal. Hence, while the aforementioned devices are portable, they are not truly

wearable since they cannot be used easily by patients themselves - and are not even designed

for that purpose. In fact, the current portable devices in use at hospitals are doctor-centric i.e.

they are designed mainly to be used by doctors to monitor patients. For long-term at-home

monitoring, the challenge is to create robust and reliable devices that patients will want to use

and hence requires a patient-centric approach.

As a result, the most significant requirements of a wearable medical device, apart from

functionality, is that it centres around human factors. These includes system reliability, small

form factor, ease of use, safety, clinical efficacy, light weight and a long battery life requiring

infrequent recharge cycles. All of these requirements may not be needed and the exact ones will

depend on the specific medical condition for which the device is being developed. Further, some

of these requirements are generally needed for consumer wearable devices as well, but in those

cases consumers are willingly using the device and making a conscious purchase and therefore

willing to sacrifice on some of the mentioned factors. The needs of the patient population,

on the other hand, are completely different from the normal consumer population and hence

their attitude towards these devices is also different. First, they are more likely to be diverse

in age groups and also in level of education. Second, since the wearable medical device would

be prescribed by medical experts, the patients would be using these devices without making

a voluntary decision and may therefore not be using them willingly. Thus, it is important that

these devices for long-term use integrate seamlessly into patient lifestyle and are easy to use for

all kinds of patients in order to ensure a high rate of compliance. If the devices cannot be used

for longer periods due to non-compliance (resulting from poor design), the purpose of creating

them in the first place is defeated.

5

Wearable medical devices that are intended to be used continuously over long periods of

time are likely to generate large amounts of data. Hence, there is a requirement for this data

to be stored on the device requiring some kind of flash memory. For example, in the case of

EEG monitoring, seven days of continuous recording with 4 channels can generate 3.4 GB of

data when sampled at 1 kHz using an ADC with 12-bit resolution. This, in turn, would require

powering up the memory blocks in the circuit, adding to the overall power consumption. An

alternative is to transmit data wirelessly to a nearby receiver; however the power requirements

for data transmission will need to be taken into account. Having said that, wireless transmission

also helps to make the system easier to use and can be an attractive option from the usabilitiy

point of view. It also helps to add important functionality of real-time feedback to allow timely

interventions. While factors such as power consumption and user convenience are very important,

in most cases, the decision of whether to store data locally or transmit wirelessly will mainly be

dictated by the context and application in which the wearable medical device is to be used. In a

device that is designed to capture data to be analyzed for long term trends, flash storage would be

a more reliable method. In a device where real-time feedback is important, e.g. real-time seizure

detection, the use of wireless transmission is a design requirement. However, regardless of the

way in which the end data is handled, the large amounts of data may also require compression

to ease some of these requirements.

In cases of real-time applications, another key requirement is an algorithm, implemented on

hardware, that can process the data and provide actionable results. The algorithms can either be

implemented on the wearable medical device itself or on a nearby receiver to handle a higher

processing bulkload. Fig. 1 shows the two common architectures that can be employed for

wireless real-time or near real-time devices. In the first case, the wearable device is only required

to sense and transmit data (perhaps after some form of compression) while the receiving device,

with fewer power and resources constraints, processes this data to extract useful information for

clinical use. In the second case, only the processed data is transmitted which is significantly

smaller in transmit payload resulting in significant power savings, thus improving the system

battery life. This strategy is known as data selection and is illustrated in Fig. 2. This requires

real-time processing of signals at the source of their acquisition. A low-complexity algorithm

implemented on hardware is thus required, that can also serve as a form of compression whereby

only clinically useful data is kept or transmitted, while the background activity is discarded.

Another important consideration is the myriad of regulatory requirements for medical de-

6

vices [8], [9]. These add a number of constraints for the designers particularly with regards to

the requirements for electromagnetic emissions and compatibility, heat dissipation, characteristics

of isolations, spacing in PCB tracks, mechanical characteristics, biocompatibility of materials,

testing, etc. Hence, it is important to take these into account early so that they are integrated

into the design process.

The requirements mentioned here are only a subset from a much larger pool and more can be

added based on the specific use case. However, what is quite clear is that these requirements are

very important and integral to the success of wearable medical devices and hence no compromises

can be made on them. Consequently, this brings about significant constraints for the designers

of such devices, making the development of a wearable medical device a significantly more

complex process than it would be for a consumer device. These restrictions are also going to

manifest in every part of the design process including circuits, interfaces, mechanical design,

signal processing and the system level design. Furthermore, in many cases the performance

and power requirements are so strict that they cannot be met using off the shelf electronic

components, and hence devices are increasingly being made with application specific integrated

circuits (ASICs) at their core.

IV. GENERAL DESIGN CONSIDERATIONS

From an electronics design perspective, the design of a wearable medical device consists of

development at three broad levels including top-level system design, signal processing algorithms

and hardware implementation. These three areas of design are tightly interwined and involve a

number of trade-offs to be made in order to meet the primary specification requirements. In order

to avoid expensive changes at a later stage, it is important that design engineers involved with

the creation of different parts of the system have a clear idea of these requirements. This section

examines some of the main questions that should be answered for each branch of the design

and demonstrates how design requirements in each domain result in a set of constraints for the

other. These will be looked by using the design of a wearable EEG device for sleep monitoring

as an example [10]. Although a specific device is used as an example, many wearable systems

will have very similar generic processing blocks but the top level specifications will result in

completely different implementations. Further, although this section is presented mainly from

a hardware and circuit design perspective, much of the discussion is equally valid for systems

made using off-the-shelf components.

7

A. System-level Design

The example device for sleep monitoring was to be designed to sense EEG signals, process

these in real-time, perform classification, and subsequently transmit the results wirelessly. Since it

is to be used during sleeping periods, user comfort, both physical and in terms of user experience,

was of paramount importance. To process the signals, the system contained a real-time algorithm

running on a custom chip. For wearable medical devices like this, such initial system-wide

specifications result in the first set of known design constraints. While some specifications form

part of the core requirement, others may have some level of flexibility. The designers who

are responsible for algorithm development and hardware design should be fully aware of these

specifications and should ask pertinent questions about the system design requirements.

This initial set of questions that should be asked are shown in Fig. 3. The answers to these

questions provide some useful direction both for the early feasibility and initial design at the

algorithmic and circuit levels. For example, based on the requirements of how the device is

going to be used, there may be size and limitations dictating the use of a particular size and

chemistry battery. This would in turn set an upper limit on the available power budget for the

entire system. Also, if there are any clinical requirements these must be used to chart out the

specs for each block in the system. For example, in the case of EEG-based sleep monitoring,

the American Academy of Sleep Medicine recommends EEG signal sampled at 500 Hz with a

resolution of 12 bits [11]. As a result the ADC needs to be designed such that it conforms to

these guidelines. Also, in our example [10], the useful part in the monitoring is the end processed

result which was the classification into one of the five sleep stages. Consequently, the memory or

transmission requirements applied only to this end result. Also, in the design used as example,

it was decided to use smartphones as receiving devices purely because this helped to integrate

easier with contemporary lifestyle. This meant that the the choice of wireless communication

was already fixed as Bluetooth Low Energy [12] from an early stage and hence the data rate

limitations that comes with BLE also had to be considered. Other, more advanced, system level

implications of data and system security, and privacy should also be taken into account at this

stage.

B. Signal Processing and Algorithms

After taking all the requirements on board, as the next step in the design lifecycle, an algorithm

might need to be developed to carry out relevant feature extraction and classification tasks to

8

be subsequently implemented on hardware. These two design streams are heavily interlinked to

obtain an efficient system. Therefore, if the objective is known to be an ASIC implementation

then the algorithm must be developed keeping the implementation requirements in mind. At

this point, algorithm developers should be asked a series of questions, as shown in Fig. 4,

to understand these requirements. The answers to these questions are important for algorithm

developers to be aware of the kind of computational techniques they can use reasonably within

the constraints that exist as a result of its future hardware implementation.

In the case of the example of the sleep monitoring system, the answers to some of these

questions were instrumental in the development of the algorithm for automatic sleep stage

classification [13], shown in Fig. 5. The system-level requirements of a small form factor, use

of a hearing aid battery and the desire to have a battery life of over 10 days meant the power

budget was limited and hence a limited number of computations could be performed. This led to

the decision of trying to use simpler classification methods since the computations and memory

requirements for the use of classifiers like neural networks were deemed to be on the higher side.

The chip designers also communicated their preference of using 16-bit fixed point arithmetic

in the design which the algorithm developers would need to take into account. The algorithm

in [13] works by extracting spectral features which are subsequently classified. Hence, having

an FFT processor was a core requirement for the algorithm. Because of this the numerical errors

accumulated over the entire FFT processing pipeline as a result of fixed-point implementation

had to be considered. Not considering these errors could have resulted in numerical inaccuracies

and hence degradation in algorithmic performance. Of course, things are not set in stone at this

point and the algorithm developers can report back saying which of the constraints definitely

need to be relaxed in order for them to come up with a workable solution.

The state-machine of the algorithm can also be developed in a way to make for an efficient

hardware implementation. This can be seen in the sleep staging algorithm as well, which was

designed using a set of decision trees. It could very well have been one large decision tree but

instead it was developed in a way to have several small contextual decision trees, inherently re-

ducing the number of comparisons needed for classification. This was possible by understanding

the clinical context of the problem which was being tackled. For sleep classification, knowledge

was used of the fact that there are five stages of sleep, and the likelihood of a certain stage is

higher at different times of sleep and may depend on the previous sleep stage. This contextual

information was used within the flow of the algorithm, in such a way that when the likelihood

9

of a certain sleep stage was higher, an attempt to classify that stage would be made first. This

way only features that were needed for this classification were first extracted and the rest were

only computed on an on-demand basis, thus saving significant number of comparisons and

computations. This algorithmic optimization was needed strictly for hardware implementation

and makes no difference when running the algorithm on a numerical software like Matlab. But

on a resource-constrained wearable system this saves hundreds of clock cycles of computations

and thus improves its power efficiency.

Another important factor that is worth to consider at the time of algorithm development is the

artefacts present in the acquired signal. The knowledge about the sources of these artefacts is

very important in order to develop hardware-efficient methods for their removal. If the signal is

heavily corrupted then artefact removal stages will be part of the algorithm to clean the signal

prior to further processing, adding to the computational burden. The overall processing burden

and algorithmic complexity should be estimated at this stage and discussed with the circuit

designers.

At a higher level, something that is generally overlooked by algorithm developers is how those

algorithms are going to be tested, since there are very specific, intended use dependent, regulatory

requirements, on the amount and the type of data that must be used to validate algorithms that

deal with physiological signals in medical devices. Also, depending on the type of device, and

both its essential performance and intended use [8], performance metrics for testing of the

algorithm need to be determined at the very beginning of the development process. A practical

consequence of this is that in many cases Figures of Merits (FOM) presented in academic papers

to evaluate the merits of a particular algorithmic approach are misleading if those algorithms

were to be used as part of an actual system; and the end result could be as bad as ending up

with a system that is turned down by regulatory bodies.

C. Hardware Implementation

The specifications needed for the design of integrated circuits are a direct consequence of

system and signal processing requirements and should be relatively clear at this stage. However,

the circuit designers should consider asking more questions and, where possible, provide some

kind of early feedback if changes are required in the alogrithm to improve the hardware imple-

mentation. Some of the key areas where the circuit designers should be focused, when given

an algorithm for hardware implementation, are shown in the checklist in Fig. 6. This list covers

10

some questions to get details of the signal processing methods as well as those about the system

level requirements that are relevant for circuit design.

Getting answers to these questions is important for chip designers so that they can start

planning for their assigned circuits and systems on chip and be able to ascertain what parts of

the algorithms should be implemented as analogue circuits and what parts are suitable for a

digital implementation. A block diagram of the mixed-signal hardware implementation chosen

for the previously mentioned sleep monitoring system is shown in Fig. 7. As seen in Fig. 7,

an analog instrumentation amplifier was used to amplify the weak input EEG signal (IA). The

outputs of the IA were digitized using a 12-bit ADC. The sleep staging algorithm, which was

chosen to be implemented in the digital domain, subsequently processes the digitized EEG signal

and identifies the different stages of sleep. A transmitter/memory block then transmits/stores the

outputs of this algorithm, with a significantly reduced data rate in comparison to the case of

transmitting/storing raw EEG signals.

The design of the front end circuitry is dependent on the sensing mechanism used in the

wearable medical system. In the case of sensing EEG, ECG and EMG bio-potentials, an IA is

typically used in the front end to boost these low-amplitude and low-bandwidth signals. The

input impedance of the IA must be kept sufficiently large (typically above 100 MΩ) to avoid

signal attenuation caused by the voltage division formed by the electrode-skin, and IA input,

impedances. A high Common Mode Rejection Ratio (CMRR), typically above 100 dB, is also

desirable to ensure that the effect of common aggressors, namely power supply noise (50/60

Hz) and motion artefacts, are minimized. The IA must tolerate a certain amount of DC offset

voltages (±300 mV in the case of EEG monitoring [14]), which are produced as a result of

the electrochemical effects at the electrode-skin interface. These voltages can otherwise result in

signal distortion, or even saturation, at the IA output. Low noise operation is also required by

the IA so as to not corrupt the weak input signal, whereas the linear range of the amplifier must

be set to accommodate the entire expected signal range. Large sized input transistors can be

used to minimize the intrinsic flicker (1/f ) noise and offset of the core amplifier. However, the

increased gate area results in added parasitics leading to a reduction in the IA input impedance.

Ultimately, the tradeoffs required to meet mentioned specifications are highly dependent on the

IA architecture and the type of circuitry used to compensate for the amplifier non-idealities,

and these must be selected with the end power budget in mind. For example, the chopping

technique [15], is utilized extensively to improve the IA noise performance. Using this technique,

11

the input signal is upmodulated prior to amplification and demodulated back to the original band

at the IA output. Flicker noise and offsets introduced by the core amplifier are only up–modulated

at the amplifier output using this technique, and thereby separated from the amplified signal.

However, the use of this technique can lead to a degraded input impedance, requiring the addition

of impedance boosting circuitry [16].

With regards to analogue to digital conversion, low-power successive-approximation-register

(SAR) ADCs are widely used among bio-potential sensing front-ends due to their suitability for

low sampling rate (up to hundreds of kS/s) and medium resolution (12 bits) applications [17].

On the system-level, the actual sampling rate of the ADC is dependent on the positioning of this

block with respect to the individual IAs. The ADC is typically placed after the IA. Alternatively,

the outputs of multiple IAs can been multiplexed to a single ADC operating at a higher sampling

rate, optimizing the overall system area.

Careful design is also required in the algorithm hardware implementation so that the signals fed

to the algorithm are not corrupted by in-band noise and non-idealities resulting from individual

analog circuits in the signal processing chain. It may prove useful to simulate the algorithm

performance with different amounts of added artificially generated noise, during the algorithm

design process, to identify the maximum noise level that can be tolerated by the system, without

incurring an intolerable loss in performance. Doing this will also avoid having to overdesign

circuit blocks to avoid risks of degradation. An illustration of this can be found in [18], where it

was found that by doing this on an interictal spike detection algorithm, the performance results

obtained from this simulation significantly relaxed the dynamic range requirements for the analog

circuits implemented in the hardware implementation of the algorithm from 72 dB down to 40

dB.

In the case of digital circuits, understanding the accuracy requirements for different datapath

components allows the chip designers to select the appropriate number representation system and

also use the correct architecture for those components. The difference between different types of

multipliers, for example, can have an impact on the power requirements but also on the overall

accuracy of the system. There will be trade-offs at this stage and hence it is also important to

take into account the acceptable tolerance for the overall classification. Within the algorithmic

pipeline, there will be different parts of the algorithm with higher accuracy requirements than

others. This should be studied to determine those parts where the initial constraints can be

relaxed thereby saving computation power. For example, some parts of the system may need

12

numbers represented in 16 bits while in other parts numbers with 4 or 8 bit representations

may be acceptable. Other datapath optimisations should also be looked at if they fall within

the acceptable accuracy range. For example, if there is an operation that requires multiplication

by 1.95, it should be checked whether multiplication by 2 is a suitable alternative within the

accuracy requirements. If it is, the resulting change requires only a simple bitshift operation

instead of a significantly more complex multiplication operation. This translates to a simple

wire in hardware compared to a set of datapath components needed for multiplication.

In any case, what is an intolerable loss in performance will ultimately depend on the device

intended use. In the case of the medical devices, the latter is not just the manufacturers/designers

choice, but it is determined by legal constraints in different territories [8], existing predicates [9]

and accepted set of standards [19].

Apart from these, it should also be possible to ascertain the memory requirements as well as

get an initial estimate on power consumption, clocking requirements, achievable classification

accuracy and latency. There may be more changes in approach when the design stage starts in

full flow; however the objective of carrying out this exercise should be to reveal the possible

tradeoffs and determine with high level of confidence how these can be used to reasonably

achieve the design specifications within the known constraints.

V. CONCLUSIONS

It is clear that the healthcare needs of the ever-aging population can not be met by the existing

healthcare models. This will only result in more and more people getting ill and either not

getting the treatment they need, or getting it unnecessarily late. Hence, a complete change in the

approach to healthcare is needed. This approach can take advantage of technological advances

to provide quick and accessible care to patients. Wearable medical devices have the potential

to disrupt the healthcare industry and provide this care by enabling long-term monitoring, data

collection and analysis, remote diagnosis and real-time detection of significant events. However,

the design of such devices is a very complex process and requires a patient-centric approach

to gain the confidence of not just clinicians, but also patients, in order to persuade them to

use such devices unsupervised and, in some cases, over long periods of time. For the designers

of wearable medical devices, this approach introduces a number of challenges and constraints

requiring to take into account many different, and in some cases, multidisciplinary aspects and

13

trade-offs. This paper has discussed some of these design aspects and trade-offs which are direct

consequence of patient usability requirements.

Wearable medical devices generate lots of data that require complex methods for signal analysis

and classification. The use of machine learning techniques such as artificial neural networks and

support vector machines together with hundreds of features in different domains is especially

helpful to gain more insights into this data. In many cases, wearable medical devices are required

to carry out real-time processing and classification of signals. To achieve this, there is a growing

trend to move towards edge processing rather than waiting for signals to be processed on more

powerful devices. Circuit designers are playing a key role on trying to bring intelligence into

embedded devices using novel algorithmic and processing techniques, such as creating dedicated

hardware for machine learning on the edge devices [20], [21]. For medical devices specifically,

it is also important to take advantage of other sources of potential optimizations stemming from

the different use-cases. Going forward, this is a trend that will continue to grow and require more

innovation to develop low-power and highly optimized hardware for specific applications. This

type of hardware is integral for the design of wearable medical devices and circuit designers

have a huge role in making them a success.

VI. ACKNOWLEDGEMENTS

The research presented in this article has received funding in part from the European Research

Council under the European Communitys Horizon 2020 Programme (grant ERC 679417), and

the Engineering and Physical Sciences Research Council, UK (grant EP/P009794/1).

REFERENCES

[1] Gartner. (2017) Forecast: Wearable Electronic Devices, Worldwide, 2017. [Online]. Available: https://www.gartner.com/

newsroom/id/3790965.

[2] S. Vaddiraju, D. J. Burgess, I. Tomazos, F. C. Jain, and F. Papadimitrakopoulos, “Technologies for continuous glucose

monitoring: Current problems and future promises,” Journal of Diabetes Science and Technology, vol. 4, no. 6, pp. 1540–

1562, 2010.

[3] R. Meier, H. Dittrich, A. Schulze-Bonhage, and A. Aertsen, “Detecting epileptic seizures in long-term human eeg: a

new approach to automatic online and real-time detection and classification of polymorphic seizure patterns,” J Clin

Neurophysiol, vol. 25, no. 3, pp. 119–131, 2008.

[4] L. S. Vidyaratne and K. M. Iftekharuddin, “Real-time epileptic seizure detection using eeg,” IEEE Transactions on Neural

Systems and Rehabilitation Engineering, vol. 25, no. 11, pp. 2146–2156, 2017.

[5] M. Ronzhina, O. Janousek, J. Kolarova, M. Novakova, P. Honzik, and I. Provaznik, “Sleep scoring using artificial neural

networks,” Sleep Medicine Reviews, vol. 16, no. 3, pp. 251–63, 2012.

14

[6] E. D. Chan, M. M. Chan, and M. M. Chan, “Pulse oximetry: Understanding its basic principles facilitates appreciation of

its limitations,” Respiratory Medicine, vol. 107, no. 6, pp. 789–799, 2013.

[7] A. J. Casson, D. C. Yates, S. J. Smith, J. S. Duncan, and E. Rodriguez-Villegas, “Wearable electroencephalography,” IEEE

Eng. Med. Biol. Mag., vol. 29, no. 3, pp. 44–56, 2010.

[8] European Commission. (2018) Medical Device Direction. [Online]. Available: https://ec.europa.eu/growth/single-market/

european-standards/harmonised-standards/medical-devices en

[9] FDA. (2018) US Food and Drug Administration. [Online]. Available: https://www.fda.gov/

[10] S. A. Imtiaz, Z. Jiang, and E. Rodriguez-Villegas, “An ultralow power system on chip for automatic sleep staging,” IEEE

Journal of Solid-State Circuits, vol. 52, no. 3, pp. 822–833, 2017.

[11] C. Iber, S. Ancoli-Israel, A. Chesson, and S. Quan, The AASM manual for the scoring of sleep and associated events:

rules, terminology and technical specifications. Westchester, IL: American Academy of Sleep Medicine, 2007.

[12] Bluetooth Technology. (2018) Bluetooth Low Energy. [Online]. Available: https://www.bluetooth.com/

[13] S. Imtiaz and E. Rodriguez-Villegas, “Automatic sleep staging using state machine-controlled decision trees,” in IEEE

EMBS conference, Milan, August 2015.

[14] Particular requirements for the basic safety and essential performance of electroencephalographs. IEC 60601-2-26, 2015.

[15] E. A. V. C. C. Enz and F. Krummenacher, “A cmos chopper amplifier,” IEEE Journal of Solid-State Circuits, vol. 22,

no. 3, pp. 335–342, 1987.

[16] J. Yoo, L. Yan, D. El-Damak, M. A. B. Altaf, A. H. Shoeb, and A. P. Chandrakasan, “An 8-channel scalable eeg acquisition

soc with patient-specific seizure classification and recording processor,” IEEE Journal of Solid-State Circuits, vol. 48, no. 1,

pp. 214–228, 2013.

[17] N. Verma and A. P. Chandrakasan, “An ultra low energy 12-bit rate-resolution scalable sar adc for wireless sensor nodes,”

IEEE Journal of Solid-State Circuits, vol. 42, no. 6, pp. 1196–1205, 2007.

[18] S. Iranmanesh and E. Rodriguez-Villegas, “A 950 nw analog-based data reduction chip for wearable eeg systems in

epilepsy,” IEEE Journal of Solid-State Circuits, vol. 52, no. 9, pp. 2362–2373, 2017.

[19] Medical electrical equipment – Part 1-11: General requirements for basic safety and essential performance. IEC 60601-

1-1, 2015.

[20] V. Sze, “Designing hardware for machine learning: The important role played by circuit designers,” IEEE Solid-State

Circuits Magazine, vol. 9, no. 4, pp. 46–54, 2017.

[21] M. Verhelst and B. Moons, “Embedded deep neural network processing: Algorithmic and processor techniques bring deep

learning to iot and edge devices,” IEEE Solid-State Circuits Magazine, vol. 9, no. 4, pp. 55–65, 2017.

FIGURES 15

Analogue

Front End

Data

Transmission

Data

Reception

Signal

Processing

(a)

Analogue

Front End

Signal

Processing

Data

Transmission

Data

Reception

(b)

Fig. 1: Two system design approaches for a wireless wearable device: (a) with signal processing at the receiver

end; (b) with signal processing at the sensor node

FIGURES 16

Arb

ita

ry u

nit

s

Time / s

2 4 6 8 10 12 14 16 18 20

Channels

Detected events and recording windows

The actual recorded data

Fig. 2: An illustration of the principle operation of data selection. It shows interesting data sections marked with

dashed lines are detected and stored while the rest of the signal being discarded.

FIGURES 17

!

!

!! !"#$%&#"'"$&(#)&"*+,#-.,"$/0*,&)#*,#".(&#10'#$.#2"&#0#30$$&/'#.4#50/$*-260/#"*7&#./#-050-*$'8#

!! 9%0$#0/&#$%&#)&"*/&)#"*+,06#-%0/0-$&/*"$*-"#

!! 9%0$#/&".62$*.,#*"#/&:2*/&)#4./#"0(56*,+#$%&#"*+,068#

!! 9%0$#0/&#$%&#-6*,*-06#+2*)&6*,&"#1*$%#/&"5&-$#$.#"*+,06#0-:2*"*$*.,;#*4#0,';#4./#$%&#"5&-*4*-#(&)*-06#0556*-0$*.,8#

!! 9%0$#0/&#$%&#"5&-*4*-#-6*,*-066'#*(5./$0,$#.2$52$"#$%0$#,&&)#$.#3&#$/0,"(*$$&)#0,)<./#"$./&)8#

!! =.&"#$%&#"'"$&(#*,>.6>&#0,'#/&06?$*(&#./#-0/&#-/*$*-06#42,-$*.,06*$'8#

!! !4#1*/&6&""#$/0,"(*""*.,#*"#2"&);#1%0$#/&-&*>*,+#)&>*-&#*"#,&&)&)8#

!! 9%0$#*"#$%&#)0$0#/0$&#30"&)#.,#$%&#/&:2*/&)#*,4./(0$*.,#0,)#4/&:2&,-'#.4#$/0,"(*""*.,8#

!! !"#$%&/&#0#/&+260$./'#4/0(&1./@#A"&$#.4#"$0,)0/)"B#$%0$#,&&)"#$.#3&#$0@&,#*,$.#0--.2,$8#

!! C/&#$%&/&#0,'#"&-2/*$'#0"5&-$"#$%0$#,&&)#$.#3&#-.,"*)&/&)#*,#$%&#)&"*+,8#

!! C/&#$%&/&#0,'#5/*>0-'#-.,-&/,"#$%0$#,&&)#$.#3&#-.,"*)&/&)#*,#$%&#)&"*+,8#

#

#Fig. 3: Checklist for system-level design considerations to determine the requirements and feasibility of the system

design at the algorithmic and circuit levels.

FIGURES 18

!! !"#$%#&'%$"'%(')%&'*+,&'-'.$/%01%$"'%#230&,$"-4%

!! 5&'%$"'&'%#.)%60$'.$,#2%"#&78#&'%0&%#&9",$'9$+&#2%2,-,$#$,0./%$"#$%#11'9$%#230&,$"-%7':'206-'.$4%

!! ;#/'7%0.%60$'.$,#2%"#&78#&'%&'/$&,9$,0./<%#&'%$"'&'%#.)%06$,-,=#$,0./%$"#$%9#.%>'%9#&&,'7%0+$%#$%$",/%/$#3'4%

!! 5&'%$"'&'%2,-,$/%0.%/,3.#2%>#.78,7$"<%-'-0&)%&'*+,&'-'.$/%#.7%0$"'&%#&,$"-'$,9%&'/0+&9'/4%

!! !"#$%/$'6/%9#.%>'%$#('.%$0%'./+&'%$"'%#230&,$"-/%6'&10&-%$"'%/#-'%8"'.%,-62'-'.$'7%0.%"#&78#&'4%

!! 5&'%$"'&'%#.)%.0.?.'30$,#>2'%&'*+,&'-'.$/%10&%$"'%#230&,$"-%1&0-%$"'%/)/$'-?8,7'%/6'9,1,9#$,0./%$"#$%$"'%

9,&9+,$%7'/,3.'&/%.''7%$0%>'%#8#&'%014%

!! !"#$%#&'%$"'%/0+&9'/%01%/,3.#2%#&$'1#9$/4

!! !"#$%,/%$"'%-,.,-+-%#-0+.$%01%7#$#%&'*+,&'7%$0%:#2,7#$'%$"'%#230&,$"-%$0%3+#&#.$''%$"'%/$#$,/$,9#2%

/,3.,1,9#.9'%10&%$"'%/6'9,1,9%-'7,9#2%#662,9#$,0.4%

!! !"#$%6'&10&-#.9'%-'$&,9/%9#.%>'%+/'7%$0%7'-0./$&#$'%'11,9#9)4%

%

Fig. 4: Checklist for algorithmic-level design considerations to determine the computational constraints that exist

for algorithm development.

FIGURES 19

N2

vs

N3

N2

!"#$%&'&"

N2

vs

Others

N2

vs

REM

N2

vs

N1

N2

vs

Wake

()"*+$,-$&)"$."#$"/0*)$

,1$'210$!3$04$.0&

5-$!36$7',.&',.$

1&'&"$'.8$4"&94.

:11,;.$!3$,-$

'22$&"1&1$-',2

<"1&$-04$0&)"4$12""/$

1&';"1$'.8$"=,&$#)".$

8,--"4".&$1&';"$-09.8

Assign new

sleep stage

!"#$%&'(%&')%&'*&"+,&-./&"0$&

12$&,344$0$+1&51"6$5&74&58$$9:

Fig. 5: An overview of the automatic sleep staging algorithm presented in [13]. It shows how a segment of EEG

is classified using a set of contectual decision trees into one of the five sleep stages.

FIGURES 20

!! !"#$%&'%$"(%)*(+#,,%-).(+%/012($%3)+%$"(%&4$(2+#$(1%5&+50&$6%

!! !"#$%#+(%$"(%5"#+#5$(+&'$&5'%)3%$"(%#570&+(1%'&24#,6

!! !"#$%&'%$"(%/#41.&1$"%)3%$"(%'&24#,6%

!! 8$%."#$%89:%+('),0$&)4%&'%$"(%'&24#,%$)%/(%'#;-,(16%

!! <).%1)('%$"(%4)&'(%5)4$+&/0$&)4%)3%&41&*&10#,%5&+50&$'%#33(5$%$"(%'&24#,%&4$(2+&$=6%

!! !"#$%&'%$"(%&4-0$%'&24#,%+#42(%$"#$%;0'$%/(%#55);;)1#$(1%/=%$"(%&;-,(;(4$(1%5&+50&$'6%

!! >)+%(#5"%)3%$"(%1#$#-#$"%5);-)4(4$'?%."#$%&'%$"(%#55(-$#/,(%#550+#5=%&4%5);-0$#$&)46%

!! !"#$%&'%$"(%#55(-$#/,(%(++)+%&4%#550+#5=%3)+%)*(+#,,%5,#''&3&5#$&)46%

!! !"#$%&'%$"(%#55(-$#/,(%$&;(%+#42(%3)+%5,#''&3&5#$&)4%,#$(45=6%

!! @'%$"(+(%#4=%+('$+&5$&)4%)4%$"(%$(5"4),)2=%-+)5(''%0'(16%

!! 8+(%$"(+(%#4=%#+(#%+('$+&5$&)4'%)4%$"(%5"&-%1&;(4'&)4'6%

!! <).%.&,,%$"(%'='$(;%/(%$('$(16%A&B(B%#+(%$"(+(%#4=%+(70&+(;(4$'%1(+&*(1%3+);%+(20,#$)+=%5)4'$+#&4$'6%

!! @'%1('&24&42%#4%&4$(2+#$(1%5&+50&$%5)'$%(33(5$&*(%."(4%&4$(2+#$(1?%5)4'&1(+&42%$"(%(C-(5$(1%,(*(,%)3%

-+)105$&)4?%$"(%5,&4&5#,%4((1?%%#41%$"(%+(&;/0+'(;(4$%;)1(,'6%

%

%Fig. 6: Checklist for circuit-level design considerations for implementation of an algoritm on hardware. It covers

the details of the signal processing methods and the system level design requirements that are relevant for circuit

design.

FIGURES 21

IA CLASSIFIER

ENGINEFFT PROCESSOR FEATURE

CALCULATION

EEG

input

FEATURE EXTRACTION

SLEEP STAGING ALGORITHM HARDWARE

ANALOG DOMAIN DIGITAL DOMAIN DATA INTERFACE

CLASSIFICATION

ADCTRANSMITTER

/

MEMORY

Fig. 7: A block diagram of the example sleep monitoring system as implemented in [10]. It shows the different

circuit blocks in both analog and digital domain.