# Design of an Open Remote Electrocardiogram (ECG) Service
## 3 An Open Service for Remote ECG
### Patient's Side Sensor Device  
Unlike the doctor's device, the sensor on the patient's side has specific features. Although today's smartphones have sensors covering a wide range of applications, they are not yet capable of acquiring heartbeat signals with sufficient precision. Thus, we need to design an ad hoc ECG sensor that receives, amplifies and processes the bio-signal. In this section, we analyze several options for each of its key aspects: ECG acquisition, usability, power consumption, link level connectivity, data transport, and finally hardware design. Regarding _ECG acquisition_, the processing of bio-signals is an evolving technology, for which sophisticated methods are available. However, the constrained computational capabilities of low-cost devices limit the complexity of a viable solution. Thus, we envision the use of one among the commercial boards that acquire and filter the electrical signals produced by the muscular activity. The _usability_ of the device takes into account that its operation should be simple, without compromising ECG quality, and electrodes placement shouldn't be critical: wearable electrodes like wristbands are better than chest leads. Usability also indicates wireless connectivity, discussed below, as preferable. Since the device needs to be portable, we need to limit _power consumption_ to ensure sufficient autonomy when operated on a battery. To quantify a target power consumption, we consider that the energy density of Lithium-Metal batteries is 0.5 kW h kg\({}^{-1}\) and introduce a weight limit of 0.1 kg. Under such assumptions, battery capacity cannot exceed 50 W h. To obtain an autonomy of 10 hours, which fits use cases like a day-long monitoring or a remote nursery, we have that power consumption must be lower than 5 W. Such a limit excludes using a powerful Single Board Computer (SBC) with a power consumption close to such a theoretical limit, like the popular Raspberry PI [21], and addresses constrained devices like Micro-Controller Units (MCU), characterized by a power consumption lower than 1 W.  
Another relevant requirement for the ECG sensor is that its use should extend beyond hospitals and private homes so that wireless technologies are preferable to link the sensor to the Internet. Here, we discuss the pros and cons of three widely diffused _link level_ wireless technologies: Bluetooth, WiFi, and Mobile Wireless, which includes various generations after GPRS. Bluetooth is a low-cost, well-established technology for short-range wireless communication. Its introduction in our design would require the presence of a nearby component acting as a gateway between Bluetooth and the Internet, which introduces additional cost and design complexity. WiFi is another stable technology, with typical coverage that is slightly larger than Bluetooth. WiFi to Internet gateways (or APs) are inexpensive devices very diffused in our towns: houses, shops, and public places frequently provide a private or public AP. A smartphone can be used as a WiFi AP, extending the range of usability of the ECG sensor to any place reached by mobile wireless networks, provided that a tethering smartphone is at hand. Our third alternative wireless technology is Mobile Wireless, which incurs slightly higher costs compared with WiFi (assuming the AP is already in place). They are due to a more expensive interface and to the need to subscribe with a mobile phone service provider. The operation range depends on the availability of a Point Of Presence (POP). In a word, connectivity compensates subscription costs. After our analysis, we conclude that the link between the sensor and the Internet could be implemented either with WiFi or with Mobile Wireless, with mixed pros and cons. Regarding _data transport_, having introduced a web server as an interface on the doctor's side suggests using the same technology for patient's, with the same benefits for security and stability.