Designing and developing a mobile application for indoor real-time positioning and navigation in healthcare facilities

2.1Background

The hospital of Santa Maria alle Scotte is a highly specialized hospital campus which provides medical and surgical services with a catchment area of about 120,000 inhabitants for basic activities and 270,000 inhabitants for specialized activities. The hospital is organized in 10 medical departments:

The hospital covers an area of about 208,000 sqm with 800 beds and 8,100 rooms and is made out of 12 pavilions. The hospital is built on a hill, therefore, because of the uneven ground, the horizontal connection between adjacent pavilions cannot take place at a constant level throughout the area. For instance, it is not rare to have the basement of a given building connected to the first floor of the next pavilion through a flat hallway. The hospital is provided with an elaborate signage system, making use of vertical signs and horizontal signs, consisting in coloured strips along the corridors, pointing the users to elevators and other points of interest.

Despite this, the structure is exceedingly complicated, chaotic, and dispersed. These issues bring out the need to develop a mobile application for indoor navigation in order to improve the user experience, in relation to different typologies of consumers, such as patients and companions, but also external technicians, suppliers or visitors.

2.2Technologies

Despite the intense research on Real-Time Location Systems (RTLS) for indoor areas, to the best of our knowledge there is no universal solution which allows positioning in all kinds of indoor environment. Because each building has its own unique characteristics and challenges, there are currently no standard solutions for global indoor navigation systems [18].

IPS can be based on different technologies which can be used individually or together as a hybrid solution in order to increase the level of accuracy.

This short list shows that a wide range of technologies is available for IPS but currently there is no perfect solution. As a matter of fact, a practical Indoor Positioning System must balance accuracy, labour cost, facility expenses, reliability and complexity. At the moment no technology meets the requirements in all these aspects. In recent years, Artificial Intelligence has also been used to solve indoor positioning problems, leading to systems based on Artificial Neural Networks (ANNs) which have the task of learning the relationship between position and measurements by applying appropriate learning methods [26].

2.3Indoor positioning system

Another aspect to be considered is the type of technology which best meets the limits of use in a hospital. All buildings are located in a magnetic landscape due to the interaction between the numerous devices (medical and non-medical) with steel cases and the magnetic field generated by the Earth itself (which in the absence of steel structures would be almost constant). Moreover, the possible steel structure of the hospital can be an additional interaction factor with the Earth’s magnetic field. Magnetic positioning appears to be the most comprehensive and affordable on the market, as it offers estimation accuracy without hardware requirements and it makes the most of the computational capabilities of the smartphone, allowing to obtain an accuracy of the estimate of 1–2 metres.

In addition to magnetic positioning, it is useful to employ multiple technologies through sensor fusion, which allows to combine each data source linked to the position to obtain a sharper and faster universal positioning, optimizing the timing of estimation and accuracy. Many of the data which can be recorded by the built-in smartphone sensors are alterations of the magnetic fields, variations in WiFi and Bluetooth signals, and position changes detected by accelerometers and gyroscopes. Therefore, the sensor-fusion may allow to obtain the maximum result, increase precision, reduce costs and make the most of the characteristics out of each available technology [27].

Several frameworks currently available on the market have been evaluated and tested (GiPSTech, Situm, IndoorAtlas, GoIndoor, Navisens, Dent Reality). All of them offer Mobile SDKs (Software Development Kits) for Android, iOS and cross-platform solutions such as Apache Cordova or Microsoft Xamarin. The aspects taken into consideration when performing the comparison among vendors consisted in sensor-fusion support, availability of online framework’s technical documentation, free-testing features and prices (Table 1). Vendors which do not offer free-testing features and frameworks which only rely on specific technologies (no sensor-fusion support) were excluded a priori. Preliminary tests have been performed by using IndoorAtlas and Situm. They both use a positioning system based on sensor-fusion technique which needs very few pre-processing tasks. Earth magnetic field (which must be mapped by using specific vendor’s application) and dead-reckoning are the base technologies needed for indoor navigation. This means that no external hardware (such as WiFi routers, BLE Beacons or radio access points) are mandatory, even though they can still be used to improve precision and accuracy. IndoorAtlas has been preferred over Situm in the demoing and testing phase because it offers an easier and user-friendlier mapping tool, together with a better and more comprehensive free documentation.

