# Design of an Open Remote Electrocardiogram (ECG) Service
## 6 Conclusions and Future Work  
Commercial and research products exist that provide remote ECG services, but the design we present in this paper is distinguished for two tightly related reasons. One is that we focus on _low cost_: overall, the retail price of the hardware we used to realize a development-oriented prototype is around 50$. A design that aims at a limited deployment of production-oriented devices can significantly cut such cost, so that the realization of a remote ECG service becomes affordable also for small communities, which are those that may take the most from this kind of service. A low entry cost may also attract the interest of small enterprises. The other reason is that we privilege _shareability_ respect to other technical aspects. For this, all parts of the design are open-source so that there are no royalties to pay to put them into production. Since the interfaces among components are also open, it is possible to produce or improve just one of them and  
Figure 10: Test setup to measure the processing pipeline in isolation, independent from Wide Area Network (WAN) performance. integrate it into an existing deployment; this opens a market to all those that share the same open design. The name of this is interoperability, and, in the past, it has been a key for the take-off of many technologies. Focusing on the performance of our prototype, there are markets that might be addressed today with this service. Looking at the REHEARSE-AF study, we see that the results we obtain fit a similar scenario: _home health-care_ in a residential area of a developed country. The ubiquitous diffusion of home WiFi routers with wide bandwidth availability eliminates the Internet bottleneck. Local administrations might even provide a local server, or use a local hosting service. Unlike the devices used in REHEARSE-AF, those of our prototype are open and low-cost, which makes a difference. Alone, the home health-care market addresses millions of potential users. It is much more extended than others that are technically more challenging, like those that follow. The road rescue service described in the introduction has a much more limited market, but an impact that may be relevant as a life-saving technology. Our solution can't help in similar scenarios since it depends on _WiFi coverage_ and experimental results prove that tethering is ineffective. However, there are viable trade-offs for that: for instance, we might cope with bad connectivity by introducing a buffer in the server and accepting a significant latency. A slightly more complex design that we have not investigated. Assuming sufficient outdoor connectivity, we may consider ambulatory monitoring, like during exercise. We have shown that, as is, the device is sufficiently lightweight and robust to be considered portable, and its autonomy may reach a day of continuous utilization, like that of a Holter monitor. Even more challenging is the extension of the service to lands covered by constrained wireless networks, like Long Range (LoRa)-based networks [27]. It is the case of least developed countries, where the presence of a remote ECG would be precious to give qualified medical assistance to isolated communities. In such cases, we cannot expect a large market to open, so that experience gained with wealthier environments is precious to enable the design of devices that address challenging use cases with an affordable price. In the short term, further results extending current work concern with its implementation, and consist of trading off simplicity against other parameters. The _cost_ can be improved using non-Arduino compatible devices, at the same time obtaining a more compact and wearable device. _Power consumption_ can be reduced avoiding redundant components and making use of power-saving features. Better data compression improves _performance in communication_. Our point is that when services have a social impact--as in the case of healthcare--it is relevant that their design addresses low-cost, openness and standardization (OpLoC).