## 6 Patient Transfer Logistics
### Data Access by Users  
Various platforms can be used to enable user access to the system including web, smartphones or \(SMS\). The proposed system allows users to access the data via Representational state transfer (REST) APIs. HTTP requests are sent to the server and the server returns fetched data based on user context. The location information can easily be shown to users via Google maps or an equivalent map service. Through a simple application, patients and general passengers can easily search a bus by bus number directly. In case the user is not aware of the bus number, he/she will be asked to first select the nearest bus stage (i.e., the boarding point). The process can easily be automated by keeping a database of bus stops along with their corresponding location data. Distance to the the system is calculated by comparing a user's location to that of the bus stops, applying the Haversine formula:  
* \(Lat_{1}:\) User latitude
* \(Long_{1}:\) User longitude
* \(Lat_{2}:\) Bus stop latitude
* \(Long_{2}:\) Bus stop longitude
* \(d_{\text{Long}}:Long_{2}-Long_{1}\)
* \(d_{\text{Lat}}:Lat_{2}-Lat_{1}\)
* \(r:\) Earth's Radius.  
Then  
\[\begin{split} H&=\left(\sin\left(\frac{d_{\text{ Lat}}}{2}\right)\right)^{2}+\cos\left(Lat_{1}\right)\times\cos\left(Lat_{2} \right)\times\left(\sin\left(\frac{d_{\text{long}}}{2}\right)\right)^{2}\\ B&=2\times\tan-1\left(\sqrt{H},\sqrt{1-H}\right) \\ \text{Distance}&=Br\end{split} \tag{18}\]  
From Equation (18) above, the nearest bus stop will be the one with the shortest distance. The live location of a bus is queried based either on target destination or bus number. If the user enters a bus number, the user API returns the last known bus location from the central buses collection. To allow mapping of the boarding stop-destination point to the route number, a database of all buses on all routes can be maintained. Hence, if a user selects a boarding point and a destination point, he/she gets a live location of all buses on a route that takes him/her to the destination.  
In Table 2 above, the first row shows the route numbers, whilst the corresponding columns list bus stops on that route. For example, if a passenger queries data by boarding and destination bus stages, the query is then checked in the table. Take stops \(B\) and \(A\) where \(B\) is the boarding stage and \(A\) is the destination bus stage. The system simply checks the table to verify if bus stop \(B\) occurs in the  
Figure 8: Message queuing telemetry transport (MQTT) clusters: Every node maintains a tree of topics.  
table and is followed by \(A\). However, bus stop \(A\) need not immediately follow \(B\). In Table 2, we see that routes number 101, 201 and 301 have such conditions. The query will then fetch the live locations of the buses on these three routes and return them to the user. The queries from the user module will be the same across all platforms. The output for the HTTP GET request will take the following formats.  
* Query by registration number: The query by registration number will return a JavaScript Object Notation (JSON) response fetching data from 'buses' collection with the parameters latitude, longitude, bus registration number, bus route number, direction and time stamp.
* Query by route number: The query by route number will return a JSON array containing objects, with each of the objects giving details of active buses running on that route. The data will be fetched from a collection with the name 'route number'.
* Query by boarding point and destination: This query will return a JSON array containing objects for active buses on every route, from the boarding point to the destination. This data will be fetched from various collections based on which routes are applicable.