As stated above, IndoorAtlas needs a pre-processing phase in order to display the layout of available storeys and to collect the actual Earth magnetic field interference and electromagnetic data. Floor plans images are added to the world map and then aligned along the geographic coordinates by using the dedicated IndoorAtlas FloorPlans web application. This allows the use of frameworks based upon geographic coordinates systems, such as Google Maps or OpenStreet Map. Subsequently, IndoorAtlas MapCreator must be used to record data relating to the magnetic field and WiFi signals (possibly integrated with BLE signals if available). MapCreator connects with IndoorAtlas navigation APIs within the offered SDK, which allow the collected magnetic field and possible WiFi and BLE signals to be used for indoor positioning.

2.4Target application

Mobile applications (or simply “apps”) can be classified into three main categories, based on the development framework and architecture:

Each category has its own pros and cons, so the choice must be made by carefully assessing the different conditions and the whole context. When designing a real-time navigation system for use within a healthcare facility, the main target is to offer the service to the widest possible range of people. Therefore, at first, a responsive website could probably be the best solution thanks to its large compatibility and simplicity of implementation, not requiring any download or installation steps. However, a mobile application can be deemed the most appropriate choice in order to smoothly interact and communicate with users and make the most out of many smartphone features [28, 29]. Mobile applications provide an interactive interface, making users prefer them to the static navigational experience offered by websites (Fig. 2). Besides, mobile applications are available also in offline mode and can make use of needed phone features such as location services and camera (Fig. 3). In the case of a native app, however, the difficulty of implementation caused by non-compatibility features across multiple operating systems together with higher maintenance costs must be also taken into account.

Figure 1.

The hospital is provided with an elaborate signage system, making use of vertical and horizontal signs, consisting in coloured strips along the corridors, pointing the users to elevators and other points of interest.

Figure 2.

Average time spent per day by mobile internet users in US through 2019. Source: eMarketer.

Figure 3.

Main differences between mobile applications and mobile web-sites.

In consideration of the previous aspects, we opted for a cross-platform hybrid application as the best developing architecture. Even with lower performance in terms of speed, it is less expensive (both in terms of time and costs), especially in terms of future maintenance and updating.

The main available cross-platform deploying frameworks have been identified in past studies [30]:

Applications developed with each of the above-mentioned framework (but Xamarin) are said to be hybrid, meaning that they are neither truly native mobile application (because all layout rendering is done via web views instead of the platform’s native UI framework) nor purely web-based (because they are not just web apps, but are packaged as apps for distribution and have access to native device APIs).

Apache Cordova has been chosen among the various possibilities because it provides all the functions needed to develop the prototype target application (access to the device hardware such as accelerometer, gyroscope, camera), whilst maintaining a very low learning-curve (unlike Xamarin, Flutter and React), an active community and documentation (unlike PhoneGap), native Javascript programming and still being among the top mobile app development frameworks in 2019–2021 (Fig. 4).

Figure 4.

Top mobile app development frameworks 2019–2021. Source: Statista at https://www.statista.com/statistics/869224/worldwide-software-developer-working-hours.

2.5Development methodology

System architecture must be defined in advance in order to reduce the complexity, solve architectural problems, reduce development time and costs and provide a proper work management. Unified Modeling Language (UML) is a common visual modelling language, rich in both semantics and syntax, used

for the architecture, design and implementation of complex software systems both from a structural and behavioural point of view. For this manuscript, UML diagrams of use cases, classes, activities and sequences have been designed.

The application offers two different navigation modes, depending on the actual position of the device while using the app: on-site and off-site. In on-site mode (Fig. 6), users have the possibility to search for the destination, view the proposed route and then proceed with the navigation. This mode is available only when users are located within the navigable area of the hospital. The search for the destination can be carried out in different ways, each of which is represented by a specific application icon:

After selecting the desired destination, the route is displayed allowing the user to start the navigation. In on-site mode, users also have the possibility to access a list of planned routes, select one of them and then proceed with the navigation.

Instead, in off-site mode (Fig. 6), users can visualise and then save a given path without actual being at the hospital. This mode is always available, regardless of the position of the device, allowing users to plan a navigation. The destination is chosen by using the same search methods proposed in on-site mode. Then the route is displayed and it can be saved or edited by adding further sections: each section will have the destination of the previous one as its starting point, and a new destination selected using one of the available methods. By accessing the saved routes, users can visualise them on the map or delete them if desired: this feature is available in both modes.

3.1Linking the application with the Computer-Aided Facility Management system of the hospital

