Zenith

Tens of millions of Canadians in rural and remote areas lack timely surgical access. Zenith tells health planners exactly where to build the next facility using AI and real Canadian data.

Comment

Inspiration

Rural and remote Canadians face a critical surgical access crisis. Indigenous communities and remote First Nations are disproportionately affected by geographic isolation from emergency surgical care. Existing planning tools don't account for Canadian geography, seasonal road access, or equity. We built Zenith to put data-driven facility optimization directly in the hands of provincial health authorities.

What it does

Zenith is a surgical access planning tool that:

  1. Analyzes Canadian Dissemination Areas against existing 24-hour emergency departments using real travel-time data
  2. Optimizes facility placement using a greedy algorithm that maximizes population coverage within the 2-hour surgical access window
  3. Generates AI-powered policy briefs tailored to Canadian health authorities using fine-tuned AI
  4. Visualizes coverage improvements and workforce constraints on interactive map

Input: "Place 5 new surgical facilities" → Output: Recommended locations, coverage gains, policy brief for decision-makers.

The Optimization Approach

The greedy algorithm iteratively selects facility locations that maximize coverage:

gain_i = Σ pop_j × I(d_ij ≤ 120 minutes)

This approach prioritizes population served within the critical 2-hour window, ensuring recommendations benefit the most people.

How we built it

The Process

Problem Definition and Architecture

We identified that health planners lack decision-support tools for rural surgical facility optimization. Existing approaches use spreadsheets or outdated models. Our goal: build a system that answers "where should we build next?" in seconds.

We designed a three-layer architecture:

  • Optimization Layer (backend): Takes population data and travel times, runs greedy placement algorithm
  • AI Layer (Freesolo): Generates specialized policy briefs from optimization results
  • Visualization Layer (Base44): Presents results to health decision-makers

Backend Development

Built FastAPI server with 6 endpoints:

  • /api/data — Returns population and facility data
  • /api/optimize — Takes facility count, returns optimal locations
  • /api/brief — Generates policy brief from optimization results
  • /api/workforce-alignment — Provincial physician supply data
  • /api/seasonal-access — Winter road and ice road access patterns
  • /api/investment-analysis — Cost estimates for facility development

Deployed to Railway with Docker containerization and API key authentication.

Training Data Generation

The key insight: we cannot rely on generic Claude for specialized policy briefs. We need a model that understands Canadian healthcare policy language, health authority expectations, and equity considerations.

We generated 80 training examples:

  1. Called our own /api/optimize endpoint with varying facility counts (1-10 facilities, 8 iterations each)
  2. For each optimization result, called /api/brief to get Claude-generated policy brief
  3. Collected 80 pairs of scenario statistics and corresponding policy briefs
  4. Formatted as JSONL for Freesolo Flash training

Model Fine-Tuning with Freesolo Flash

