Mobile Clinic Placement Planner Using Travel-Time Coverage Maps

The problem with deciding where mobile clinics go

NGOs and district health teams run mobile clinics, vaccination camps and outreach days. Where these stop is often decided by habit, by which village asked loudest, or by straight-line distance on a map. Straight-line distance hides the real barrier: a village 8 km away across a river with no bridge may be two hours from the nearest clinic, while one 20 km away on a good road is 25 minutes.

Planners usually have three pieces of data that never meet: a facility list in a spreadsheet, a rough idea of where people live, and field staff knowledge of roads. The result is duplicated coverage near towns and blind spots further out.

What already exists and the gap

• AccessMod, from the WHO, models physical accessibility and coverage of health facility networks, and now has an online version. It is powerful and aimed at national-level analysts with GIS training.
• healthsites.io collects open health facility locations, useful as an input but not a planning tool.
• ArcGIS Network Analyst does location-allocation well but needs paid licences and GIS staff.
• Google Maps gives travel times for single trips, not a population-wide coverage analysis.

The gap is a small web tool that a district coordinator or NGO programme officer can use without GIS skills: pick an area, see who is out of reach, test "what if we add stops here", and export a plan. The data engineering (joining roads, population and facilities, and caching travel-time matrices) is the core of the work.

What you build

Roles: planner (runs scenarios), field staff (corrects facility locations and flags broken roads), admin (loads new data layers).

Flows:

1. Admin loads a district: road network from OpenStreetMap, population grid, facility list.
2. The system snaps population cells (H3 hexagons work well, the index Uber built for exactly this kind of spatial aggregation) and facilities to the road network and computes travel times.
3. The planner sees coverage bands and the ranked list of underserved areas.
4. The planner asks for K stops with a 60-minute limit; the optimiser proposes sites from a candidate list (schools, union council offices, markets).
5. Scenarios are saved, compared and exported.

The technically interesting part

Two linked problems. First, travel-time matrices at scale: tens of thousands of populated cells times hundreds of candidate sites is a large many-to-many problem. You need to run OSRM locally, batch requests, cache results in PostGIS, and deal with cells far from any road (add walking time to the nearest road). Show your supervisor the matrix build time and how caching changes it.

Second, location-allocation. The maximal covering location problem chooses K sites that cover the most population within a time limit. Formulate it as an integer programme, solve with PuLP, and compare with a greedy heuristic on quality and run time. Explain why optimal and greedy differ on your data.

How to evaluate it

• Travel-time accuracy: compare modelled times with at least 30 real or routing-service trips; report median and 90th percentile error.
• Coverage gain: population within 60 minutes before and after the proposed K stops, versus a hand-made plan and a random plan.
• Optimiser: solve time and optimality gap for K from 3 to 20; greedy versus integer programme.
• Pipeline: time to onboard a new district from raw downloads to first map.
• Users: three or more health planners or NGO staff complete a scenario task; note what they trust and what they question.

Suggested plan

1. Weeks 1 to 3: pick one district, gather data, interview a health programme officer.
2. Weeks 4 to 8: PostGIS pipeline, OSRM set-up, first travel-time matrix.
3. Weeks 9 to 12: coverage map and underserved ranking.
4. Weeks 13 to 18: optimiser, greedy baseline, scenario storage.
5. Weeks 19 to 23: field validation of travel times, corrections workflow.
6. Weeks 24 to 28: user sessions, evaluation, write-up.

Path to a product

The first customer is an NGO running mobile health or vaccination outreach, often funded by donors who ask for evidence behind placement choices. Sell a hosted instance per programme, or a one-time analysis package plus training. The same engine fits other facilities: schools, bank agents, pickup points, and could be sold to logistics firms choosing parcel lockers.

Scope warning

Do not build a patient record system or appointment booking. Do not model every district in the country; one or two districts, done with validation, is enough. Avoid a custom routing engine; OSRM is fine.

Learn what you need on Sefism

• Data Analytics roadmap : SQL, Python and visual analysis foundations.
• Data Analytics cheat sheet : quick reference while building the pipeline.
• PostgreSQL Documentation : the base for PostGIS storage and spatial queries.
• Our World in Data : examples of clear health access charts to learn from.
• From Data to Viz : choosing the right map and chart for coverage results.

Get help with this idea

The usual trap is spending all the time on the map and none on validating travel times. If you want a second opinion on scope, stack or how to evaluate it before you pitch it to your supervisor, a mentor can help you shape it. You still build it; the guidance is about making the plan realistic and the results defensible. New here? create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session