Leveraging online tools and GIS software to generate routes for an Emergency Transport

Recently, D-tree’s project team performed a task very distinctive from our usual work in an effort to improve the design of our Emergency Transport System (EmTS) in Phase II of the Mobilizing Maternal Health (MMH) program. D-tree has been implementing the MMH program in partnership with Touch Foundation and Pathfinder International since 2015.

The system is an integration of different components that function together during an emergency:

· A call center, where emergency calls can be accepted and cases are managed;

· A triaging protocol, to determine the severity of a case and the level of facility that can handle the case;

· A database of participating drivers – ambulance and community members with cars – along with their phone numbers and locations;

· A database of routes with prices;

· Mobile money, through which the drivers receive payment after transporting a case.

Dispatchers at the call center, who are available 24 hours per day, receive calls (through a toll free number) from the community or facility about a case that needs immediate transportation. They have been trained to use a mobile application, which guides them to triage calls and determine whether the reported case should be treated as an emergency. The application then recommends the best facility to transfer the client based on the client’s location and condition. Through the same application, dispatchers organize transportation – an ambulance, or from the community (if ambulance is unavailable). Once the driver confirms availability, the system automatically sends him the client’s contact information and location through SMS. After the driver has picked up the client, the dispatcher can track the case until the client arrives at the facility and then follow up with the health care workers to determine the results. Upon a successful transportation, the system triggers a payment to the driver, which he receives through mobile money.

This system was piloted in 2 districts in northwest Tanzania and is now being scaled to 7 districts in collaboration with the Tanzanian government in the current phase after showing a 27% reduction in maternal mortality at a cost of $110 per life year saved, as outlined in this report.

The Emergency Transport System that was built in Phase I has been working well, but now that we have proof of concept, we are making some upgrades to support more efficient scalability and leverage advances in technology which can make the system even more effective. One way that we identified to strengthen the system was to improve the back-end database which feeds into the dispatcher application to coordinate transport routes, drivers and prices. The current static database requires the team to do a great amount of work to set up and maintain the system. For example:

i. Routes: There are currently 818 routes set between Shinyanga DC and Sengerema. The implementation team must identify all villages and facilities and manually determine the most appropriate routes to the nearest lower level, mid-level and hospital.

ii. Price negotiation: For every route, the implementation team must go through a process of negotiating a rate with drivers in these routes. This can be very time consuming, and maintaining the price list can be challenging.

We decided, together with our partners, to introduce a more automated system in which: (i) all villages and facilities are mapped with GPS coordinates and tagged with location type (village, dispensary, health center, or hospital) and (ii) all drivers are tagged to a specific location based on the nearest village or facility to where the driver is located.

GPS coordinates will be incorporated to support the following 2 functionalities:

· Pre-generated routes: By knowing GPS locations and type, the system automatically determines the most efficient routes from any location. For example, if an emergency originates in a village, the system identifies the nearest dispensary, nearest health center, and nearest hospital.

· Automatically calculated prices: With GPS coordinates known for all locations and drivers, the system automatically calculates route prices for any given route. This is based on the distance between two locations and a price per kilometer (KM) factor. It’s important to note that very few drivers in the program have smart phones, so we are unable to use real-time GPS tracking to calculate a price for a journey.

The caveat with calculating price per KM using GPS-based distances is that roads are not set up as straight lines (“as the crow flies”) i.e. the distance between two locations at the origin of the journey and at destination is rarely straight line. We worked to determine the best way to compute distances between villages and between villages and facilities and were able to use algorithms from various sources to compute more accurate “standard” distances (described later in this blog). These distances better reflect the real distances on the ground compared to straight-line distances, however, they still do not take into account road conditions and accessibility difficulties especially during or after heavy rains. Therefore, the system is designed to be flexible by allowing a pre-determined factor to be multiplied to a certain route if that route is determined to be particularly difficult or has other variations that make standard distances unreal. For example, if there are two routes, one from village A and another from village B, that have the same distance to destination facility in village C, but route B is determined to have bad road conditions and may take more time to reach to the facility, a factor is applied to route B so as to account for the realities on the ground.