Submitted training job to Freesolo Flash:

  • Base model: Qwen/Qwen3.5-4B
  • Training method: SFT (Supervised Fine-Tuning)
  • Dataset: 80 Canadian surgical policy examples
  • Epochs: 3
  • Total training time: 6 minutes
  • Cost: 0.04 USD (thanks to Freesolo's hackathon credits)

Deployed trained adapter to Freesolo's managed endpoint for production inference.

Frontend Integration with Base44

Integrated backend APIs into Base44 no-code platform:

  • New Scenario form (input: facility count)
  • Scenario Results map (output: recommended locations)
  • Policy Brief view (AI-generated recommendations)
  • Site Review tabs (workforce, seasonal access, investment data)

Testing and Production Deployment

Deployed full stack to production:

  • Backend: Railway (auto-redeploys on git push)
  • Frontend: Base44 (published to Base44 platform)
  • AI Model: Freesolo (OpenAI-compatible endpoint)
  • Code: GitHub (public repository)

Technologies Used

Backend:

  • FastAPI (Python web framework)
  • Pandas (data manipulation)
  • NumPy (numerical computing)
  • Pydantic (data validation)
  • Python-dotenv (environment management)

Deployment:

  • Railway (cloud hosting)
  • Docker (containerization)
  • GitHub (version control)
  • Git (CI/CD pipeline)

AI and Machine Learning:

  • Anthropic Claude API (policy brief generation)
  • Freesolo Flash (model fine-tuning platform)
  • Qwen/Qwen3.5-4B (base model for fine-tuning)
  • OpenAI SDK (compatible inference)

Frontend:

  • Base44
  • REST API integration

Data Sources:

  • McGaughey & Peters 2024 — Travel-time analysis
  • StatsCan 2021 Census — Population and dissemination area data
  • CIHI 2024 — Physician supply by province
  • Salles and Mullan — Winter road access patterns

System Architecture

$$\text{User Input} \rightarrow \text{Optimizer} \rightarrow \text{Location Results} \rightarrow \text{AI Policy Brief} \rightarrow \text{Interactive Visualization} \rightarrow \text{Decision Support}$$

The optimizer analyzes population distribution and travel distances. The AI brief translates optimization results into policy language. The visualization presents complete context including workforce availability, seasonal access challenges, and investment requirements.

Challenges we ran into

1. Windows CLI Incompatibility with Freesolo Flash

Problem: Freesolo Flash CLI uses fcntl (POSIX filesystem module), which does not exist on Windows. Installation attempts failed with ModuleNotFoundError.

Solution: Installed Windows Subsystem for Linux (WSL) and ran Freesolo Flash from Ubuntu terminal within WSL. This provided a Linux environment while maintaining Windows workflow compatibility.

Learning: Specialized ML tools often assume Unix-based systems. WSL bridges the gap for Windows developers without requiring dual-boot or virtual machine overhead.

2. Python Version Compatibility in Production

Problem: pandas and numpy compilation failures on Python 3.13 when deploying to Railway. All dependency versions required Python 3.11-3.12.

Solution: Created Dockerfile explicitly specifying Python 3.11-slim base image. Removed root directory configuration in Railway settings that was forcing incompatible versions.

Learning: Pinning Python versions in production is critical. Letting deployment platforms auto-select versions leads to compilation failures with compiled packages.

3. API Key Authentication Blocking Training Data Generation

Problem: API key middleware was rejecting requests during training data generation script, preventing the backend from calling its own endpoints to generate examples.

Solution: Temporarily disabled API key middleware during data generation phase. Re-enabled for production deployment with environment-based configuration.

Learning: Development workflows need different authentication rules than production. Environment-based configuration (dev vs prod) is essential for operational flexibility.

4. Training Data Format Mismatches

Problem: Training data initially in nested JSON format did not match Freesolo's required JSONL format with flat input/output structure.

Solution: Built conversion script to transform nested JSON to flat JSONL with proper string serialization and escape handling.

Learning: Dataset format requirements matter deeply in ML workflows. Understanding training platform specifications before generating 80 examples saved significant debugging time.

5. Fine-Tuned Model Inference Authentication

Problem: Fine-tuned model endpoint required Freesolo API key in Authorization header, but initial implementation used placeholder authentication.

Solution: Added FREESOLO_API_KEY to Railway environment variables. Backend now properly passes Freesolo credentials with inference requests.

Learning: External API authentication needs to be environment-managed. Hardcoding keys is a security risk and creates deployment blockers.

Accomplishments we're proud of

Deployed production backend with 6 functional endpoints on Railway, handling real healthcare data and real Canadian geographic information

Generated domain-specific training data consisting of 80 Canadian policy brief examples collected from optimization scenarios and formatted for Freesolo

Trained specialized AI model using Qwen, fine-tuned specifically on Canadian healthcare policy language and recommendations

Solved Windows-to-Linux deployment compatibility by getting Freesolo Flash running on Windows via WSL, enabling full team participation regardless of operating system

Built pipeline using peer-reviewed travel-time research and census data from authoritative Canadian sources

Delivered end-to-end system with complete workflow from user input through optimization to AI policy brief generation to interactive visualization

Created production-ready architecture with API key authentication, containerization, environment management, and error handling

What we learned

Fine-tuning versus frontier models: Domain-specific training on 80 examples creates significantly better output than generic Claude for specialized tasks. The fine-tuned model learned Canadian healthcare policy language and framing that base models do not understand.

WSL enables cross-platform ML workflows: Specialized ML tools built for Unix do not require abandoning Windows development. WSL bridges this gap cleanly and efficiently.

Dataset format matters deeply: Understanding training platform requirements before generating large datasets saves hours of debugging and conversion work.

Environment-based configuration is critical: Different authentication rules for development versus production, different data endpoints for testing versus production. System flexibility is essential.

Health decision-support requires policy framing: Raw optimization results do not move decision-makers. Policy briefs that translate numbers into actionable recommendations are what actually drives decisions.

Freesolo Flash enables rapid model iteration: Training specialized models in 6 minutes on real examples beats weeks of prompt engineering. Post-training techniques are genuinely faster for specialized domains.

What's next for Zenith

Partner with provincial health authorities like Ontario Health or Manitoba Health for validation using actual facility planning data and requirements

Extend optimization scope to include telemedicine hub placement, mobile surgical unit routing, and workforce forecasting capabilities

Scale model serving from Freesolo to self-hosted inference infrastructure for higher volume production use

Compare AI recommendations against actual facility decisions made by provinces to validate and improve the model

Develop Zenith as a formal SaaS product for health ministries across provinces and international markets

Integrate real-time population and facility data updates to keep recommendations current as circumstances change

Built With

Share this project:

Updates