## 7 Conclusions and Future Work  
In this article, we have presented all the steps involved in the design, implementation and deployment of the SPIDEP platform and its RC variants based on the SOA and MSA architectural patterns; the platform is focused on remote telemonitoring of the elderly. Therefore, our purpose is to offer a replicable framework to support the early diagnosis of infectious diseases and their derivatives by using recent ICT developments through artificial intelligence algorithms (e.g., deep learning and machine learning-based inference systems), with the added value of reducing logistical costs for medical institutions. Therefore, it was necessary to evaluate which of the SPIDEP variants are best suited for our versatile high-performance concept, considering the strengths and weaknesses of each architecture and how they behave in a high demand scenario. As a result, we have analyzed and contrasted the performance of each variant vs. the metrics obtained from the various performance tests (i.e., response time, efficient use of infrastructure and network consumption), which found that MSA is a better performer in terms of the performance quality attribute (approximately 54.21%). In the same manner, when processing multiple requests for various services, the response time was lower compared to SOA (approximately 7.34%), but the bandwidth consumption in MSA was more significant than SOA (approximately 73.80%). Based on the ideas presented, we feel that the implementation of SOA and MSA depends on the capabilities and needs of organizations (e.g., performance, flexibility, availability, interoperability or other characteristics in return for known and unknown consequences) [33; 63]. Therefore, within the eHealth context and based on the results obtained, we observe that MSA is capable of meeting the majority of needs in support of medical decision making and is adaptable to different types of clinical systems (e.g., EHR, IoHT or telemonitoring systems) and various infrastructure solutions (e.g., nursing homes, hospitals and public health management) [16; 62; 117]; however, this brings with it many challenges [51; 74; 94; 99; 105]. The SOA and MSA architectural patterns can be considered complementary allies for an intereterprise or interbusiness architecture that confers a suite of different services, rather than being competitors [33; 118; 119], i.e., combining the SOA and MSA attributes within an environment. Therefore, we plan to work on a proposal for an intergenerational ecosystem for SOA-MSA, with the aim of developing a basis for the integration and interconnection of the different eHealth applications involved in medical organizations in conjunction with microservices adapted to machine learning-based inference systems to perform specialized tasks in decision support in the prevention, monitoring and treatment of various conditions. Additionally, we are exploring the possibility of extending our framework to other eHealth areas (e.g., a patient monitoring system for hemodialysis) [120; 121], early prediction of COVID-19 [122; 123; 124; 125] or prediction of heart and kidney risks in diabetic patients [126; 127; 128]). Another possible area for future research would be the adaptation of this proposal to other sectors of industry 4.0 (e.g., smart buildings or tourism) [8; 129; 130; 131; 132]; however, additional research is needed to obtain sufficient results to demonstrate the robustness of the architecture in terms of the adaptations of the attributes for these sectors. Our findings will be published in the near future. Conceptualization, J.M.G.-P. and M.V.-L.; methodology, H.C.-G., L.M.-P., J.M.G.-P., and M.V.-L.; software, H.C.-G., L.M.-P. and M.V.-L.; validation, H.C.-G., D.R.-P., G.S., M.-L.P.-L., and J.M.G.-P.; formal analysis, H.C.-G., J.M.G.-P. and [PERSON]-L.P.-L.; investigation, [PERSON]-G., [PERSON]-P., [PERSON]-L., [PERSON]-P., [PERSON]-P., G.S., and M.-L.P.-L.; resources, [PERSON]-P., M.-L.P.-L., G.S. and [PERSON]-P.; data curation, M.-L.P.-L. and G.S.