Wearable Medical Devices: High Level System Design ...
Post on 21-Oct-2021
1 Views
Preview:
Transcript
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*,&)#*,#".(
'#$.#2"�#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>�,'#/&06?$*(&#./#-0/&#-/*$*-06#42,-$*.,06*$'8#
!! !4#1*/&6&""#$/0,"(*""*.,#*"#2"&);#1%0$#/&-&*>*,+#)&>*-&#*"#,&&)&)8#
!! 9%0$#*"#$%&#)0$0#/0$"&)#.,#$%&#/&:2*/&)#*,4./(0$*.,#0,)#4/&:2&,-'#.4#$/0,"(*""*.,8#
!! !"#$%&/�#/&+260$./'#4/0(&1./@#A"&$#.4#"$0,)0/)"B#$%0$#,&&)"#$.#3&#$0@&,#*,$.#0--.2,$8#
!! C/&#$%&/�,'#"&-2/*$'#0"5&-$"#$%0$#,&&)#$.#3&#-.,"*)&/&)#*,#$%&#)&"*+,8#
!! C/&#$%&/�,'#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,-,$#$,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.
top related