With these considerations in mind, we are reminded how important it is to have a “systems thinking” – understand how different components of the system will interact with each other. From our experience, designing and agreeing on high-level system requirements with our partners before building the system has been very crucial. Specifying system requirements early on allows us and our partners to be clear on expectations i.e. capabilities and limitations of the system.

Obtaining village-level GPS coordinates

If the system scales up to the national level, we want to ensure that GPS coordinates will be available or accessible in a cost-effective way. After conducting research, we determined that GPS coordinates are largely available and can be generated from existing village maps in shapefile format (format for storing GIS data) and online resources.

Using GPS coordinates for each location

A location in this case would be a village, a health facility or a pickup point on the shore of a lake. For this option, a list of villages/shore and facilities by ward within each district needs to be readily available.

We identified 3 options to obtaining village-level coordinates:

1. Online resources: The team searched for coordinates remotely using different online tools including Elevation Map.net, OpenStreetMap, and Google Maps and was able to identify coordinates for 98% of the villages in Shinyanga DC. The identified GPS locations were placed on a customized Google map for easy viewing:

2. Village shapefiles: A shapefile is “an Esri vector data storage format for storing the location, shape and attributes of geographic features”, Esri. When shapefiles are available, GPS coordinates can be quickly computed using a GIS software such as ArcGIS. The team was able to use ArcGIS software to obtain village GPS coordinates from village shapefile for the Kahama District of Shinyanga region. But how could we be sure that shapefiles are available for the rest of Tanzania? We met with a mapping expert who works with the Humanitarian Open Street Map Team (HOT OSM), an international group that provides map data to assist in various areas including disaster management and public health initiatives. He shared with us village shapefiles for Tanzania that had been obtained from the National Bureau of Statistics and although it may need to be updated, most villages were captured.

3. A combination of gathering coordinates remotely and physically mapping villages which are missing GPS location OR remote gathering and approximating coordinates for villages missing GPS location. This would be a go-to option if we would be unable to achieve 100% of coordinates remotely; since physical mapping would be a field activity, the concern with this option is cost. However, the cost would be less if we only have to map a few locations.

Computing distances and possible routes

We used service providers such as Google Maps, Bing Maps and Open Street Maps to precompute a table of distances which could then be uploaded into a mobile device.

We created a script which reads from the Shinyanga DC Excel sheet containing village names and GPS coordinates and then created a table with possible paths between any two given villages and between villages and facilities.

The results provided the distance (in meters) as well as the driving time (in seconds) needed to go from one village to another and from one village to facility for each service provider. Depending on the data available for the service provider, some providers would suggest a quite straight route while others would suggest a route that is some kilometers longer. We assumed that all returned paths are valid in the sense that they follow an existing route. Hence, the optimal path should be the one with the shortest distance.

Bottom line, if we want to precompute all distances in a table, we would create a table containing only:

a) The name of the starting village

b) The name of the destination village

c) The straight line distance (which can also be computed on the device if the GPS coordinates exist)

d) The fixed minimum distance, which is the minimum distance between two villages, considering only those routes which are 90% or higher of the straight line distance (i.e. most likely to be correct) in meters.

What’s next?

We are now in the process of building a prototype of the new Emergency Transport System, incorporating the GPS coordinates and computed distances. This will also involve validation of the locations and computed distances since they are system-generated and would need to vet a few routes at random. We expect to roll out the updated system in the field in stages, beginning October 2018.

By using the process outlined above, we are significantly reducing the technical inputs required to set up the emergency transport system in new locations, and this gives us a significantly more dynamic and flexible system which can support more accurate coordination of emergency transport in the case of life threatening maternal and child health emergencies. We anticipate that the new system will be more easily scaled and able to continue achieving reductions in maternal and child mortality in Tanzania and beyond.