Accessibility is a travel-time relationship, not a facility count.
Every population area is evaluated against the facilities that actually provide the selected service. CareGap does not assume the nearest facility is suitable. In the Delhi release, services are attributed only from OpenStreetMap tags; a facility name is never used to infer a service.
t_i = min over f in F_s of travel_time(i, f) covered_i = 1 if t_i <= T else 0 coverage = Σ(pop_i * covered_i) / Σ(pop_i) for areas with population weighted_mean_time = Σ(pop_i * t_i) / Σ(pop_i)
Delhi denominator
272 MCD wards, 16,000,745 people (Census 2011). The 18 NDMC/Cantonment charge polygons and the unassigned riverbed polygon carry population: null. They are analysed for travel time but excluded from every population denominator.
Not in the denominator
787,196 people (4.7% of the 2011 NCT total) are not represented: NDMC and Cantonment residents, rural village population inside wards, and boundary mismatch. Coverage is reported against the represented 16,000,745 only.
A service tag means the facility is modelled as offering the service. It does not verify staff, equipment, stock, hours, affordability, or quality. Areas with no suitable mapped facility are uncovered with no invented travel time.
Service attribution in the Delhi pilot
| Facility category | Modelled services |
|---|---|
| Hospital (OSM amenity/healthcare) | Primary care; emergency only with emergency=yes |
| Health centre / Ayushman Arogya Mandir | Primary care |
| Dispensary | Primary care |
| Clinic / doctor | Primary care |
| Birthing centre | Maternal health |
| Diagnostic laboratory | Diagnostics |
| Maternal or obstetric tag | Maternal health added from the mapped speciality |
| Proposed clinic / sub-centre / AAM | Primary care + maternal health (assumed) |
| Proposed diagnostic centre | Diagnostics (assumed) |
Shortest paths over OpenStreetMap roads.
The Delhi release ships a routed graph built from OpenStreetMap drivable ways (motorway through residential and living-street classes) clipped to the NCT boundary. Edge time is length ÷ class speed, capped by a parsable maxspeed tag. Dijkstra is run on an undirected graph; one-way restrictions are not modelled.
Ward centroids and facilities snap to the nearest road node. A straight-line local-access leg is added at 15 km/h with a 1.25 detour factor. Population-weighted statistics use the same area times shown on the map.
Speeds (km/h): motorway 80 · trunk 60 · primary 50 · secondary 40 · tertiary 35 · unclassified 30 · residential 25 · living street 15; links are slightly slower. The snapshot date is recorded in the data source register.
Explicitly not claimed
- Not live traffic, congestion, closures, or turn-by-turn routing.
- Not walking, cycling, public transport, or emergency-response time.
- Not facility wait time, opening hours, capacity, or service availability.
- Not a measurement of actual patient travel or utilisation.
A straight-line fallback exists only for the explicitly synthetic demo. It is never used for the Delhi release: a missing road artifact stops the API with an actionable error.
Metric note
A median of 9.6 minutes means half of the represented population lives in a ward whose centroid is at or below that value. It is not a measurement for every resident, and it can conceal large differences inside a ward.
Worst-served is defined before results are seen.
For scenario comparisons, CareGap sorts population areas from longest to shortest baseline travel time and includes areas until at least 20% of the represented population is in the group. Unreachable areas sort first. The group is fixed from the baseline and then compared before and after the intervention; it is not re-selected to flatter the result.
Vulnerability weighting is unavailable in this release
No defensible ward-level vulnerability indicator was acquired for the Delhi pilot. Rather than fabricate one, the release reports vulnerability_index: null, disables the equity-weight slider, and forces the equity weight to zero. Candidate ranking still uses newly covered population, person-minutes saved, and the worst-served group. The synthetic demo has its own clearly labelled synthetic index for workflow testing only.
Additive by design.
A scenario stores 1–5 proposed facilities of a single intervention type, the service, threshold, and coordinates. The same accessibility function is run on the active dataset with the proposed facilities added. Existing facilities are never removed or degraded, so an area's nearest-facility time cannot worsen. Automated tests assert this invariant; a positive worsened count is surfaced as a defect warning.
Proposed facilities are marked proposed in API responses and on the map and are never counted as existing facilities. A proposed site must fall inside the active ward geometry. Capacity, staffing, schedule, cost, and quality are not modelled; intervention assumptions are returned with every simulation and shown in the interface.
An explained heuristic, not an optimum.
Candidates are the representative points of the 272 populated wards. Each candidate is evaluated by adding one facility and re-running the same analysis. Components are normalised by the best candidate in the current set, so scores are relative, not absolute utility.
coverage_component = newly_covered_population / best_candidate_value
equity_component = vulnerability_weighted_gain / best_candidate_value
travel_component = person_minutes_saved / best_candidate_value
score = (1 - w_equity) * coverage_component
+ w_equity * (0.75 * equity_component + 0.25 * travel_component)
score *= 0.9 if the candidate's own ward is already covered
Delhi pilot: w_equity = 0 because no validated vulnerability input exists.The recommended set is greedy: choose the best marginal candidate, add it, re-run, repeat. Ties break by area ID. This is not a global optimum and not a claim about land availability, cost, or political feasibility.
Every number has a definition.
| Metric | Definition |
|---|---|
| Coverage | Population in areas whose modelled nearest suitable facility is within the threshold ÷ represented population |
| Covered population | Sum of Census 2011 ward population in covered areas |
| Weighted mean time | Σ(population × nearest-facility minutes) ÷ Σ(population), populated areas only |
| Weighted median / p90 | Population-weighted percentile of area travel times |
| Newly covered population | People moving from outside to inside the threshold after an additive intervention |
| Worst-served group | Areas sorted by baseline travel time until at least 20% of represented population is included |
| Residual gap | Population still outside the threshold after the intervention |
Coverage is modelled access, not attendance, utilisation, clinical quality, or health benefit.
Real sources, with their defects visible.
Boundary
OpenStreetMap relation 1942586 (admin_level=4, ISO IN-DL), 1,482.04 km², validated against the official 1,483 km² figure.
Wards
DataMeet 272-ward municipal layer plus 18 NDMC/Cantonment charges. Ward polygons extending outside the NCT boundary were clipped at build time (44 wards, 10.5 km²); population counts are unchanged.
Population
Census of India 2011 ward-level Primary Census Abstract. All 272 MCD ward numbers joined exactly; the total 16,000,745 cross-checks against the official 16,787,941 NCT total minus NDMC, Cantonment, and rural population.
Facilities
1,856 OSM elements filtered to 1,368 care facilities; 472 excluded as pharmacies, dentists, laboratories outside the care model, or other out-of-scope tags; 16 duplicates merged only when the normalised name matched within 150 m; zero outside the boundary.
Roads
125,452 drivable ways assembled into a 532,088-node graph. The largest connected component covers 99.5% of nodes. Zero areas and zero facilities are unreachable in the baseline matrix.
Imports
CSV/GeoJSON facilities are validated for schema, coordinate range, category, services, duplicates, and boundary containment. Population-area imports are disabled for Delhi because the release must match the validated Census ward set.
Provenance
Every facility carries its OSM element ID, source URL, relevant tags, and operational_status=unknown. The dataset manifest records release ID, source dates, licences, counts, and validation results.
Known answers, not vibes.
Backend tests include known-answer accessibility cases with nullable population, a dictionary/array parity test, the additive non-worsening invariant, release validation (population sum, geometry, boundary containment, facility provenance, duplicate checks), routing consistency, API contracts, import validation, read-only mode, and a failure test proving a missing real-data release does not fall back to synthetic data.
cd backend ../.venv/bin/ruff check app tests ../.venv/bin/pytest cd ../frontend npm run lint npm run typecheck npm test npm run build npx playwright test
Actual pass/fail counts for each run are recorded in the release report and the repository README. A skipped or unavailable test is reported as such, never counted as a pass.
What this pilot cannot establish.
Historical population
Census 2011 is a 2011 baseline, not current population. The 2022 municipal delimitation is not represented.
Partial denominator
NDMC and Cantonment charge populations, rural village population, and the unassigned riverbed are outside the denominators. Results describe 95.3% of the 2011 NCT population.
Incomplete facility inventory
OpenStreetMap completeness is unknown. A facility absent from the map is not evidence that care is absent.
Unverified services
Service attribution comes from tags. Operating status, staffing, hours, equipment, stock, affordability, and quality are not verified or modelled.
Coarse geography
Ward centroids represent where people live. Intra-ward differences and informal settlements are concealed.
Routing assumptions
No live traffic, one-way restrictions, turn restrictions, public transport, walking, or seasonal access.
No vulnerability input
Equity weighting is disabled rather than fabricated. Vulnerable sub-populations are not identified.
Heuristic ranking
Greedy candidate selection is not globally optimal and ignores land, ownership, utilities, flood risk, and cost.
No outcome claims
Coverage is modelled access, not utilisation, treatment, health improvement, or causal effect.
Public-demo controls
The API has no authentication by default. Mutating endpoints must be disabled (read-only mode) or protected before public exposure.
Coverage is not care.
Appropriate uses
Comparing modelled access, finding candidate sites, testing assumptions, and asking better questions before resources are committed.
Not appropriate
Allocating real resources, inferring individual need, making clinical decisions, or claiming that a mapped facility is staffed and available.
No patient-identifiable data is collected, accepted, or required. CareGap is an aggregate geographic planning tool, not a clinical record system. It is not affiliated with, endorsed by, or an official product of the Government of NCT of Delhi or any facility operator.
An inspection instrument, not a dashboard.
The interface is an original implementation informed by the InstaLanding design library: Halden Clinical Equipment (clinical restraint, mono instrumentation, inspection board), Footnote (warm paper, Source Serif, semantic highlighter), GEO/LAB (spatial instrumentation), and Mirador (rail + context filters). No third-party code, fonts, or assets were copied. See the design audit and credits in the repository documentation.