## 2 Related Works  
As addressed elsewhere, interoperability in pervasive healthcare impacts directly on different levels, such as (i) interoperability of the collection system, involving sensor networks and integration of heterogeneous IoMT devices; (ii) interoperability in the exchange of data stored in heterogeneous IoMT information systems; (iii) definition of mechanisms for the dissemination of data to third party applications; and (iv) services for massive data processing and knowledge extraction. Below are some studies that partially solve such issues, however without considering the whole scenario. [PERSON] et al. [21] developed a platform that integrates different IoMT solutions for companies, such as Samsung, Microsoft, and Nokia. Data are collected by connectors, which are specific programs for a systematic extraction of data from each provider. The data are then changed to a format not specified in the article, stored in a non-standardized EHR, and re-transformed to resources in FHIR (fast healthcare interoperability resource) [22] and Open mHealth (author-defined format). The FHIR resources can be queried by third parties through a set of REST APIs defined by the FHIR standard (see Section 2.2). However, the platform does not consider the integration of isolated IoMT devices and ignores the supply of an environment that enables the application of data mining or analytic processing. Other proposals enable an agent-based approach to integrate isolated IoMT solutions. An agent plays the same role of the connector in the previous approach, which performs the CTL process, but follows an Agent-oriented programming (AOP) paradigm [23]. [PERSON] et al. [24] designed AIDA platform, in which an agent is developed to interact with each type of medical equipment and forwards the collected data to a main server. The authors used JADE framework [23] and, apparently, the EHRs are based on FHIR. However, the study lacks a definition of tools for data processing and integration of other EHRs, rather than IoMT devices. [PERSON] [25] defined an agent-based platform in which a set of agents (monitoring, component and system agents) performs the CTL from primitive platforms. Another set of agents (diagnosis, decision and searching agents) queries data and performs operations for clinical DDS. Data do not remain on the platform and are retrieved by the agents when necessary. The process hampers the application of data-processing techniques, since the massive volume of data must be retrieved in real time. [PERSON] et al. [26] developed Vicinity platform, which provides interoperability as a service following the concepts of adapters. Adapters can be consumed as services on demand and act similarly to the connectors defined in [21]. The main difference is connectors are developed specifically for a set of communication and data format standards, which simplifies the integration of IoMT devices to the platform. However, it hampers integration with IoMT systems that do not follow a standardized approach. [PERSON] and [PERSON] [27] conducted a survey on IoMT architectures and observed that two to five layers were commonly used. The authors adopted a three-layered IoMT architecture composed of things, intermediate, and integrated application layers to cover all IoMT requirements. The Things layer is comprised of heterogeneous IoMT devices that communicate through various communication protocols and networks. The Intermediate layer is represented by a middleware or gateway that handles the IoMT devices and processes the data at a local stage. The Integrated Application layer stores huge amounts of data and processes them through several applications. The authors ignored the definition of EHRs and disregarded the volume of data involved in the IoMT scenario.