The hospital of Santa Maria alle Scotte has an internally developed custom CAFM system, named SPOT, which is a tool that allows the analysis of spaces and the organization and evaluation of hospital data and parameters [31, 32].

SPOT’s main relational database is a Microsoft SQL Server instance installed on a dedicated hospital data-server. The core module has been developed as a Windows Forms Application within Microsoft .NET Framework.

For the development of the indoor navigation system, it is useful to take advantage of the existing SPOT system. In fact, the coordinates and plans of floors with information about Operating Units (OUs), rooms, offices and all those places that can be considered points of interest can be provided by the system itself. At the same time, it is important to avoid to directly expose the hospital inner network to external users, in order to preserve the integrity of the contained data and reduce possible cybersecurity attacks.

Figure 7.

Activity diagram of application start. watchVenue, watch-FloorPlan, watchGeofences, watchPosition and watchOrienta-tion are IndoorAtlas methods while addGroundOverlay, ad-dPolygon, addCircle are Google Maps methods.

For this reason, a new set of WebAPIs have been developed within Microsoft .NET Framework and then installed on a web-server connected both to the inner and outer (i.e. exposed to the web) network. Hardware and software firewalls, together with SSL encryption, provided the required levels of logical separation between the two networks. The APIs operate as an intermediary layer between the mobile application installed on the user’s mobile and the SPOT system. Besides, it is essential to protect the privacy of users while they are using the app. For this reason, no personal username and password are requested during the authentication phase. Only a common set of credentials and an API-key are used instead. In this way, the user is not associated with an individual person and no user’s sensitive data are sent across the network.

3.2Authentication and data protection

The application authenticates itself with specific API keys on IndoorAtlas and Google Maps frameworks, as well as on the SPOT system. While authorization with third-party solutions is demanded on their inner architecture (documentations are available on owners’ websites [33, 34]), the authentication with SPOT has been developed from scratch, upgrading the current release of the system with a dedicated module. The application authenticates itself on the system using Basic Authentication security protocol with an HTTP POST method to the dedicated API controller, sending a Base64-encoded username and password within the request header. As stated above, this login method avoids users to actually personally sign-in to the system, preventing personal information and identity theft, while assuring a virtual identity confirmation and authorization at the same time. If the authentication is successful, the system returns a JWT (JSON Web Token) valid for the next 24 hours, which the application will use to authenticate itself in future API calls via Bearer Authentication security protocol.

Figure 8.

Available modes.

3.3Developed interface and navigation modes

Once authentication has been provided, the application is ready to run. The designed interface prompts the user to choose between one of the two proposed modes (Fig. 8):

Figure 9.

Activity diagram for selecting points of interest.

3.3.1Off-site mode

Figure 10.

Preliminary stages for off-site mode.

This mode can be selected by users who are not physically on the venue and want to plan and save a route. Users can choose the destination, the starting point, visualize the route and eventually save it in the mobile’s storage (Fig. 9). Three distinct routines are available for searching the desired destination POI (Fig. 10a): by choosing the endpoint among a list of pre-designed useful destination (getPOIByOU), by inputting the room code if it is known (getPOIByRoom) or by searching a physician’s name (getPOIByName). Likewise, the starting point must be selected among a list of fixed locations which correspond to the main entrances to the hospital. The available POIs are listed as follows and theirs position on the map are shown in Fig. 14:

• 1. Entrance

• 2. Blood Sampling Point

• 3. Buildings Intersection

• 4. Building 1 Lifts

• 5. Building 4 Lifts

• 6. Playroom

• 7. Emergency Department Lifts

• 8. Building 2 Lifts

• 9. Cafeteria

• 10. Building 3 Lifts

The coordinates of starting and ending points are given as input to the startRoute method, which requires the calculation of the route through the IndoorAtlas framework.

The app displays a map of the building’s storey, with the navigable area highlighted in blue, the planned route highlighted in red, the beginning location marked with a blue dot, and the destination marked with a red marker. Moreover, information about the total length of the route is displayed at the bottom (Fig. 10b). Lines, shapes and markers are drawn onto the map through the addPolyline and the addMarker methods of Google Maps.

The user can eventually save the planned route inside the mobile’s memory by pressing the green ”Save” button at the bottom-left corner of the screen. The app prompts the user to enter a custom name for the route (Fig. 11a). The routine stores the coordinates and the floor number of both the destination and the starting point in JSON format inside the device’s internal memory. If the user wishes to insert an additional leg for the current route (Fig. 11b), the whole activity is repeated and the destination of the previous leg will be automatically stated as the new starting point. The operation can be further iterated endlessly.

