DeepCare

DeepCare Offline gives frontline health workers instant, AI-powered clinical triage on basic 8GB laptops—100% offline, zero internet, and no cloud fees when every second counts.

Comment

What it does

DeepCare is a small Python app for clinical triage in low-connectivity settings. It is designed for community health workers and nurses who need an explainable, offline decision aid on a normal laptop without depending on internet access.

Inspiration

The inspiration for DeepCare came from a conversation with a family member who spent time as a Community Health Worker (CHW) in a rural district. They described the profound stress of being the only medical point of contact in a digital blackout. When a high fever or complex symptom presented itself, they were isolated. There was no cell service, no internet, and the nearest hospital was over a four-hour drive on rough roads. Making the wrong triage call sending someone home who needed an emergency referral could be fatal.

The world is celebrating large language models but in that rural clinic, ChatGPT is entirely useless. I realized that African clinicians and CHWs don't need shiny new tech, they need ruggedized dependable support for the hardware they already own.

The Africa Deep Tech Challenge 2026 became the perfect catalyst for this idea. The constraints; the limited laptop hardware (8GB RAM), CPU-only inference, and complete offline requirement forced us to confront the same constraints that CHWs face daily.

What We Learned

We learned that "state-of-the-art" doesn't mean "cloud-only." Building DeepCare taught us a fundamental lesson in localized inference. We discovered that by using severe quantization, we could run high-performance language models (like Qwen2.5 or Llama-3.2) efficiently on standard CPU laptops. We learned to optimize prompt representation, forcing the LLM to output clean, structured risk assessments (JSON) instead of conversational chatter. Most importantly, we learned to balance rule-based safety with modern AI reasoning. We designed the system so that local clinical rules always act as a failsafe for the LLM.

How We Built It

The building process focused intensely on portability and simplicity:

  1. Model Optimization: We selected small base models (1B to 3B parameters) to ensure speed. We quantized the models to GGUF Q4_K_M, dramatically reducing their RAM footprint to fit comfortably within the 8GB challenge budget.
  2. Core Integration: We chose llama-cpp-python as the main inference engine because of its incredible C++ optimization on CPU hardware.
  3. Application Logic: The app.py script was built using Python's standard library. When a symptom is entered, the app constructs a compact, domain-specific prompt. This prompt is fed to the local model, which generates a structured JSON output (e.g., {"triage": "EMERGENCY", "reasoning": "Signs of WHO danger category A"}).
  4. Local Storage: All patient data is stored locally on the device in an encrypted-ready SQLite database. No data is ever transmitted off the laptop.
  5. Deployment Script: The required download_model.sh script was built using only standard Unix tools like curl and bash to ensure it runs correctly on any laptop profile without hidden dependencies.

Challenges Faced

The road was far from simple. Our biggest challenge was finding the precise intersection of speed, intelligence, and memory constraints. Initial tests with unoptimized models caused immediate Out Of Memory (OOM) crashes.

  • Prompt Engineering: We struggled to make the local model deterministic. A "conversational" AI is dangerous in medicine. We had to spend significant time engineering specific, rigid prompts that forced the local model to adopt a conservative, standardized WHO-compliant triage vocabulary and output strict JSON, rather than conversational text.
  • Pathing Errors: Making a cross-platform (PowerShell vs. Bash) application that correctly found the GGUF weight file was tricky. We had to implement robust path resolution to ensure the app found model/deepcare-llm.gguf regardless of the evaluation environment.

Despite these hurdles, the final prototype runs 100% offline and delivering a danger-sign assessment in under two seconds on standard hardware and demonstrates that edge AI is a viable, lifesaving reality for disconnected communities.

Accomplishments that we're proud of

True 100% Offline Inference: We successfully got a high-performing language model running entirely on local CPU and system RAM without sending a single byte of data to the cloud or requiring an active internet connection. Conquering the 8GB RAM Limit: Through GGUF Q4_K_M quantization and C++ optimizations via llama.cpp, we kept the total runtime memory footprint under 2GB. This leaves plenty of headroom for the operating system and guarantees zero out-of-memory crashes on standard budget laptops. Sub-2-Second Clinical Triage: We engineered a compact, domain-specific prompt architecture that forces the local model to process patient observations and return structured, explainable clinical JSON outputs in under two seconds.

  • Safety-First Architecture: We successfully bridged modern edge AI with deterministic clinical rules, creating a hybrid system where local clinical safety logic acts as a failsafe to protect patient care.

What's next for DeepCare

Deepening African Language Support: We plan to expand local language prompt representations and lightweight translation modules for languages like Swahili, Hausa, Yoruba, and Twi, ensuring health workers can input symptoms in the languages their patients speak. Encrypted Multi-Facility Sync: When a community health worker occasionally reaches a zone with connectivity, DeepCare will support authenticated, end-to-end encrypted record synchronization with central district hospital databases (PostgreSQL). Expanded Clinical Protocols: Beyond general emergency triage, we aim to build specialized offline micro-modules for maternal health monitoring, pediatric malnutrition tracking, and endemic disease screening (such as Malaria and TB). On-Device Hardware Profiling & Tuning: We will build auto-tuning scripts into the setup process that analyze the host laptop's CPU core count and available RAM to dynamically optimize thread usage and context sizes for peak performance.

Built With

Share this project:

Updates