# Empowering Clinical Engineering and Evidence-Based Maintenance with IoT and Indoor Navigation +
## 3 Materials and Methods
### Integration with the ODIN Platform  
An instance of the ODIN platform (Figure 5) was deployed on a dedicated server within the hospital network, ensuring its communication with both the SPOT and OHIO servers. The modules of the ODIN platform that OHIO exploited include the IoT gateway (an Eclipse Mosquito MQTT Broker) [33], the semantic triple store (Apache Jena Fuseki [34]) for the ODIN ontology, and the enterprise service bus (ESB, namely Apache Kafka [35]). The technologies are part of the inner architecture of the ODIN platform as described in the deliverable D3.11 of the ODIN project [36]. The MQTT Broker collects the incoming messages from the BLE antennas, published via MQTT (message queuing telemetry transport) protocol; Apache Jena Fuseki is responsible for serving resource description framework (RDF) [37] data over HTTP (hypertext transfer protocol) performing semantic translations to the ODIN ontology; Apache Kafka is an open-source distributed event streaming platform for high-performance data pipelines, streaming analytics, and data integration, ensuring syntactic transport. Figure 4: Fingerprinting quality for the RTLS. (**a**) Magnetic mapping quality. (**b**) WiFi environment quality. (**c**) Beacon environment quality. Figure 5: Schema of the ODIN platform. Connectors were developed to allow communication between the above-mentioned OHIO applications (management web application and HiWay) and the local deployment of the ODIN platform, allowing them to be registered as key enabling resources (KERs). The first deployed connector translates the payload message from the MQTT protocol to a standardized ODIN-compliant JSON format and subsequently publishes it on a dedicated topic on the ESB. This information is then retrievable via another MQTT connector subscribed to the same Kafka topic, which exchanges information with the OHIO APIs. The development of the web application, APIs, and ODIN connectors was executed within the Microsoft.NET 6 framework, leveraging the MQTTnet [38] and Confluent's.NET client [39] libraries. OHIO also interfaces with the ODIN ontology (Figure 6), ensuring the desired level of abstraction. Various aspects of information about the healthcare facility, including buildings, stories, and rooms, are systematically mapped using the building topology ontology. The inner organization of the hospital, encompassing departments and operative units, is represented through an organizational ontology. Employee data are classified using the National Cancer Institute Thesaurus (NCIT) ontology for medical and allied health occupations and the friend of a friend (FOAF) ontology for non-medical personnel. Data related to medical devices are structured using the OdinEMDN ontology. Additionally, an extension of the ODIN ontology incorporating the Dublin Core Ontology (DC) [40] has been proposed and implemented. This extension integrates digital documents by building abstractions for a variety of file types, including images, texts, videos, and more. OHIO interacts with the ODIN ontology by storing information about performed maintenance on the Apache Fuseki semantic triple store. To ensure that relational data stored in the SPOT Microsoft SQL Server DBMS are accessible through the ODIN platform via semantic SPARQL queries, they need to be exposed through the ODIN ontology. R2 RML (RDB to RDF mapping language) is a language used for expressing customized mappings from relational databases to RDF datasets. Such mappings enable the viewing  
Figure 6: The ODIN ontology. of existing relational data within the RDF data model, expressed in a structure and target vocabulary chosen by the mapping author. R2 RML mappings are themselves RDF graphs and are written in Turtle syntax [41]. Therefore, an R2 RML connector was developed, utilizing the R2 RML4 net library. This connector processes the created R2 RML mapping graph against the SPOT SQL database.