Figure 11.

Saving route, adding a new leg and display saved routes in off-site mode.

The user can then click the “Route” button (right below the “Home” button – Fig. 10a) to access the list of saved routes, possibly selecting or deleting them by choosing from the available options (Fig. 11c).

3.3.2On-site mode

In on-site mode, the user can actually navigate within the hospital. The destination can be selected by:

• • choosing a point of interest through the three different routines described in the previous section and outlined in Fig. 9;

• • starting from a previously saved route: the loadRoutes method loads the available saved routes (Fig. 12). Once the desired one is chosen, the coordinates of the stored destination point are passed to the IndoorAtlas framework to evaluate the shortest route in relation to the current user’s location.

  Figure 12.

  Activity diagram for loading the saved routes.

  

  The route is then displayed by using Google Maps framework. Notice that the current user’s location is used as starting point despite the one which had been chosen in off-site mode, which served just for reference and planning purposes.

Figure 13.

Route loading and navigation for on-site mode.

Figure 14.

Map of tested ground storeys of six adjacent pavilions of the Hospital Le Scotte, Siena (Italy) with navigable POIs and paths.

After the route is displayed, the user can proceed to the actual navigation by clicking the “Start” button (Fig. 13a). The current point locator is substituted with a blue arrow-shaped locator. An approximation blue circle is also displayed around the location marker. The radius of the circle specifies the precision of the IPS, being proportional to the error of the positioning system (Fig. 13a and b). In navigation mode, the map’s orientation is no more referred to fixed cardinal signs, but to the actual orientation of the device. A tilt is also performed on the map itself, which becomes oriented in relation to the direction the device is actually pointing to (Fig. 13b). These displaying variations are useful to differentiate the navigation activity from the previous map and route visualization. The IndoorAtlas method requestWayfindingUpdates is recursively called until the destination is reached. During the navigation, the locator follows the movement of the device and moves along the path. Once the destination is reached, the application prompts the user accordingly. The user can always stop the navigation at any time by clicking the red “Cancel” button at the bottom-right side of the screen. Once the user arrives at his destination, the application notifies him that the navigation has been performed successfully, the route is erased from the map, and the device returns to its normal view.

3.4Testing and implementation

A demo version of the app has been tested to assess the positioning error and the tolerance of the IPS on hospital areas where the magnetic field and WiFi signals had been previously acquired (no BLE beacons installed). Positioning error is defined as the offset between the actual position and the displayed locator, while tolerance represents the margin of error for each measurement and it is defined as the value of the radius of the approximation circle. Tests have been conducted on Android OS using a Xiaomi MI Mix smartphone with an active data connection on the ground storeys of six adjacent pavilions for a total surface of 12,438 sqm.

3.4.1Test 1

The first conducted test has been carried out to measure the positioning error and the tolerance for each available POI. Each measurement has been taken 10 times in each site. Results are shown in Figs 15 and 16.

Figure 15.

Box plots of positioning errors for each navigable POI (test 1).

Figure 16.

Box plots of tolerances for each navigable POI (test 1).

3.4.2Test 2

The accuracy of the IPS has been also tested in free-navigation mode (i.e., no destination selected). A closed loop of about 214 m (from POI 3 – Buildings Intersection – to POI 8 – Building 2 Lifts – and back) has been travelled with an average speed of 1.38 m/s. The test has been repeated 20 times. Initial and final values of positioning error have been measured for each iteration (Fig. 17).

Figure 17.

Initial and final positioning error for 20 iterations of a closed loop free-navigation between POI 3 and POI 8 (test 2).

3.4.3Test 3

The third and final test measured the accuracy and the tolerance of the system during navigation in on-site mode. The chosen route was from the main entrance of the hospital (POI 1) to the lifts of Building 4 (POI 5). The total length is about 206 m. Navigation has been repeated 20 times with an average speed of 1.38 m/s. For each iteration the positioning error between the physical position and the displayed marker of the destination has been measured (Fig. 18). Moreover, the value of the approximation radius has been sampled every 2 s during every navigation to evaluate the trend of the tolerance of the IPS during navigation (Fig. 19).

Figure 18.

Plot of destination accuracy (positioning error) trend through 20 iterations of a navigation between POI 1 and POI 5 in on-site mode (test 3).

Figure 19.

Box plots of tolerances for each iteration of test 3.